(In reply to comment #0)
> STEPS TO REPRODUCE THE PROBLEM:
> Start any user-facing camera (/dev/video1) software, or simply
> gst-launch-0.10 v4l2src device=/dev/video1 ! ffmpegcolorspace ! autovideosink

Confirming.  This:

v4l2src device=/dev/video1 ! ffmpegcolorspace ! pngenc snapshot=1 ! filesink
location=test.png

avoids scaling and produces a file that can be examined.  The band starts at
around 123 pixels from the left.

Can anyone suggest any tests that don't involve gstreamer?

Comment 2 Andre Klapper 2009-10-21 14:43:06 UTC

(This can for example be seen in the "mirror" application in extras-testing
repository.)

Fixed in internal week 43 build.
Any public update released with or after this build version (x.2009.43-y) will
include the fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

Comment 3 Andre Klapper 2009-10-21 16:03:08 UTC

I can confirm myself that this is fixed in "mirror" running on the latest
internal image.

Comment 4 Attila Csipa (reporter) 2009-10-21 21:29:37 UTC

For the record, mirror is using gstreamer (that's why I filed the bug here
initially). An independent test is for example something along the lines of
mplayer tv:// -tv device=/dev/video1

Comment 5 Andre Klapper 2009-10-30 19:32:25 UTC

*** Bug 5944 has been marked as a duplicate of this bug. ***

Comment 6 Tim Samoff 2009-12-23 19:15:40 UTC

I can confirm this as FIXED in 2.2009.51-1, BUT...

The camera quality seems even worse than before and there are many static
"dead" pixels that remain onscreen, regardless of external ambient light.

Should this be reopened, or should a new bug be filed?

I can confirm this has been fixed in 2.2009.51-1 and confirm also that there
are "dead huge pixels" in the image.
The quality of the image using 'mirror' is mostly the same, may be a bit darker
(compared with two n900s one next to each other with firmware 42-11 and 51-1)

Comment 8 Attila Csipa (reporter) 2010-01-12 16:39:31 UTC

With 44-1 firmware, I still have this issue, even though according to #2 it
should be gone.

Comment 9 Andre Klapper 2010-01-12 16:42:57 UTC

Sorry for being misleading here.
The fix is not included in 1.2009.44-1, but will be included in the next
2.2009.** release (PR1.1).

Comment 10 Andre Klapper 2010-01-14 12:27:43 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

Comment 11 Tim Samoff 2010-01-14 15:42:23 UTC

(In reply to comment #10)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
> Please leave a comment if the problem is not fixed for you in this update
> version.
> 

Andre, should we go through the formality of lodging another bug report for
Comments #6 & #7?

Comment 12 Attila Csipa (reporter) 2010-01-14 15:47:26 UTC

Verified, dark band gone in 51-1. 

As the OR I'd say missing/weak noise reduction is a different issue as to what
was reported here, but if you say it's simpler to keep it here, feel free to
reopen.

Comment 13 Andre Klapper 2010-01-14 16:35:13 UTC

(In reply to comment #12)
> if you say it's simpler to keep it here, feel free to reopen.

Nah, this report here is about the band only. And that's fixed.

Comment 14 Tim Samoff 2010-01-14 19:04:19 UTC

(In reply to comment #13)
> Nah, this report here is about the band only. And that's fixed.
> 

Please see Bug #7993 for further developments with the dead pixel/noise
reduction issues.