Webcam Randomly Stops Working

Camera model
Logitech, Inc. Webcam C310

What is the problem?
Webcam randomly stops working within OctoPrint & RasPi altogether until reboot. Worked fine before switched to Raspberry Pi 4 (brand new build and setup from scratch - not even a restore from backup). Based on other similar posts I've read on this forum, it seems it may be related to specifically RasPi4s.

What did you already try to solve it?

  • Known good webcam. Used with prior OctoPrint server (RasPi3) without issue.
  • Executing "vcgencmd get_camera" during issue returns:

supported=1 detected=0

  • Executing "lsusb" shows the webcam attached during issue & returns:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 005: ID 046d:081b Logitech, Inc. Webcam C310
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

  • Executing "raspistill -o test.jpg" during issue returns:

mmal: Cannot read camera info, keeping the defaults for OV5647
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Camera is not detected. Please check carefully the camera module is installed correctly

  • Updated all dist & standard packages + reboot

Logs (/var/log/webcamd.log, syslog, dmesg, ... no logs, no support)

  • Despite webcam initially working, there is no /var/log/webcamd.log

  • Searched all logs within /var/log for "webcam" and found the below results within both the syslog & daemon logs at about the time I expect the camera stopped working

Feb 26 00:00:06 knoctopi webcamd[337]: Unable to dequeue buffer: No such device
Feb 26 00:00:06 knoctopi webcamd[337]: i: Error grabbing frames
Feb 26 00:00:06 knoctopi webcamd[337]: i: cleaning up resources allocated by input thread
Feb 26 00:00:06 knoctopi webcamd[337]: Unable to stop capture: No such device

  • Have attached zip of octoprint.log + all logs from /var/log
    octoprint.zip (1.5 MB)
    log.zip (272.0 KB)

Additional information about your setup (OctoPrint version, OctoPi version, ...)

  • Hardware: Raspberry Pi 4 (1gb RAM)
  • OS: Raspbian GNU/Linux 10 (buster)
  • Kernel: Linux knoctopi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
  • Octoprint: 1.3.12
  • Webcam: Logitech, Inc. Webcam C310 (USB connected to USB 2.0 port)
  • Network: Ethernet (Static IP)
  • SD:: Class 10 / Plenty of free space
  • Display: 3.5" Touch LCD (TouchUI) / HTTP / SSH
  • Power: Official RasPi4 power adapter / No undervoltage warnings
  • Plugins: (All up to date)

Action Command Prompt Support
Announcement Plugin
Anonymous Usage Tracking
Application Keys Plugin
Autoscroll (0.0.2)
Backup & Restore
Bed Visualizer (0.1.11)
BetterHeaterTimeout (1.2.0)
BLTouch Plugin (0.3.3)
Core Wizard
Dashboard (1.11.1)
DeleteAfterPrint Plugin (1.7.0)
Discovery
DisplayLayerProgress Plugin (1.18.0)
Error Tracking
Filament Manager (0.5.3)
FileManager (0.1.3)
Simple FileManager
Force Login
Logging
OctoPod Plugin (0.2.4)
OctoPod extension for OctoPrint
OctoPrint-IFTTT (1.2.1)
Connects OctoPrint events to IFTTT
Pi Support Plugin
Plugin Manager
Preheat Button (0.4.1)
Printer Safety Check
PrintJobHistory (1.0.0rc5)
Pushover (0.3.3)
Resource Monitor (0.2.1)
Sidebar Webcam (0.1.7)
Software Update
Tab Order (0.5.5)
Themeify (1.2.0)
Ultimaker Format Package (0.1.2)
Virtual Printer
Wemo Switch (0.1.5)

Any suggestions are appreciated and happy to test or submit additional info. Thanks!

Does it work in safe mode?

Thanks for the reply...

Are you asking if the webcam works in Safe Mode or that the issue occurs in Safe Mode? In middle of print now so can't check, but the webcam works fine on boot - it just randomly stops working during jobs. If thinking that it may be due to a plugin conflict (assuming that Safe Mode basically disables plugins), the plugins I use + their configuration is exactly the same as they were when I used it on the RasPi3 (when I didn't have the issue.)

Thanks

1 Like

We're just trying to find out if one of your plugins (on the Pi4B) is causing this or if it's naked-OctoPrint causing this or if it's the OctoPi-imaged mjpg_streamer that's causing this. The first step is to disable all plugins by running in safe mode.

Assuming that it still periodically fails then we're left with the latter two. If it's not the third-party plugins and it's not OctoPrint then we're left with mjpg_streamer, the driver stack, the hardware itself to include power-related issues and the connections to the camera.

Remember that you had to disconnect the camera from the Pi 3B rig to put it on the Pi 4B. It could be as simple as the ribbon cable connection is vibrating itself loose.

1 Like

USB webcam :wink:

Which is also why the raspistill test did absolutely nothing to confirm or deny functionality as that only works with a raspicam (AND won't work of said camera is already claimed by the webcam server, which is usually the case).

Same goes for vcgencmd btw - that's for the raspicam and does nothing for usb.

Could be that the camera just is wonky, I had similar issues with a Microsoft Lifecam back in the day. Next time it happens try if restarting the webcam server does the trick:

sudo service webcamd restart

The log entries from webcamd certainly sounds like the camera device simply vanished suddenly. Share /var/log/webcamd.log

Edit oh wait, is that a self install? Or OctoPi?

Thanks, Guys -

In middle of long print now, so will try once done. Don't know if related, but set up TouchUI yesterday which obviously requires installation of many additional packages. Since then, the camera is still working after 12 hours which is longer than it has before. BTW, the build was from the OctoPrint 0.17.0 image - not a custom build.

Thanks

Thanks

In case you are struggling with camera giving up after a few seconds or so:

What worked for me was this:

in /boot/config.txt change gpu_mem=128 to gpu_mem=256.

Fiddling with udev did not solve the issue, that did.

Regards.

Scratch that, the problem is still there.
From what i have found so far, i'is kernel related, something to do with xhci_hcd.
It happens on my pi running octopi, i have also seen it on a pi4 running pure raspbian.
It doesn't happen on my desktop, with kernel 5.9.something.
For the time being, i don't know how to solve it, i am trying to find a solution...

If anyone can enlighten me (us), please let me (us) know.

Hi there,

Just dropin'in because I have the same behavior.

  • OctoPrint 1.5.1
  • Python 3.7.3
  • OctoPi 0.17.0

The webcam just stops working, I never got it back without restarting the system (i.e. the RPI) completly...
lsusb command is grepping the webcam correctly (when it is not working through Octoprint). The LED on my webcam is not ON.

2 Likes

Me too with the same problem. Microsoft Life Cam HD. Needs reboots ocassionally to get it back up.

2 Likes

Still looking into it guys, i am not giving up.
l'll let you know if i nail it.

For the time being:
I taped the power pin in the usb cable that connects my Ender5 to the pi, no effect.
I booted with the camera disconnected.
Plugged the camera after everything started.
Manually started webcamd.
It worked flawlessly for more than 6 hours while a print was running...

However:
Today the camera is back to its previous behaviour no matter what i do.
Manually stopping/restarting webcamd, killing mjpg_streamer, remove/reinsert uvcvideo did not have the desired effect.

When i reach a consistent behaviour i'll let you know.

1 Like

Follow up:
If it means anything, after the camera "crash" the /dev/video0 is gone...

I believe i solved it, no hiccups so far.
It's not kernel related see my previous post.
It has to do with power suspending on usb devices.

Note to bzowk: This is not a pi4 issue, I am using a pi3b+.
I can't say if it applies to a pi4...

If i post everything it's going to be a very long post, i'll try to make it short:

I have a fan permanently connected to the pi, first thing i did was disconnecting it in case this is power related.
Problem still there***.
I added a udev rule to disable the microphone.
Problem still there***.

manually start webcamd***

tail -f /var/log/syslog

after a few seconds i got a "usb disconnected"***

lsusb

what is of interest is:
Bus 001 Device 006: ID 045e:0779 Microsoft Corp. LifeCam HD-3000
so camera still there

ls /dev/video*

/dev/video0 gone

So i figured this has to do with suspending.
created a udev rule specific to camera autosuspend:

nano /etc/udev/rules.d/90-disable-lifecam-autosuspend.rules

add the line (note the previous output from lsusb and adjust accordingly):
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="045e", ATTR{idProduct}=="0779", ATTR{product}=="Microsoft Corp. LifeCam HD-3000", TEST=="power/control", ATTR{power/control}:="on"

If anybody is interested i am happy to post all the details (marked with ***).

I am not sure if this is the "safe" way of solving it, please let me know if it is not.

Just confirming I have the same issue. Raspi4B, Default Ribbon Cable Cam.

As long as I was using version 1.4.x, everything worked fine. Once I updated to 1.5.x, the camera works initially but randomly becomes unavailable, and only Raspi system reboot can reactivate it. Reboot works reliably to get cam fixed however so unlikely this is a simple ribbon cable issue.

My plugins are:

Consolidated Tabs (0.1.3)
Cost Estimation (3.1.0)
DisplayLayerProgress Plugin (1.24.0)
EEPROM Editor for MPSM (0.1.1)
Filament Manager (1.6.3)
Malyan/Monoprice Connection Fix (0.1.3)
Marlin GCode Documentation (0.11.0)
Octoprint-Display-ETA (1.1.1)
PrettyGCode (1.2.3)
PrintTimeGenius Plugin (2.2.7)
Sticky Pad (0.1.4)
TouchUI (0.3.17)
TP-Link Smartplug (0.9.26)

Vanilla MJPEG says this once the cam fails:
HTTPConnectionPool(host='127.0.0.1', port=8080): Read timed out. (read timeout=5)

Since it worked so well before and so reliably unreliable after the update, I suspect a connection to the update.

Not sure if it would help if I would post any logs... which ones would?

Addendum:

sudo service webcamd restart

seems to help when the issue occurs... but I'd rather not have the fix be scripting something that SSH spams this command to my octopi :wink:

1 Like

This is my webcamd working normally (from journalctl -u webcamd):

Dec 11 01:47:14 octopi webcamd[341]: Starting up webcamDaemon...
Dec 11 01:47:14 octopi webcamd[341]: --- Configuration: ----------------------------
Dec 11 01:47:14 octopi webcamd[341]: cfg_file: /boot/octopi.txt
Dec 11 01:47:14 octopi webcamd[341]: camera: auto
Dec 11 01:47:14 octopi webcamd[341]: usb options: -r 640x480 -f 10
Dec 11 01:47:14 octopi webcamd[341]: raspi options: -fps 10
Dec 11 01:47:14 octopi webcamd[341]: http options: -w ./www-octopi -n
Dec 11 01:47:14 octopi webcamd[341]: Explicitly USB device:
Dec 11 01:47:14 octopi webcamd[341]: -----------------------------------------------
Dec 11 01:47:14 octopi webcamd[341]: Found video devices:
Dec 11 01:47:14 octopi webcamd[341]: /dev/video0
Dec 11 01:47:14 octopi webcamd[341]: /dev/video10
Dec 11 01:47:14 octopi webcamd[341]: /dev/video11
Dec 11 01:47:14 octopi webcamd[341]: /dev/video12
Dec 11 01:47:14 octopi webcamd[341]: raspi
Dec 11 01:47:14 octopi webcamd[341]: config file='/boot/octopi.txt':USB device was not set in options, start MJPG-streamer with the first found video device: /dev/video0
Dec 11 01:47:14 octopi root[419]: Starting USB webcam
Dec 11 01:47:14 octopi webcamd[341]: <13>Dec 11 01:47:14 root: Starting USB webcam
Dec 11 01:47:14 octopi webcamd[341]: Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n -i input_uvc.so -r 640x480 -f 10 -d /dev/video0
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: starting application
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: MJPG Streamer Version: git rev: 501f6362c5afddcfb41055f97ae484252c85c912
Dec 11 01:47:14 octopi webcamd[341]: MJPG Streamer Version: git rev: 501f6362c5afddcfb41055f97ae484252c85c912
Dec 11 01:47:14 octopi webcamd[341]: i: Using V4L2 device.: /dev/video0
Dec 11 01:47:14 octopi webcamd[341]: i: Desired Resolution: 640 x 480
Dec 11 01:47:14 octopi webcamd[341]: i: Frames Per Second.: 10
Dec 11 01:47:14 octopi webcamd[341]: i: Format............: JPEG
Dec 11 01:47:14 octopi webcamd[341]: i: TV-Norm...........: DEFAULT
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: Using V4L2 device.: /dev/video0
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: Desired Resolution: 640 x 480
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: Frames Per Second.: 10
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: Format............: JPEG
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: TV-Norm...........: DEFAULT
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Pan (relative): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Tilt (relative): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Pan Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Tilt Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Pan/tilt Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_ADD - Error at Focus (absolute): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Pan (relative): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Tilt (relative): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Pan Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Tilt Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Pan/tilt Reset: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Focus (absolute): Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at LED1 Mode: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at LED1 Frequency: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Disable video processing: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: UVCIOC_CTRL_MAP - Error at Raw bits per pixel: Inappropriate ioctl for device (25)
Dec 11 01:47:14 octopi webcamd[341]: o: www-folder-path......: ./www-octopi/
Dec 11 01:47:14 octopi webcamd[341]: o: HTTP TCP port........: 8080
Dec 11 01:47:14 octopi webcamd[341]: o: HTTP Listen Address..: (null)
Dec 11 01:47:14 octopi webcamd[341]: o: username:password....: disabled
Dec 11 01:47:14 octopi webcamd[341]: o: commands.............: disabled
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: www-folder-path......: ./www-octopi/
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: HTTP TCP port........: 8080
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: HTTP Listen Address..: (null)
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: username:password....: disabled
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: commands.............: disabled
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: starting input plugin input_uvc.so
Dec 11 01:47:14 octopi mjpg_streamer[420]: MJPG-streamer [420]: starting output plugin: output_http.so (ID: 00)
Dec 11 01:47:15 octopi webcamd[341]: Done bring up all configured video device
Dec 11 01:47:15 octopi webcamd[341]: Goodbye...
Dec 11 01:47:15 octopi systemd[1]: Started the OctoPi webcam daemon with the user specified config.

This is where shit hit the fan (not sure if there is a way I can get this to log more verbosely?):

Dec 11 08:07:05 octopi webcamd[341]: i: select() timeout
Dec 11 08:07:05 octopi webcamd[341]: i: cleaning up resources allocated by input thread
Dec 11 08:07:05 octopi mjpg_streamer[420]: MJPG-streamer [420]: select() timeout
Dec 11 08:07:05 octopi mjpg_streamer[420]: MJPG-streamer [420]: cleaning up resources allocated by input thread

This happenend after I ran "sudo service webcamd restart":

Dec 11 10:34:27 octopi systemd[1]: Stopping the OctoPi webcam daemon with the user specified config...
Dec 11 10:34:27 octopi systemd[1]: webcamd.service: Main process exited, code=killed, status=15/TERM
Dec 11 10:34:27 octopi systemd[1]: webcamd.service: Succeeded.
Dec 11 10:34:27 octopi systemd[1]: Stopped the OctoPi webcam daemon with the user specified config.
Dec 11 10:34:27 octopi systemd[1]: Starting the OctoPi webcam daemon with the user specified config...

The rest sounds normal, and it's been working since.

So the more permanent solution was running the following three steps in SSH:

sudo apt-get update --fix-missing
sudo apt-get upgrade
sudo reboot

As @foosel correctly pointed out, it's not Octoprint's fault if the Octopi enviroment it is running on becomes outdated.

So unless you frequently re-etch the latest Octopi to your SD card anyways, this is probably one of the default maintenance actions you have to do once in a while to prevent Octopi from eventually going downhill...

Again maybe at some point we can get an additional reboot option to execute these steps into octoprint's top bar (in addition to reboot system, shutdown system, there could be a new "udpate and reboot system" option doing effectively the above).

1 Like

Hi and thanks for the command on webcamd restart (working even when printing, not impacting the print)

But I am quite surprised with the sudo command (that I performed for sure few days ago, when trying the 1.5.0 rc3). I will execute them again, but even my octopi is 0.17 (the lastest version)... I do not think this will fix the issue efficiently, at least not in my case....

My original suspicion was that with 1.5.X something changed about the way octoprint talks to webcamd / MJPEG that sometimes makes those crash.

But I don't seem to understand enough about the process to effectively debug it, and it sounds like the devs are saying in other parts of this forum that no such change has been made. Power supply shortage was suspected at some point as well, in addition to mechanical issues (e.g. in the ribbon cables), but I could rule those out.

For me the apt-get upgrade seems to have reliably solved the issue, but i guess in other cases scripting something that regularly makes webcamd restart (like 5 min intervals or so) might be the best bet for a workaround until someone gets to the root of the issue. As you said, restarting webcamd over SSH does NOT mess with ongoing prints or any other vital operation so should be safe even if done pretty regularly.

The only change that was made anywhere near the webcam embedding was a quick permissions check of whether it should be loaded - and note that this is purely on the embedding side, and once the web UI is loaded it is either there, visible or it is not. And this was actually a bug fix, since it should have been there anyway.

The way embedding MJPG streams works, is with an <img> tag, set the src to the webcam stream and away we go. OctoPrint doesn't even know MGPG streamer exists, let alone how to mess around with it.

With every update, there seems to be cases of system instability that cause problems, like the SerialException thread, nothing was changed that could case this, but the upgrade somehow made people's printers disconnect more often. No idea whether the few isolated cases of MJPG streamer dying could be related, or whether it is coincidence - what tends to happen is that around updates, the people who would have usually run into problems think the problem was the update. Same number of people in a months time, but no update to blame.

1 Like

Hi there,
Just another update on this topic. I also find out another way to fix (temporarly) the issue:

sudo pkill mjpg_streamer

Excute this command twice will also make the webcam working again....