After months of flawless operation, the webcam tab in OctoPrint will show various digital artifacts during operation. When this is happening, no other streaming clients (IP Cam on Android and iOS, for example) can connect to the stream.
What did you already try to solve it?
Restarting the webcamd service will return operation to normal, as will rebooting the Rpi4. After a few hours, though, the problem will return. If Cura is connected via its OctoPrint add-in, it will crash when webcamd.service is restarted, even though it appears to be unable to display the stream.
Logs (/var/log/webcamd.log, syslog, dmesg, ... no logs, no support)
There's no /var/log/webcamd.log. I've included everything in /var/log that references either mjpg_streamer or webcamd.service, though. logs.zip (11.0 KB)
Additional information about your setup (OctoPrint version, OctoPi version, ...)
Running on an RPi4 4GB, OctoPi 0.17.0, OctoPrint 1.4.2. All available Buster updates have been applied.
I'm now about 20 hours into a 25 hour print and the problem has not recurred. There are two distinct differences from incidents where the problem had occurred previously:
There's an active print running (it had occurred previously only when the printer was off or idle)
Cura (v4.7) Is not connected. I would usually leave Cura loaded so that I could preview upcoming layers and compare the printer's layer height against the slice preview in Cura. Once the current print was started, though, I exited Cura.
I'm beginning to think the latest Cura update may be having an odd interaction with the OctoPrint plugin, and this may be somehow interfering with mjpg_streamer's operation.
There are two incidents/changes that happened around the time this issue started. The first was a temporary disconnection of the camera to test flashing another controller; I had done that without shutting down the RPi. Once I plugged the camera back in, restarting webcamd.service seemed to return the video feed to operation. The other was the Cura 2.7 upgrade.
It's been a couple of days since the reported problem has occurred, and during that time Cura 4.7 has not been connected to OctoPrint.
So now I'm going to start up Cura and allow it to stay connected to OctoPrint for the next two days (although I don't currently have anything demanding to be printed). See you in 2 days, or when the problem resurfaces ... whichever comes first.
IF it is indeed Cura, I'd look if it's possibly a power issue. With the OctoPrint plugin in Cura it will show the webcam pretty much constantly, causing traffic & power consumption through additional CPU load. So maybe that's the clue here.
Maybe @fieldOfView can shed some light on possible changes on the Cura side that might be at play too.
Sure, here's the log. See the entries starting at around 2020-09-06 08:15:01,983. I think that's the last time it crashed. cura-20200909.zip (182.5 KB)
Thanks for the response. If it's a power issue, though, I'm not sure why restarting the webcamd service would correct it, at least for a while. The camera is pretty much always displaying in the OctoPrint tab and/or the Cura monitor constantly. And it's been working fine up until just recently.
I had top running while the stream was being presented both in my browser and via Cura's plugin, and whether the image was relatively static or active, there was no appreciable impact on CPU load.
Looking at the Cura log, I can not easily spot why it crashes; the log just stops and the next log item is from Cura starting again. This indicates that the crash did not happen in the Cura python or qml code, but a crash higher up in the frameworks Cura uses.
What I can see is that something strange is going on with the stream. There are a LOT of MJPEG buffer exceeds reasonable size. Restarting stream... messages. To understand these, a bit of information about MJPEG is needed. An MJPEG stream is - for the intent of this discussion - a stream of jpeg images streamed one after the other. There is no native support for this in the version of Qt that comes bundled with Cura, so I wrote a bit of code that parses the MJPEG stream, looking for the start and end markers of jpeg frames and decoding them one by one.
The 'MJPEG buffer exceeds reasonable size. Restarting stream...' log message means that Cura could not find a JPEG end marker after parsing 2 MB of MJPEG stream. That could mean two things:
your webcam stream resolution and quality are set higher than I anticipated, or
the mjpeg stream is misbehaving and not including end markers for the stream
It looks like the stream is reopened by Cura every two seconds or so. I can imagine reopening the stream is more stranuous than just streaming.
What resolution and quality do you have configured for your webcam? MJPEG wasn't really meant for high quality 1080p streaming. It is a fairly inefficient codec. Especially for scenes that are mostly static, since MJPEG (as explained above) does not look at inter-frame changes at all.
The camera is set for 1280x720 @ 15fps. It's a pretty basic camera, a Logitech C270 that's been operating perfectly for months. Nothing special for settings in /boot/octopi.txt:
camera_usb_options="-r 1280x720 -f 15"
My Cura experiment (leaving it connected overnight) was aborted by a Windows 10 cumulative update. I'll try again.
