Zoneminder: Got unexpected memory map file size

I'm trying to capture video from a device that's 640x480 24bit color, but I'm getting this in /var/log/syslog:

ERR [Got unexpected memory map file size 9217192, expected 36865192

Google-ing for this doesn't turn up anything except the Zoneminder source code; but it turns out that this is caused by too small a setting in /proc/sys/kernel/shmmax. This is explained the Zoneminder FAQ.

After updating my /proc/sys/kernel/shmmax to the recommended 128MB, it works just fine...

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 SourceForge.net, 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 ./install.sh to
BARS=0
and run ./test4PAL.sh 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 install.sh is, or how to find it. Maybe the whole thing's moved to kernel.org. 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 site:kernel.org"
• 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

Zoneminder Memory.pm 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 Memory.pm is at

/usr/share/perl5/ZoneMinder/Memory.pm

and the patch in question was applied at line 130.

Movable Type and Google Plus authorship

I found the instructions for linking authorship to your Google+ profile:http://www.google.com/support/webmasters/bin/answer.py?answer=1408986

I'm trying to get this to work in Movable Type, but so far either my page is not getting indexed, or I'm doing it wrong. These are the instructions I followed:

• Edit your Movable Type profile so that your Website URL is your Google+ profile page. You don't have to add ?rel=author at the end of the URL; that will be done below.
• Choose Design->Templates and edit Archive Templates->Entry:
• Find the byline. In my template it looks like this:

By <span class="vcard author"><$mt:EntryAuthorLink show_hcard="1"$></span> on <abbr class="published" title="<$mt:EntryDate format_name="iso8601"$>">

• Insert the following markup in an appropriate place; I've inserted it directly after the <$mt:EntryAuthorLink> element:

<a href="<$mt:EntryAuthorURL$>?rel=author">Google+</a>

• Now go back to Design Templates and edit Template Modules->Entry Summary. Repeat the same steps as above.

If you follow these instructions (which produces HTML which seems to match the requirements of authorship), and you're successful, please leave me a comment and let me know...

Update: I've moved to Blogger, and it will soon have Google+ profile integration, so I'm not as motivated to figure this out. If anyone else figures it out, please feel free to post a comment.

Update2: I've found out how to find out if your rel=author link will work. There's a Rich Snippets Testing Tool that tells you about authorship for a specific page. I tried that page and it said my Movable Type page is "Verified: Authorship markup is correct for this page." But it still doesn't show up in search results, because my blog probably isn't interesting enough to be included yet...

iOS 4.3.x wifi unresponsive after x minutes of use

I have a network setup with an Airport Extreme base station, and a second wired bridge access point with the exact same SSID, key, etc., that's running DD-WRT v24-sp2.

With my iPad 2 with iOS 4.3.3 and 4.3.5, my wifi connection won't work after x minutes of use. It looks like it's connected: icon is good, IP address is good, but no traffic. Turning wifi off and then back on instantly repairs the connection.

However, it always works when I'm close to the Airport Extreme.

I filed this bug with Apple a while ago, and they've asked for more information, but haven't fixed it yet. I wonder if anyone else has this issue...