Webcam worked and then I added a second one

Camera model
2x C270

What is the problem?
One was working fine. I then went through the Chris's Basement youtube tutorial and the original cam stopped working (it's being seen second according to /var/log/messages) I originally got past the source octopi.txt in the webcamd files which originally threw me.

Now a cam will not start with 'Unable to set format: 1196444237 res: 1280x720'

What did you already try to solve it?
So I first tried setting different resolutions, all got the same error, so I went through my config again.

I set up the rules so that my devices are allocated a symlink in /dev based on their serial numbers taken from /var/log/messages when plugging them in.

**pi@pmk3** : **/etc/udev/rules.d $** cat 99-usb.rules
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0825", ATTRS{serial}=="D6A16790", SYMLINK+="videosky"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0825", ATTRS{serial}=="18502F90", SYMLINK+="videobase"

I checked and both symlinks point to a video[number] so I'm assuming that's good:

**pi@pmk3** : **/etc/default $** ls -las /dev/video*
0 crw-rw---- 1 root video 81, 0 Nov 20 23:07 **/dev/video0**
0 crw-rw---- 1 root video 81, 1 Nov 20 23:07 **/dev/video1**
0 crw-rw---- 1 root video 81, 4 Nov 20 23:07 **/dev/video10**
0 crw-rw---- 1 root video 81, 5 Nov 20 23:07 **/dev/video11**
0 crw-rw---- 1 root video 81, 6 Nov 20 23:07 **/dev/video12**
0 crw-rw---- 1 root video 81, 2 Nov 20 23:07 **/dev/video2**
0 crw-rw---- 1 root video 81, 3 Nov 20 23:07 **/dev/video3**
0 lrwxrwxrwx 1 root root 6 Nov 20 23:07 **/dev/videobase** -> **video0**
0 lrwxrwxrwx 1 root root 6 Nov 20 23:07 **/dev/videosky** -> **video3**

The system is able to support 2 C270 cameras attached since it can tell them apart.

webcamd (the original cam now called /dev/videosky, but now detected second) was updated as per the video and is failing to start while the webcamd2 (/dev/videobase) is starting fine. See webcamd logs below.

I saw somewhere about checking if the devices have attached properly:

**pi@pmk3** : **/etc/udev/rules.d $** v4l2-ctl --list-devices
bcm2835-codec (platform:bcm2835-codec):
/dev/video10
/dev/video11
/dev/video12

UVC Camera (046d:0825) (usb-3f980000.usb-1.1.2):
/dev/video2
/dev/video3

UVC Camera (046d:0825) (usb-3f980000.usb-1.2):
/dev/video0
/dev/video1

But in that article, it says I should be using the first of the devices lists, which is video2, not video3 that the symlink points at. I assumed this is a red herring because if I use /dev/video2 I get a device busy error.

Looking at the capabilities however:

pi@pmk3:~ $ v4l2-ctl -d /dev/videosky --all
Driver Info (not using libv4l2):
	Driver name   : uvcvideo
	Card type     : UVC Camera (046d:0825)
	Bus info      : usb-3f980000.usb-1.1.2
	Driver version: 4.19.66
	Capabilities  : 0x84A00001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x04A00000
		Streaming
		Extended Pix Format
Priority: 2

Seems a bit light on stuff, but this is the physical camera that was there before, just being detected second now. If I do the same to the /dev/video2 which is first as per the previous article:

pi@pmk3:~ $ v4l2-ctl -d /dev/video2 --all
Driver Info (not using libv4l2):
	Driver name   : uvcvideo
	Card type     : UVC Camera (046d:0825)
	Bus info      : usb-3f980000.usb-1.1.2
	Driver version: 4.19.66
	Capabilities  : 0x84A00001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
	Width/Height      : 640/480
	Pixel Format      : 'YUYV'
	Field             : None
	Bytes per Line    : 1280
	Size Image        : 614400
	Colorspace        : sRGB
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Default
	Flags             : 
Crop Capability Video Capture:
	Bounds      : Left 0, Top 0, Width 640, Height 480
	Default     : Left 0, Top 0, Width 640, Height 480
	Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 640, Height 480
Selection: crop_bounds, Left 0, Top 0, Width 640, Height 480
Streaming Parameters Video Capture:
	Capabilities     : timeperframe
	Frames per second: 30.000 (30/1)
	Read buffers     : 0
                     brightness (int)    : min=0 max=255 step=1 default=128 value=128
                       contrast (int)    : min=0 max=255 step=1 default=32 value=32
                     saturation (int)    : min=0 max=255 step=1 default=32 value=32
 white_balance_temperature_auto (bool)   : default=1 value=1
                           gain (int)    : min=0 max=255 step=1 default=64 value=64
           power_line_frequency (menu)   : min=0 max=2 default=2 value=2
      white_balance_temperature (int)    : min=0 max=10000 step=10 default=4000 value=4000 flags=inactive
                      sharpness (int)    : min=0 max=255 step=1 default=24 value=24
         backlight_compensation (int)    : min=0 max=1 step=1 default=0 value=0
                  exposure_auto (menu)   : min=0 max=3 default=3 value=3
              exposure_absolute (int)    : min=1 max=10000 step=1 default=166 value=166 flags=inactive
         exposure_auto_priority (bool)   : default=0 value=1

That seems good, except it's the YUYV camera which I don't want. But I thought I'd try the -y option, and that gives me a device busy:

Starting up webcamDaemon...

--- Configuration: ----------------------------
camera:        auto
usb options:   -d /dev/video2 -r 1280x720 -f 30 -y
raspi options: -fps 10
http options:  -w ./www-octopi -p 8080
-----------------------------------------------

Explicitly set USB device was found in options: /dev/video2
Found video devices:
/dev/video0
/dev/video1
/dev/video10
/dev/video11
/dev/video12
/dev/video2
/dev/video3
USB device was set in options and found in devices, start MJPG-streamer with the configured USB video device: /dev/video2
<13>Nov 21 07:10:41 pi: Starting USB webcam
Running ./mjpg_streamer -o output_http.so -w ./www-octopi -p 8080 -i input_uvc.so -r 1280x720 -f 30 -y
MJPG Streamer Version: git rev: ddb69b7b4f114f3c2ca01adf55712792ca8aed43
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 1280 x 720
 i: Frames Per Second.: 30
 i: Format............: YUYV
 i: JPEG Quality......: 80
 i: TV-Norm...........: DEFAULT
libv4l2: error setting pixformat: Device or resource busy
Unable to set format: 1448695129 res: 1280x720
Init v4L2 failed !! exit fatal
 i: init_VideoIn failed

The new hardware shows what I'd expect:

pi@pmk3:~ $ v4l2-ctl -d /dev/videobase --all
Driver Info (not using libv4l2):
	Driver name   : uvcvideo
	Card type     : UVC Camera (046d:0825)
	Bus info      : usb-3f980000.usb-1.2
	Driver version: 4.19.66
	Capabilities  : 0x84A00001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
	Width/Height      : 1280/720
	Pixel Format      : 'MJPG'
	Field             : None
	Bytes per Line    : 0
	Size Image        : 816000
	Colorspace        : sRGB
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Default
	Flags             : 
Crop Capability Video Capture:
	Bounds      : Left 0, Top 0, Width 1280, Height 720
	Default     : Left 0, Top 0, Width 1280, Height 720
	Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 1280, Height 720
