select timeout #182
Comments
|
@mdevaev multiple cams definitely used to work before the new select() stuff, any idea what the issue might be? |
|
Actually I can see you are using an invalid frame rate, I think it has to be a whole number and will parse that as 0, doing whatever your camera does when asked to do 0. If the framerate is below one every 5 seconds, you'll want to give the For future enhancements, |
|
@jacksonliam With such a high resolution, I recommend increased timeout. In addition, the FPS is indeed incorrect, it must be an integer. @cgpeter96 Try option |
|
@mdevaev thanks ,I will try it |
|
Hi. I'm having exactly the same issue: when starting at the same time, after some seconds/minutes I always get the timeout (Note: by "some seconds" I mean something as short as 2 secs). If I start the one for /dev/video2 I runs fine until I start the other: then both get the timeout. This makes me think it might be a problem not related to mjpg_streamer, but to linux itself? (I'm running rev 501f636, on Linux archlinux 5.2.1-1-ARCH #1 SMP Sun Jul 14 19:29:00 UTC 2019 aarch64 GNU/Linux) |
|
It's on Raspberry Pi? |
|
sorry, my bad: Yes, on an RPi 3B+. |
|
Maybe you're right and the problem somewhere in the kernel. |
|
It definitely seems to be a system problem, rather than app-related. I have coded a simple mjpeg streamer variant, using restbed to serve the images, and I'm experiencing exactly the same issue: At some point in time, a select starts to timeout, and from that moment all selects will fail. As soon as I kill and restart the app, everything gets fixed. |
|
Hi, Same issue here : Running on Raspbian 10 (kernel 4.19.66-v7+) on RPI3 Can someone help us find what is the problem please ? |
|
Have you tried increasing the timeout? |
no, I just reduce the number of camera |
|
Tried with -timeout 15 with no success, still the same issue.
but no success either :( |
|
Does your camera work with another program? |
|
Just collect photos,so I use another strategy that we use |
no, but it's work well on PC(x86-64) |
|
@cgpeter96, @lbr38 - Sorry, I'm a little confused. Do you solve your common problem? :) Be that as it may, more diagnostics are needed. It is necessary to rebuild mjpg-streamer in debug mode and post here the entire log of the program. Or there is an easier way. Try to use my https://github.com/pikvm/ustreamer, it's very similar to mjpg-streamer but contains many debug hints out of box: |
Thank you for your help, in my case the problem is not solved (still got timeout error) and I'd like to try ustreamer to get more logs but I have issues while building it (i'm on Raspberry Pi3) : |
|
Install libevent, libjpeg and libuuid |
|
Can you tell me the equivalent packages names for RPi (debian) ? Thank you |
|
Should be fine. run |
|
Thanks, so here are some logs from ustreamer after 5sec of execution. I don't know if this will help. Also here are informations of my camera device : |
It changes everything! @jacksonliam I have an idea. In some cases, a timeout is not a fatal failure. You could add an option that would enable behavior in which the device will be reinitialized during a timeout or other error. This is not the fault of my patch. I investigated this question - without my patch mjpg_streamer simplye hangs in this case. @lbr38 ustreamer correctly handles such situations and automatically restarts the stream on error or timeout. You can use it for your purposes if you want. If you have problems or questions, you can create an issue in my repository. |
|
Okay I guess I will use ustreamer as you suggested, but will need some help to set up the http server. I'll open a new issue in your repository. Thank you for all |
Thanks, a ll think about making a change in this area, do you have to re-init everything or just carry on with more selects? |
|
I think you can re-init only v4l2 code. I.e. close device, open again and etc. https://github.com/pikvm/ustreamer/blob/master/src/stream.c#L128 |
@jacksonliam, in a general sense, you might also consider a second parallel option to have mjpg-streamer terminate on errors like this. From a user perspective, this select() timeout is a frustrating issue, as the server side happily continues running... so camera systems silently fail, yet the host doesn't have the ability to recover. If mjpg-streamer had exited on the failure, it would have been possible to wrap the command in a script to auto-restart, providing an additional layer of fault recovery possibility. That's not to say that this issue shouldn't be patched by restarting the input component within mjpg-streamer, as that is clearly the better solution. But for general runtime faults with the camera inputs, continuing to run isn't necessarily always helpful, even if it is possible to continue. Thanks for looking into this! |
|
@mdevaev Thanks for the pointer to ustreamer! So far it's completely stopped our constant random streamer lockups on multi-camera systems. |
|
I also have similar problem. I'm using raspberrypi 2B+ and two same type cameras. I added systemd script for executing on boot and restart on failure. However, there is a problem that mjpg_streamer keeps running after some error occured in input_uvc. |
|
I had a |
|
Having the same problem. I have two webcams (one Logitech, one Razer). If I have both plugged into the same Raspberry Pi then either one will work fine if mjpg-streamer is started first for that camera. When mjpg-streamer is started for the second camera I never get an image and it ends up in select() timeout. I have tried increasing gpu_mem to 256 with no effect. I have tried increasing the timeout with no effect. I have tried decreasing the frame rate and resolution with no effect. The first started always works and the second started always times out, with the first still working fine. |
|
Definitely got enough power for the pi and both cameras? Assume this is running multiple instances of mjpg-streamer? Is the issue the same if you run two input plugins under one mjpg steamer? Select timeouts is usually the OS / v4l2 not returning a frame, it's not usually an mjpg-streamer issue. |
|
Running |
This is not true. I use OBS and everything is fine. After switching to I would think of v4l2 loopback in OBS, to workaround this issue. |
|
I am afraid I have found the solution. Turned out pretty simple. It is to reset the USB HDMI capture device every time the line First, locate your USB device by Next, use the above information to fill in the following Python code: On Ubuntu, this import usb.core
from usb.core import find as finddev
dev = finddev(idVendor=0x<idVendor> idProduct=0x<idProduct>)
dev.reset()Finally, initiate the streamer. When any error shows up, execute this script exactly once, manually. You will see the issue has been fixed immediately. I believe there is a lot more to do in PiKVM for fixing this issue. But it could be rather simple. I would recommend setting a back-off period at 1 minute for running this Python script, to avoid frequently resetting the USB device. |
hello,all.
I install mjpg-streamer in Raspberry 3B+。
I want to drive three cameras to capture images, but I have encountered such a problem.
If I open tow cam,one of them will occur this problem ,maybe both:
if I open three cam,two of them will occur this problem ,maybe one:
the command
The text was updated successfully, but these errors were encountered: