Unable to stop cameras screen rotation

[SemoTech]

Hello, I just installed RpiSurv on a fresh image of Raspian 10 Lite & updated to latest versions. Git download & install of RpiSurv went smoothly, and I was able to both get the demo running as well as configure my RTSP cameras with a single display.

I configured 6 cameras and used the "nr_of_columns: 3" variable to allow RpiSurv to auto layout the screen as a 3x2 layout. Worked great.

The issue I am having is that about every 30 seconds the auto-rotation kicks in and tries a single full screen (with the message "All streams for this screen are not connectable :-(") and then about 30 seconds later it switches to either 2 of my cameras loaded side by side, 3 of my cameras loaded side by side, or back to the single large screen with the error about no stream, then eventually back to my 6 cameras screen/layout.

I tried everything to prevent this form happening, including uncommenting and setting "disable_autorotation: True" in display1.yml, I tried adding "duration: 3000000000", and even renaming "display2.yml to display_2.yml, while restarting the RpiSurv service after each change, with no success.

Any ideas how to stop the autorotation permanently? I just want to permanently display my 6 cameras....

Thanks.

[SvenVD]

Hi, pls provide your config. I guess there is an error in that. disable_autorotation: True is the correct config, make sure you put in the right place with the correct indentation see https://github.com/SvenVD/rpisurv/blob/v3_latest/surveillance/conf/display1.yml

[SemoTech]

