Webcam Is Not Working

[Sean Vaidhyanathan]

HelloJoe_tFb, thank you for bringing this to our attention. What kind of device and OS do you use? Have you tried deleting cookies and cache recently? Do you use extensions? Does the same happen in a private window?

If you go brave://settings/content/all and then to one of the sites, such as your webcamtests.com one, and change it to Allow instead of Ask, does it make a difference? (Note: For screenshot I just randomly clicked on a site and then changed to Allow. Mine is usually on Ask, I just did it for the screenshot, lol)

On the previous version of MacOS (14.1) I was able to get this working using a firmware workaround -to-do-if-your-webcam-doesnt-work-in-macos-sonoma but since the 14.2 update the camera is not recogised (the OES utility is recognised by Zoom however - it just thinks the camera is disconnected)

Good news folks, the Mac OS 14.2.1 update released today seemed to have fixed the issue. You will still need to do the firmware workaround -to-do-if-your-webcam-doesnt-work-in-macos-sonoma but it works again like in 14.1.

I agree with all of the above, this is becoming ridiculous and to all above sorry about the rant below, but I do not feel that Canon is taking its customers seriously and this is just another nail in the coffin.

The EOS Webcam Utility software doesn't work and when it works it's crippled behind a paywall.

Besides, how many times do you have to restart your camera for it to show up?

And why should I pay extra for 1080 or 4k for that matter? What of Wi-Fi connectivity? It's all available in the hardware that I paid for.

All we need is a driver that works. Install, plug and play, that's it. The only thing I'd wish for on the driver is the ability to connect more than 1 camera at a time and have a stream for each. Bells and whistles should be reserved for OBS and other similar software.

I've already sold a part of my professional Canon equipment; I am thinking of selling the rest and going to a company that listens to their customers and does not discriminate operating systems or platform.

This should never happen Canon, you have access to the macOS Betas, and you should be testing. If you don't, well my case is made for me.

By the way, [REDACTED PER FORUM GUIDELINES] work on MacOS Sonoma 14.2, a third-party paid product just like yours, but it works! So, it is doable. And I should not have to buy a 3rd party product for a simple driver.

Canon, please fix it ASAP, I've already waisted 2 days thanks to this.

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.

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

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.)

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.

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).

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.

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...

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.

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.

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.

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).

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....

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.

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.

Thank you. Once I read this part properly "You'll see the volume name...." and stopped trying to guess what my Volume was called, the rest was easy. I did encounter an issue that the New Teams would only display the logo for the EOS webcam app and not my actual camera. However, I switched back to Teams Classic and it works great. Thank you for taking the time to post!!!

The webcam stream via the web frontend worked 2 months ago. Now it only shows "Webcam Stream Loading" on a black background. When I use the iPad app the cam works just fine but not on the website.

I also tried to change the USB ports but it didn't help. I have the latest version of Octoprint installed.

Brilliant. That means that mjpg_streamer is running and seems to be happy. I'm guessing that you're seeing two images, one a snapshot and one a video. The second one is something like :8080/?action=stream . Just the / path from before by itself is some HTML which includes both outputs.

If you're trying to reach your OctoPrint instance using HTTPS then it's possible that it doesn't like trying to include an HTTP stream as part of that for the webcam. In other words, just try rather than .

ive started the mjpeg streamer in SSH following setting up octoprint tutorial. but i cant get a image from the camera like sydthe. ive enabled the cam in sudo raspi-config (which is a bit different on a raspberry 3a+)

If the web interface isn't working then it could be that something went wrong during the original install. It could mean that the haproxy service isn't happy. It could mean that the OctoPrint service didn't startup. I'd just suggest that troubleshooting the webcam connectivity is 2nd place right now versus getting the main software itself.

3a8082e126