2

I want use two USB webcam with motion, I've connected both to an USB hub, giving from CLI the command

sudo lsusb

I can see that both cams are connected

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 008: ID 046d:09c1 Logitech, Inc. QuickCam Deluxe for Notebooks **//THIS**
Bus 001 Device 021: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 0951:1643 Kingston Technology DataTraveler G3 4GB
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 007: ID 046d:092f Logitech, Inc. QuickCam Express Plus **//THIS**
Bus 001 Device 022: ID 0461:4d0f Primax Electronics, Ltd HP Optical Mouse
Bus 001 Device 023: ID 04f2:0841 Chicony Electronics Co., Ltd

The problem is that I'm not able to see the videostream of the second cam.

I've seen in /etc/motion/thread1.conf the first cam using videodevice /dev/video0, by default. The second /etc/motion/thread2.conf use videodevice /dev/video1, always by default.

The first works, the second doesn't. [I use port 8081 for first webcam and port 8082 for the second]

/dev/video0 /dev/video1

I thought that one error could be the wrong name /dev/video1.

Any advice?

Mitro
  • 1,091
  • 6
  • 22
  • 37

1 Answers1

1

If /dev/video1 exists, it is probably attached to something. Try pulling the second camera out of the hub, wait a few seconds, and ls /dev | grep video -- the node should disappear. Likewise, when you plug it in, it should appear. This would clarify whether or not it is using that node.

goldilocks
  • 86,451
  • 30
  • 200
  • 258
  • Ok, it shows me video0 and video1, both written in red. So are they connected and ready to use, right? – Mitro Apr 19 '14 at 15:45
  • Those are created dynamically, so if one of them appears and disappears when you plug a device in and out, you can be certain it is using that node and the kernel has a driver for it. It's "ready to use" in that sense, but it doesn't mean it will work -- e.g., if the second camera doesn't work alone at all, it won't work in combination with another one. – goldilocks Apr 19 '14 at 15:52
  • I tried both alone and both works. When they are recognised as video0 I suppose – Mitro Apr 19 '14 at 15:53
  • It's unlikely to be the kernel driver then (unless there's some bug whereby they interfere with one another, but that would be odd, I think), so it's not simply because it's `/dev/video1`. "Motion" is a specific piece of software, right? Try plugging a screen and keyboard in and using something else (e.g. `cheese`, or anything seperate from the motion software) to see if you can use the second camera locally while the other one is networked. – goldilocks Apr 19 '14 at 16:06
  • I've solved ;) thanks also to your answer but was my mistacke, I wrote 1 as input instead of 8 (8 is used for USB device). Altough I've tried third cam, but is too old and doesn't work. – Mitro Apr 19 '14 at 17:26
  • 1
    It's not unusual to find your own mistake by first ruling out everyone else's, lol -- I do it pretty regularly. – goldilocks Apr 19 '14 at 17:27
  • When identifying hardware from the command line, yanking out hardware is not an appropriate software solution. – Cerin Apr 15 '15 at 19:23
  • @Cerin You're just wrong. There is nothing bad about unplugging and plugging in USB devices. That's what USB is intended for. It is not a PCI slot. When a USB device is plugged in, the kernel knows about it, the device ID is communicated, and it will look to see if a driver is available for that device. If so, it is loaded, and the driver may create a `/dev` node. Then when the device is removed, the driver should remove the device node. – goldilocks Apr 16 '15 at 11:36
  • @goldilocks, I didn't say USB wasn't hotpluggable. I said identifying hardware by yanking it out and seeing what stops working isn't a good solution. Yes, you could also figure out which hard drive corresponds to sdb by shutting down your machine, yanking out one hard drive, rebooting, and see what data's missing, but a better solution would be to run a tool to find the hdd's serial number, than match that number to the one on the physical drive. The same is possible with USB by using hwinfo/libusb/lsusb. – Cerin Apr 16 '15 at 17:41
  • I'd agree this is not the *ideal* solution, in that sense that an ideal solution could be one that does not *exist* (e.g., to go to an extreme, I subvocalize a request for information and it is instantly displayed holographically before me...). However, I disagree that with the assertion that it's "not an appropriate solution". I'm sure there is a more decisive way to do this *if* you want to parse and correlate stuff in `/sys`, and if someone takes the time to write an answer doing so, they have my vote... – goldilocks Apr 16 '15 at 17:50
  • ...Better yet, someone could write an application to do so. Sans any of these, this is really a **debugging stategy** and nb. it did lead the OP to solution based on the debugging of an error made by the OP. – goldilocks Apr 16 '15 at 17:51