Sure thing @SvenVD, please see YML file I used ("/usr/local/bin/rpisurv/conf/display1.yml") HERE (File was originally edited on the Pi via SSH and then downloaded with SFTP. The RTSP URL's are sanitized)

Originally I had left "_disableautorotation: False" commented, then tried to uncomment it, and even changed to "_disableautorotation: True", but no effect! Same for "duration: 3000000000"

Please advise if anything is not indented as expected as I cannot seem to find any issues... Thank you.

[SvenVD]

The configuration file seems good, the way you are describing seems like Rpisurv is not reading the the config file. Did you restart Rpisurv after the changes?

Can you provide debug logs: https://www.tapatalk.com/groups/rpisurv/guidelines-t119.html that way we can see if Rpisurv loaded the settings matching the config file you uploaded

[SemoTech]

Hi @SvenVD It must be reading my config file as it is rendering the RTSP streams I put in it from all 6 cameras!

[SvenVD]

What is in display2.yml?

[SemoTech]

I have renamed "display2.yml" to "display_2.yml" in a futile attempt to stop the layout changes by "hiding" it.

[SvenVD]

I am puzzled.

Can you provide debug logs: https://www.tapatalk.com/groups/rpisurv/guidelines-t119.html that way we can hopefully see more

[SvenVD]

I am just thinking that what you are describing is not the autorotation, but rpisurv detecting streams that are not connectable and thus tries to redraw the screen with the ones it still have left ( and later on it detects them reachable again and redraws the screen again). We can verify this theory without debug logs. Just provide output of /usr/local/bin/rpisurv/logs/main.log

[SemoTech]

Sorry this took a while to enable debug, capture and sanitize the files. Here is main.log and daemon.log

While you may be right, the same RTSP streams are solid in VLC running on my computer, yet seem to disconnect very often on rpisurv, so thats another issue. But they are not only dropping and re-connecting, the screen layout is also changing from 3x2 to 1x3 to 1x1 and back, almost randomly... But most of the time it stays on 3x2 layout and shows the back "connecting" background for the cameras it is trying to connect to.

P.S. Two (2) of the six (6) cameras have same RTSP URL, and that is by design, so can be ignored.

[SvenVD]

By default Rpisurv changes screen layouts on dropped streams also. A quick glance on your logs seems to confirm the theory. It is not the autorotation that is kicking in, but Rpisurv detecting streams are not connectable and trying its best to only display the connectable onces ( sometimes there are none, so it tells no connectable stream detected ).

You could try to increase the probe timeout for each stream to something bigger:

#Increase probe_timeout if you have streams that are slow to connect to. If they longer then probe_timeout seconds then rpisurv #will consider them unconnectable
#Default to 3 seconds
          probe_timeout: 3

Otherwise you should find out why the cameras are sometimes less responsive or the network that is less responsive.

[SemoTech]

Thanks @SvenVD. I tried to use "probe_timeout: 3" but the camera streams fail to start up/render at all when I do!

And lost as to why would they work perfectly on every other device and in VLC on my computer, but not on Rpisurv on a Pi 4B with 2GB ram?

[SvenVD]

Sorry I was maybe a bit unclear. probe_timeout: 3 is the default, try setting it to probe_timeout: 20 or 10

[SvenVD]

And lost as to why would they work perfectly on every other device and in VLC on my computer, but not on Rpisurv on a Pi 4B with 2GB ram?

I have no idea, are the cameras taking streams from other sources, cameras could be overwhelmed by the extra streams the Rpisurv is asking, just a guess

[SemoTech]

Sorry I was maybe a bit unclear. probe_timeout: 3 is the default, try setting it to probe_timeout: 20 or 10

Yes, and I made a typo but if I set it to "anything" (uncomment it) the streams will not initialize.

[SvenVD]

if probe_timeout: 20 still times out then you have a real problem on your camera or network side of things. Is the NVR overloaded perhaps?

[SemoTech]

I will try it again with "20". But again my cameras work smoothly everywhere else!

By the way, how do we disable the debug logs i had to enable to get the files to you?

[SvenVD]

Disable debug sed -i 's/level:.*/level: INFO/g' /usr/local/bin/rpisurv/conf/logging.yml; systemctl restart rpisurv

[SemoTech]

Thanks. Will do that then will try a setting of "20" for the probe_timeout

[SvenVD]

I will try it again with "20". But again my cameras work smoothly everywhere else!

I just can see what the logs say, and they say that the connection to the stream timeout ... maybe try a "ping" command from Pi to NVR and see if that stays stable to start with.

[SemoTech]

I did the "probe_timeout: 20" and all six (6) cameras started. On the ping I was getting about 1.5ms to 3ms roundtrip latency from the Pi to the NVR, so at a loss, literally...

Seems a bit better but 1st camera stream just dropped off again from the 3x2 layout, and then came back... Then display went to a 2x1 and back to a 1x1 layout...

Any way to force the layout not to change?

[SvenVD]

Any way to force the layout not to change?

disable_probing_for_all_streams: True will have that side effect. However the healing logic will be disabled also

[SemoTech]

Any way to force the layout not to change?

disable_probing_for_all_streams: True will have that side effect. However the healing logic will be disabled also

I can surely try. Let me do that now...

[SemoTech]

I uncommented and set "disable_probing_for_all_streams: True" but the streams do not start at all now. There is a bit of flicker on the display but the streams do not appear...

[SvenVD]

Well, I guess it is because they really can't be streamed, due to some external factor. Is the NVR overloaded?

[SemoTech]

Well then why they start streaming again if I comment the line "disable_probing_for_all_streams: True"? If it was due to the cameras they should not render at all...

No, NVR is running at about 35% utilization and all cameras display perfectly on my phone and tv, just not via Rpisurv...

[SvenVD]

Well then why they start streaming again if I comment the line "disable_probing_for_all_streams: True"? If it was due to the cameras they should not render at all...

disable_probing_for_all_streams only disables the health probes, so maybe a coincidence of flapping external factor, I don't know. If the option is enabled then Rpisurv does not autorestart anything so if they are not connectable at start then they will never connect again.

No, NVR is running at about 35% utilization and all cameras display perfectly on my phone and tv, just not via Rpisurv...

Maybe another approach is to try one stream, then two streams and so on until issues start appearing

[SemoTech]

Really appreciate all your help with this @SvenVD, but it is looking like too much time and effort exerted for little return and no real progress. Wish there was a way to disable the "optimization" but still keep the probing and auto-restart feature.

Anyway, given the cameras RTSP streams all work seamlessly and perfectly on my phone, TV & computer, maybe this is all due to the underperformance of the Pi itself. I will see if there is not some other dedicated hardware (not a Pi), able to display 6 or more RTSP streams that I could use "out of the box". Again, my thanks for all your efforts.

[SvenVD]

No prob. For the record, 6 rtsp streams normally should be able to run find fine with Rpisurv on a pi.

[SemoTech]

Just an update:

I connected the Pi 4B via Ethernet and got the pings to the NVR down to 2ms. The "connecting" screens and wild camera rotation and re-alignment stopped!

Sadly it seems my Pi 4B WiFi is not fast enough to handle multiple (6) RTSP streams, so only way to reliably use it with RpiSurv is hardwired.

Thanks again for all your help @SvenVD