ZoneMinder Forums

Hello, (first post).

I have tried Googling this, and found multiple mentioned of bandwidth, but that doesn't seem to be the issue.

Two identical USB webcams (I actually have 4, but only try 2 at a time).
First one works fine - very easy to add.
Second one doesn't work, but works fine when swapped with the first ... then the other doesn't work. So I can only get one (either one) to work at once.

zmu -d /dev/video1 -q -v -U * -P *
Video Device: /dev/video9
General Capabilities
Driver: uvcvideo
Card: USB2.0 Camera
Bus: usb-0000:00:13.2-2
Version: 1.0.0
Type: 0x4000001
Supports video capture (X)
Does not support video output
Does not support frame buffer overlay
Does not support VBI capture
Does not support VBI output
Does not support sliced VBI capture
Does not support sliced VBI output
Does not support video output overlay
Does not have tuner
Does not have audio in and/or out
Does not have radio
Does not support read/write i/o (X)
Does not support async i/o
Supports streaming i/o (X)
Standards:
Formats:
YUV 4:2:2 (YUYV) (YUYV)
Crop Capabilities
Bounds: 640 x 480
Default: 640 x 480
Inputs: 1
Input 0
Name: Camera 1
Type: Camera
Audioset: 00000000
Standards: 0x0
Power on (X)
Signal detected (X)
Colour Signal detected
Horizontal Lock detected

Extract from /var/log/messages
Jun 16 00:56:14 localhost zmdc[19242]: ERR ['zmc -d /dev/video1' exited abnormally, exit status 255]
and
Jun 16 00:57:28 localhost zmdc[19242]: INF ['zmc -d /dev/video1' crashed, signal 134]

I have run out of ideas.

I can run the second camera fine using Cheese (whilst running the first through ZM).

As far as I understand, all ZM cameras are their own zmc process, and therefore don't clash. Since the OS (CentoOS 6.5) can view both cameras (one in ZM one in Cheese) at the same time, I don't see where the confusion is coming from.

One other comment, at one point, when I switched cameras, I had the output from /dev/video0 displayed on a monitor for /dev/video1.

I would appreciate any help.

Many thanks.

FIXED!

For anyone who is interested:

# chmod 666 /dev/video*

For some reason the video device was being added with different permissions. This fixes it!

(Also upgraded to v1.27)

marloweos wrote:FIXED!

For anyone who is interested:

# chmod 666 /dev/video*

For some reason the video device was being added with different permissions. This fixes it!

(Also upgraded to v1.27)

Now, just to see if that really did fix it, reboot and remove/reattach the devices. Still fixed? Or did you lose the permissions again?

In the old days, you could go in and manually mess with things in /dev. Now, with udev and other automated systems, you can find that your changes disappear when the device is recreated. I don't know the specifics of your distribution, but you may need to go and fix this properly in a rules file somewhere, to hint what permissions and owner should be used when the device is discovered.

As (not the right solution) as it may be, I have a cron entry of:
* * * * * chmod 666 /dev/video*

Which fixes it (even on reboot). (Maybe an @reboot would have been better, but this also works for connected hardware - albeit at an up to 60 second delay).

You are quite right however, my solution is by far from the best.

One day I will read up on the udev rules and then I'll know what to change and where, (I previously tried manipulating udev rules to always pass through set hardware to a VM when attached, but couldn't get it working).
From memory I simply add the command to execute when a device is connected.

Thanks for your reply.

I too was hit with this permissions problem when I upgraded to v1.27 yesterday. In the case of Gentoo, the device is owned by the "video" group. Rather than muck about with udev rules I solved it with a different method. Since zoneminder (in the case of Gentoo, other distros may vary) runs under the "apache" user, I simply added the "apache" user to the "video" group.

marloweos wrote:As (not the right solution) as it may be, I have a cron entry of:
* * * * * chmod 666 /dev/video*

Which fixes it (even on reboot). (Maybe an @reboot would have been better, but this also works for connected hardware - albeit at an up to 60 second delay).

You are quite right however, my solution is by far from the best.

A single chmod by hand, is a gentle tap with a rubber toy hammer. I was concerned you might lull yourself (and others) into a false sense of fixedness!

A chmod a minute, from cron, now that's a sledgehammer

@reboot wouldn't be better -- if the device is disconnected and reconnected, then nothing would be there to fix it.

udev rules are the way to go, and yes they can be a pain to get just right.

Thanks