Selection: crop_bounds, Left 0, Top 0, Width 1280, Height 720
Streaming Parameters Video Capture:
	Capabilities     : timeperframe
	Frames per second: 30.000 (30/1)
	Read buffers     : 0
                     brightness (int)    : min=0 max=255 step=1 default=128 value=100
                       contrast (int)    : min=0 max=255 step=1 default=32 value=28
                     saturation (int)    : min=0 max=255 step=1 default=32 value=26
 white_balance_temperature_auto (bool)   : default=1 value=0
                           gain (int)    : min=0 max=255 step=1 default=64 value=128
           power_line_frequency (menu)   : min=0 max=2 default=2 value=2
      white_balance_temperature (int)    : min=0 max=10000 step=10 default=4000 value=6000
                      sharpness (int)    : min=0 max=255 step=1 default=24 value=24
         backlight_compensation (int)    : min=0 max=1 step=1 default=0 value=0
                  exposure_auto (menu)   : min=0 max=3 default=3 value=1
              exposure_absolute (int)    : min=1 max=10000 step=1 default=166 value=171
         exposure_auto_priority (bool)   : default=0 value=0

I have now run out of things to try.

Logs

My looping /var/log/webcamd:

Starting up webcamDaemon...

--- Configuration: ----------------------------
camera:        auto
usb options:   -d /dev/videosky -r 1280x720 -f 30
raspi options: -fps 10
http options:  -w ./www-octopi -p 8080
-----------------------------------------------

Found video devices:
/dev/video0
/dev/video1
/dev/video10
/dev/video11
/dev/video12
/dev/video2
/dev/video3
USB device was not set in options, start MJPG-streamer with the first found video device: /dev/video0
<13>Nov 21 00:12:05 pi: Starting USB webcam
Running ./mjpg_streamer -o output_http.so -w ./www-octopi -p 8080 -i input_uvc.so -d /dev/videosky -r 1280x720 -f 30
MJPG Streamer Version: git rev: ddb69b7b4f114f3c2ca01adf55712792ca8aed43
 i: Using V4L2 device.: /dev/video3
 i: Desired Resolution: 1280 x 720
 i: Frames Per Second.: 30
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
Unable to set format: 1196444237 res: 1280x720
Init v4L2 failed !! exit fatal
 i: init_VideoIn failed

Additional information about your setup (OctoPrint version, OctoPi version, ...)
OctoPrint 1.3.12 running on OctoPi 0.16.0 on a Pi3B+

Oh, interestingly, I rebooted, and both cams worked. I rebooted again and the other cam failed. I rebooted again and both cams failed... and all combiantions that seem random. Is this an mjpeg streamer startup thing?

I added a random delay in the webcamd script of between 5 and 15 seconds and it's still pretty random as to whether either cam will start up.

I think I'd look at the power requirements and make sure that my power adapter is correct.

Its the modmypi 3a supply with switch, no under-voltage detected:

**pi@pmk3** : **~ $** /usr/bin/vcgencmd get_throttled
throttled=0x0

I think I'd next run...

sudo apt-get update --allow-releaseinfo-change
sudo apt-get -y upgrade

Nope, i't don't wanna:

**pi@pmk3** : **~ $** sudo apt-get update --allow-releaseinfo-change
[sudo] password for pi: 
E: Command line option --allow-releaseinfo-change is not understood in combination with the other options

Alright, try it without that argument then. Basically, we're trying to allow a non-release version of Buster to go full release. But maybe you have that already...? Drive on without that argument for the first command.

I think I did that, but this is a new image from octopi. But the upgrade seems to hold some things back but they don't seem important?

pi@pmk3:~ $ sudo apt-get update
[sudo] password for pi: 
Get:1 http://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages [11.7 MB]                      
Fetched 11.7 MB in 23s (490 kB/s)                                                                                                                                  
Reading package lists... Done
pi@pmk3:~ $ sudo apt-get -y upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  ffmpeg libavdevice57 libavfilter6 libavformat57
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
pi@pmk3:~ $ 

9 reboots, 2 success :frowning:

See this post for a reason why that might be the case. Maybe it wants the dist-upgrade; it's what I was trying before with that extra argument.

Ha, I'm not afraid if a dist-upgrade. 3 reboots later, 2 failures of the webcams

pi@pmk3:~ $ sudo apt-get -y dist-upgrade
[sudo] password for pi: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  libbluray1
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  libaacs0 libbdplus0 libbluray2
The following packages will be upgraded:
  ffmpeg libavdevice57 libavfilter6 libavformat57
4 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,417 kB of archives.
After this operation, 586 kB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian stretch/main armhf libbluray2 armhf 1:1.0.2-1 [128 kB]
Get:3 http://archive.raspberrypi.org/debian stretch/main armhf libavformat57 armhf 7:3.2.14-1~deb9u1+rpt1 [874 kB]
Get:2 http://raspbian.mirror.uk.sargasso.net/raspbian stretch/main armhf libaacs0 armhf 0.8.1-2 [44.4 kB]
Get:5 http://archive.raspberrypi.org/debian stretch/main armhf libavfilter6 armhf 7:3.2.14-1~deb9u1+rpt1 [693 kB]
Get:4 http://archive-bm.raspbian.org/raspbian stretch/main armhf libbdplus0 armhf 0.1.2-2 [43.1 kB]
Get:6 http://archive.raspberrypi.org/debian stretch/main armhf libavdevice57 armhf 7:3.2.14-1~deb9u1+rpt1 [113 kB]
Get:7 http://archive.raspberrypi.org/debian stretch/main armhf ffmpeg armhf 7:3.2.14-1~deb9u1+rpt1 [1,520 kB]
Fetched 3,417 kB in 55s (61.3 kB/s)                                                                                                                                
apt-listchanges: Reading changelogs...
Selecting previously unselected package libbluray2:armhf.
(Reading database ... 44623 files and directories currently installed.)
Preparing to unpack .../0-libbluray2_1%3a1.0.2-1_armhf.deb ...
Unpacking libbluray2:armhf (1:1.0.2-1) ...
Preparing to unpack .../1-libavformat57_7%3a3.2.14-1~deb9u1+rpt1_armhf.deb ...
Unpacking libavformat57:armhf (7:3.2.14-1~deb9u1+rpt1) over (7:3.2.12-1~deb9u1+rpt1) ...
Preparing to unpack .../2-libavfilter6_7%3a3.2.14-1~deb9u1+rpt1_armhf.deb ...
Unpacking libavfilter6:armhf (7:3.2.14-1~deb9u1+rpt1) over (7:3.2.12-1~deb9u1+rpt1) ...
Preparing to unpack .../3-libavdevice57_7%3a3.2.14-1~deb9u1+rpt1_armhf.deb ...
Unpacking libavdevice57:armhf (7:3.2.14-1~deb9u1+rpt1) over (7:3.2.12-1~deb9u1+rpt1) ...
Preparing to unpack .../4-ffmpeg_7%3a3.2.14-1~deb9u1+rpt1_armhf.deb ...
Unpacking ffmpeg (7:3.2.14-1~deb9u1+rpt1) over (7:3.2.12-1~deb9u1+rpt1) ...
Selecting previously unselected package libaacs0:armhf.
Preparing to unpack .../5-libaacs0_0.8.1-2_armhf.deb ...
Unpacking libaacs0:armhf (0.8.1-2) ...
Selecting previously unselected package libbdplus0:armhf.
Preparing to unpack .../6-libbdplus0_0.1.2-2_armhf.deb ...
Unpacking libbdplus0:armhf (0.1.2-2) ...
Setting up libaacs0:armhf (0.8.1-2) ...
Setting up libbluray2:armhf (1:1.0.2-1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libbdplus0:armhf (0.1.2-2) ...
Setting up libavformat57:armhf (7:3.2.14-1~deb9u1+rpt1) ...
Setting up libavfilter6:armhf (7:3.2.14-1~deb9u1+rpt1) ...
Setting up libavdevice57:armhf (7:3.2.14-1~deb9u1+rpt1) ...
Setting up ffmpeg (7:3.2.14-1~deb9u1+rpt1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...

If it were me, I'd next swap in a Raspberry Pi 3B or 3B+ at this point. I'm guessing that this is Pi4B-specific and it will suddenly work as expected on the earlier platform.

I'm guessing that this is where things get shaky:

0 lrwxrwxrwx 1 root root 6 Nov 20 23:07 **/dev/videobase** -> **video0**
0 lrwxrwxrwx 1 root root 6 Nov 20 23:07 **/dev/videosky** -> **video3**

See how it's video0 and video3?

Similarly to your problem, if I press the reset button of a serial PyBoard Raspbian won't recapture the same device, it will use the next one available. So it was /dev/ttyACM0 maybe and after pressing the button it's suddenly /dev/ttyACM1 then. But rebooting puts it back to zero in my case. Perhaps yours—when it goes bad—it's just incrementing one of the two device handles in such a way that your configuration is temporarily wrong.

Not sure if we mentioned this in this thread but I think I'd plug both of these into the non-blue (v2.0 spec) USB connectors.

This is a 3B+ fresh out of the box (no blue USB ports).

When I run the v4l2-ctl --list-devices above it seems to use video0 for the first cams JPEG stream and video1 for its YUV stream, 2 and 3 are for the second cam. Somehow it seems to know that I want the JPEG streams and attach the symlinks to the correct ones. Things still fail if I use the -y option and the correct /dev/video, and also when I switch things around (restarting the appropriate webcamd). I'll swap out the 3B+ and see if it's a board thing, but I don't understand how it would be as it's not consistently one camera or video device... this sounds like a software glitch.

I'll switch boards and see what happens... assuming just the board swap will be ok, and won't melt my router or 3d printer... at this stage, I'll try anything :slight_smile:

My bad, I'm mixing up multiple support threads on here. You might even consider this approach (it's what I did on my own printer). The mobility means that I can re-use it on other projects or add more if I need to seriously document something.

When I did this before I had a raspicam and a C270 and after some manual config it worked fine. But the raspicam is really pants (laggy/slow/bad motion blur/can't control parameters...) at 1280x720 so I thought I'd go for 2 C270s. I can think of no reason why this won't work as it works fine with 1, and it can happily run 2 mjpeg-streamers.

For info, second board and its 5 attempts, 1 success. :frowning_face:

If you did have a Pi4B then I would say that it's got plenty of RAM to make all this happy.

Which makes me think... does any of this use hardware acceleration (math/gpu)? If so, then maybe it's a matter of testing this. Adjust the gpu_mem in your /boot/config.txt higher (stealing from CPU memory).

I upped the gpu_mem to 256 from 129 and its still failing.

I think I might be getting somewhere though, what I'm seeing is the symlinks changing:

  • When /dev/videobase works, it points at /dev/video0, when it fails it points at /dev/video1
  • When /dev/videosky works, it points at /dev/video2, when it fails it points at /dev/video3

If I delete the symlink and remake it to the correct device, then restart the webcamd it seems to work.

How can I force the symlink to point to the first video channel for that device in the rules file? I don't want to hard code this to use video0 and video2 cuz they may change if I pull the cables out and move them accidentally... and besides, that's kind of the point of the rules file.

Worst-case, I'll botch something in bash to run the v4l2-ctl call and compare bus infos and then rebuild the symlinks, but there has to be a better way, I only have a small underpowered brain????

I think I nailed it. Adding , ATTR{index}=="0" seems to have had 4 successful reboots. I'll try more.

Running sudo udevadm info --name=/dev/video0 --attribute-walk shows all the parameters and it seems you can use anything in the heirachy. When you compare it to /dev/video1 you only see the index difference.

9 reboots, 9 sucesses. I think that's it sorted :slight_smile:

Thanks for all your help tonight @OutsourcedGuru :slight_smile:

1 Like