Wednesday, November 9, 2011

EasyCap DC60 and Ubuntu 11.10

I got an EasyCap DC60 from Amazon to see if it would work with my Ubuntu box to capture video. It looked promising at first... The output from dmesg looks like this:

[ 3391.497363] easycap::0adjust_standard: selected standard: PAL_BGHIN
[ 3391.808248] easycap::0adjust_format: sought:    640x480,UYVY(0x59565955),1=field,0x00=std mask
[ 3391.808256] easycap::0adjust_format: sought:    V4L2_FIELD_NONE
[ 3391.808264] easycap::0adjust_format: actioning: 640x480 PAL_BGHIN_AT_640x480_FMT_UYVY-n
[ 3391.832121] easycap::0adjust_brightness: adjusting brightness to  0x7F
[ 3391.856121] easycap::0adjust_contrast: adjusting contrast to  0x3F
[ 3391.880121] easycap::0adjust_saturation: adjusting saturation to  0x2F
[ 3391.904122] easycap::0adjust_hue: adjusting hue to  0x00

and it shows up as a video device just fine:

$ ls -altr /dev/video0 
crw-rw----+ 1 root video 81, 0 2011-11-05 22:58 /dev/video0

But when actually using it, it shows an image at first, and then shows grey bars. Note that the above message shows PAL, but I've tried NTSC, and other encodings with the same result. I found a thread about this on, but the SourceForge project appears to be empty now. Google Cache currently contains the thread. The interesting pieces of text are:

The vertical grey bars usually mean that the front-end video chip cannot lock onto the analogue input signal.  This can happen if, for example, the video signal is really NTSC while the mplayer command line specifies PAL.  But in these circumstances, I would not expect to see any video output at all (apart from the grey bars).  The puzzling thing is that you do get some valid video, which then disappears.

One possibility is that the SAA7113H chip is raising a hardware "lost signal" flag when in reality the signal remains entirely viable (some aspects of this chip are known to be flaky).  To investigate this, it would be useful if you could reinstall the driver after changing line 31 of the script ./ to
and run ./ again.  This is a straight go/no-go test:  either it solves the problem or it is doesn't.  We don't need a verbose kern.log this time, so you can set DEBUG=0 in the installation script.
Since the SourceForge project seems to have disappeared, I'm not sure where is, or how to find it. Maybe the whole thing's moved to I suppose I could start digging around in the kernel source and see if I can figure out what that does...

Update: OK, this was a lot easier than I thought:

  • Google for "easycap"
  • Find the README.
  • Remove all users of easycap kernel mod (shut down apps/services)
  • sudo rmmod easycap
  • sudo modprobe easycap 'bars=0'
  • Restart and try again...
Update 2: The next thing you should probably do is:
  • sudo vi /etc/modprobe.d/easycap.conf
  • options easycap bars=0
  • :wq
  • sudo reboot

Sunday, November 6, 2011

Zoneminder bug in 1.24.4

If you have Zoneminder installed and you're seeing this in /var/log/syslog:
Nov  6 14:36:11 machine zmwatch[2741]: ERR [Shared data size conflict in shared_data for monitor monitor, expected 328, got 316]
It's probably because of a bug that's been patched. On my distribution (Ubuntu 11.10) the file is at
and the patch in question was applied at line 130.