Stale Streams detected but not fixed #94
Comments
|
Samedi here. |
This was referenced Oct 2, 2023
|
We are seeing a lot of those as well on the camera-streamer enabled OctoPi image. This is currently a blocker for general roll-out. |
|
I will implement mechanism to periodically send ping-pong from the browser
to server.
…On Mon, Oct 2, 2023 at 12:05 PM Gina Häußge ***@***.***> wrote:
We are seeing a lot of those as well on the camera-streamer enabled OctoPi
image. This is currently a blocker for general roll-out.
—
Reply to this email directly, view it on GitHub
<#94 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AASOSQNNYAVI4GDDM263BKTX5KGWZANCNFSM6AAAAAA3OZU6XA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Hm... I'm not sure how this is going to help here though, for mjpg? The problem we are seeing is that the service simply stops working correctly when a log like the above is encountered. It's still running (so an automatic restart by the unit doesn't trigger), but all the streams (not just webrtc) just error one way or another. If the service would fully crash, the unit restart should trigger, though obviously a graceful handling of this situation would be preferable over all. A refresh in the browser or something like that doesn't work, it just errors out. |
|
Exactly. I temporarily fixed it by just adding an "exit(0)" where the log message "detected stale streams" is logged and just auto restart the service. However, i believe the issue also occures at different places, as this does not fix all issues. |
|
Let me take a look at this again. Previously when I checked this:
|
|
Bit confused about that. |
|
Too add some more data points to this, we've also gotten reports about this from CSI cameras (primarily RPi Cam 3, but also others). So I don't think it's just USB stuff. In any case, it would be important that this gets handled gracefully some way or another, either by exiting the service altogether since it is unusable when it happens right now (in which case it can be restarted automatically by systemd), or handling it internally by restarting whatever needs to get restarted in the camera pipeline. As things are at the moment, a manual restart is required to fix things, and for a headless system that's an big UX issue sadly. |
|
@foosel So, restarting service fixes the issue? Interesting. Do you have maybe |
|
Currently not, but I can see that I get one. It's a bit tricky since I haven't found yet a way to trigger it when I want, I just saw it happen myself, and I've gotten ( |
|
You can also send my way |
|
One example would be https://paste.octoprint.org/OYXd3AsGW5, as also posted by the user in question (with additional info on the hardware) here on this repo as #90. edit Also attached: edit2 FWIW, I've just flashed a Pi3 with attached Cam3 with a build and am not accessing the stream, as described in #90, to see if I can get a reproduction and associated |
|
Successful repro. Left the streamer alone for an hour as suggested in #90, tried to access the mjpg stream, "stale" message in log and just a server error in the browser. dmesgjournalctl -u camera-streamer*(ignore the Note how the stale message in the journalctl output only gets logged once I tried to access the mjpg stream in the browser. The server is now dysfunctional, neither of the streams nor the snapshot work. After a server restart however, everything works again. |
|
I hope this can be of use. I have multiple raspberry pi's( pi4, pizero)
Now the wifi ones.
But what I think might be causing the issue is that :
|
|
@foosel Hi! |
|
I have this same issue. Streams just stop working after a while. Wondering if there's a fix ? |
|
You could just restart the service via cron on a regular interval like every few hours. That could at least serve as a workaround until it is fixed. |
|
After digging around, apparently H264 encoding 1280p can cause voltage dips? On the kodi forums saw a reccomendation to add over_voltage=2 to the boot/config.txt file, and maybe just drop the res of the pi-cam to 720p, or the framerate to 15fps. I have made these changes on my mainsail system and will update if things stay stable |
|
I have noticed that once my Rpi 4 with klipper starts printing, the camera invariably stops working. |
No crashes of the webcam after these changes so far. |
|
@foosel Please check out my comments. The tweaks here have fixed the camera issue for me. |
|
Saw the comments, that isn't a solution for the issue however that will work for the majority I fear. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes, after a while streams just die. WebRTC shows nothing, mjpg streams throws a server error.
This happens if the camera is left running for a while, sometimes an hour, sometimes a day.
Anyway, I think the software detects a stale stream and tries to restart it but it still doesn't work. Restarting the entire service works just fine. Any idea what could cause this?
Here is the log:
The text was updated successfully, but these errors were encountered: