-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebRTC stream stops working #139
Comments
Woops this seems to be a camera-streamer bug. Will test some things and report back here before closing. |
I increased my RPi video ram from 160 to 256mb and this particular issue seems to be gone, or at least havnt happened for 12+ hours. |
increasing the GPU memory also resolved this issue for me. Should we take this up into documentation/readme? |
Increasing video ram did not fix the issue for me. It still fails after a while, streaming 800x600 resolution from USB webcam. |
Still an issue. I have 2 printers same setup and one works while the other just stops. |
still an issue..my rtc feed keeps stopping with both of my cameras. GPU memory set to 256.. |
I can confirm I have the same issue on both my Voron zero and 2.4 mainly with raspicam v1. The voron 2.4 is also running a logitech USB webcam, which keeps running significantly longer compared to the raspicam but eventually also goes black. a reboot solves the issue. both systems: Raspicam v1: /base/soc/i2c0mux/i2c@1/ov5647@36 gpumem: 128 |
Even with gpumem 256, the WebRTC for the raspicam still stops streaming. |
Forgot to reopen this issue. Can you guys please try to use |
|
Inside the crowsnest.conf under custom_flags |
Literally just worked it out as you replied :P Thanks ! |
Also just as an overall information for this. We couldn't reproduce this. So please attach a debug log next time with the issue reproduced, that we can maybe try to make some assumptions based on the output. |
With --camera-force_active=1 flag in combination with gpumem=256 I have had no more issues. After 48hr+ both cameras are still running. I have attached my log file. Perhaps we just need to update the documentation. I will report back if I encounter any more issues. |
@SaltyPaws thank you for the confirmation, that this works for you too. Next time a debug log would be nice. To create one, just set |
To further confirm this is the right fix, after 5 days, my USB camera shutdown, it did not have --camera-force_active=1 in the config. The Raspicam V1 was still up and running (it has the flag). Wow, wait 5 days to confirm a bug, I would call that hard to find! I will update the flag for both cams, and change gpumem back to 128 to test. |
Looks like |
@SaltyPaws Just for your information. |
We had to remove this parameter from default values as it causes problems with some printers #202 v4.0.5 has it set by default and v4.1.0 removed that default again. |
I've just had this happen as well with a generic USB cam. Logs indicate no issue, crowsnest looks normal. A restart fixes it but it goes offline within three to four days. I just restarted the Pi, crowsnest has been updated to v4.1.0 and Edit: The camera has just gone offline again, I've restarted crowsnest and its blank. Unsure what happened, crowsnest logs look fine. Going to try this solution and see how long it holds. |
This shouldn't help in any way for this. It seems like there was a bug with ustreamer in the beginning, that one is already fixed for quite some time. Also this problem is about camera-streamer and not ustreamer. Within 3-4 days I would consider fine. camera-streamer WebRTC isn't perfect, but this issue is something that is pretty hard to debug as it seems like appearing at random. I also recommend everyone to always attach a log as there are some good and maybe helpful informations about your setup. |
I'm running into this issue as well, I have a debug I am on a Raspberry Pi 3b+ using pi camera v1.2, I've set gpu memory to 256 and also added |
I get this issue with RTSP streams too - after a while they just stop working. Usually restarting crowsnest fixes the issue, unless it kernel panics the Pi, of course Log attached. |
@recrudesce Ofc the rtsp will break down too. Both are provided by camera-streamer. |
log uploaded, no idea why github didn't like it before. The kernel panic happens sometimes if I restart the service after it stops working. Not all the time, but sometimes. Then the SSH connection dies and the only way I can get back into the Pi is to physically unplug it to power it down. I do use the parameter, yeah. |
I recommend to remove that parameter again. Your camera-streamer is restarting every 20s. |
I think this is a camera-streamer issue, because running camera-streamer separately (without crowsnest), I still get the crashes on service restart, and webrtc just stopping. I'll raise an issue over there. |
Crowsnest is just starting camera-streamer for you with maybe some extra parameters, like we tried with |
This comment was marked as off-topic.
This comment was marked as off-topic.
@g14nluc4 please do not write your problem in any issue. If you need help/support, you are generally in the wrong place in the GitHub issue tracker. there is more information here: https://docs.mainsail.xyz/faq/getting-help |
What happened
Installed the latest version with all the compiling etc, got it running with WebRTC it was very nice for a while, but after a few minutes/hours it just stops working. /stream and /snapshot still works but not /webrtc
It starts working again if I restart crowsnest service from within mainsail.
Ive reverted and disabled RTSP and only running MJPG again. Not a big deal, I just wanted to report this.
What did you expect to happen
WebRTC streaming working indefinitely
How to reproduce
This is on my MainsailOS 1.0.1 RPi 3 b+ fitted with a Logitech C270 USB camera. Reproduced by running WebRTC for a while in Mainsail (with a web client open for approx an hour or so).
Additional information
I didn't find any errors, and cpu/mem usage of host was ok, but I found a few suspect websocket lines in journal.
crowsnest.txt
suspect.txt
The text was updated successfully, but these errors were encountered: