Issue with freeze

[wifispray]

Hi All,

Has anyone experienced an issue where streams will just freeze? No particular reason or time this happens. But normally within the 1:30-2hr mark.

The only way to recover is to manually stop and start the service. Maybe im missing some kind of script or cron job. This could be normal or expected behaviour....

Not sure if this is omxplayer crashing or other

[Anonymousdog]

This hasn't been reported before. Omxplayer must still be reporting through DBUS that streams are still playing, else the repair routines would restore the feeds.

Running 'sudo /usr/bin/displaycameras status' when the streams freeze may yield more information.

Andy

On Sat, Apr 18, 2020, 3:02 AM wifispray notifications@github.com wrote:

Hi All,

Has anyone experienced an issue where streams will just freeze? No particular reason or time this happens. But normally within the 1:30-2hr mark.

The only way to recover is to manually stop and start the service. Maybe im missing some kind of script or cron job. This could be normal or expected behaviour....

Not sure if this is omxplayer crashing or other

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKPILEQSQEI2OWPPX5LRNFF73ANCNFSM4MLHRC2A .

[wifispray]

Hey

all screens now frozen, at the same point.... this is the output

pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 40917sec NE is Playing rtsp://172.16.201.1:7447/5d2607e5207da9fc0690e014_2 at 40909sec South is Playing rtsp://172.16.201.1:7447/5dbd7ecf207d9787c719ba19_2 at 40903sec West is Playing rtsp://172.16.201.1:7447/5da5cae8207dfa7c43866fc2_2 at 40898sec Vestibule is Playing rtsp://172.16.201.1:7447/5d260899207da9fc0690e048_2 at 40890sec SW is Playing rtsp://172.16.201.1:7447/5d1f61ee207d1fa8425db8ae_2 at 40886sec

[Anonymousdog]

Do those times progress if you run that repeatedly? Omxplayer is (obviously) not seeing a failure to play the streams. If it doesn't see a problem, it won't report one via DBUS, and the repair functions won't fix it. Is there anything else notable in your environment? Can you play any of these streams on another device while they are frozen here?

Thanks, Andy

On Tue, Apr 21, 2020, 1:39 AM wifispray notifications@github.com wrote:

Hey

all screens now frozen, at the same point.... this is the output

pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 40917sec NE is Playing rtsp://172.16.201.1:7447/5d2607e5207da9fc0690e014_2 at 40909sec South is Playing rtsp://172.16.201.1:7447/5dbd7ecf207d9787c719ba19_2 at 40903sec West is Playing rtsp://172.16.201.1:7447/5da5cae8207dfa7c43866fc2_2 at 40898sec Vestibule is Playing rtsp://172.16.201.1:7447/5d260899207da9fc0690e048_2 at 40890sec SW is Playing rtsp://172.16.201.1:7447/5d1f61ee207d1fa8425db8ae_2 at 40886sec

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-616963886, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKI3FFPZ6CHJUD655ULRNUWSBANCNFSM4MLHRC2A .

[wifispray]

Hey thanks for reply...

Do those times progress if you run that repeatedly? Yes they do....

pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 7256sec pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 7259sec

Is there anything else notable in your environment?
Not im aware of...

Can you play any of these streams on another device while they are frozen here? Yes I can play on VLC on my PC while still failed on PI. Only way to recover is to stop and start displaycamera with

sudo /usr/bin/displaycameras stop sudo /usr/bin/displaycameras start

[Anonymousdog]

That's some kind of omxplayer failure (or maybe resource exhaustion on the Pi. Model and mem split?

On Tue, Apr 21, 2020, 3:43 PM wifispray notifications@github.com wrote:

Hey thanks for reply...

Do those times progress if you run that repeatedly? Yes they do....

pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 7256sec pi@raspberrypi:~ $ sudo /usr/bin/displaycameras status SE is Playing rtsp://172.16.201.1:7447/5daf2378207dcbbc62ea7d61_1 at 7259sec

Is there anything else notable in your environment? Not im aware of...

Can you play any of these streams on another device while they are frozen here? Yes I can play on VLC on my PC while still failed on PI. Only way to recover is to stop and start displaycamera with

sudo /usr/bin/displaycameras stop sudo /usr/bin/displaycameras start

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-617374347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKJHWDVNBLXDUFQ47RDRNXZMLANCNFSM4MLHRC2A .

[wifispray]

cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

Hardware : BCM2835 Revision : c03111 Serial : 10000000608ba8c3 Model : Raspberry Pi 4 Model B Rev 1.1

nano /boot/config.txt gpu_mem=256

[Anonymousdog]

I got nothing. Is the RPi multi-tasking at all?

Andy

On Wed, Apr 22, 2020, 1:36 AM wifispray notifications@github.com wrote:

cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 1 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 2 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

processor : 3 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 108.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

Hardware : BCM2835 Revision : c03111 Serial : 10000000608ba8c3 Model : Raspberry Pi 4 Model B Rev 1.1

nano /boot/config.txt gpu_mem=256

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-617561173, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKLV5CNFHUM5BXVLBBLRNZ637ANCNFSM4MLHRC2A .

[nmcrae85]

As in running any other tasks? No

Only other slightly different config from a standard deployment is that I have multi vlan setup. However all Cams, PI etc are on the same L2 domain and not traversing any firewall etc

FYI - using a different github account. 😬

[wifispray]

Is it worth running the "Latest Commits" version? A flash of RP lite? Im using the noob desktop version Also the latest version of omxplayer/screens...

[Anonymousdog]

Shouldn't matter. We have VLANs in use too.

I'm assuming raspbian and omxplayer are up-to-date?

Andy

On Wed, Apr 22, 2020, 3:51 PM nmcrae85 notifications@github.com wrote:

As in running any other tasks? No

Only other slightly different config from a standard deployment is that I have multi vlan setup. However all Cams, PI etc are on the same L2 domain and not traversing any firewall etc

FYI - using a different github account. 😬

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-617999191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKPVQTSXKCWMVV2M5Z3RN5DFNANCNFSM4MLHRC2A .

[wifispray]

Yep all up to date. The interesting thing is, I just booted up another (older PI) running older RPI code (Jesse 8). With the same config file and it works... This is running

omxplayer - Commandline multimedia player for the Raspberry Pi Build date: Fri, 23 Sep 2016 00:56:49 +0000 Version : dfea8c9 [master] Repository: https://github.com/popcornmix/omxplayer.git

screen --version Screen version 4.02.01 (GNU) 28-Apr-14

pi@raspberrypi:~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

[wifispray]

Sorted out the problem. Turned out to be a fault PI.... Some hardware issue on the SD card.. A quick question if you can answer. For this example - https://raw.githubusercontent.com/Anonymousdog/displaycameras/master/example_layouts/layout.conf.large_left

Is it possible to have only one of the panels rotate the video display? In this case top left large?

[wifispray]

A quick question if you can answer. For this example - https://raw.githubusercontent.com/Anonymousdog/displaycameras/master/example_layouts/layout.conf.large_left

Is it possible to have only one of the panels rotate the video display? In this case top left large?

[jasonpcrowley]

We have experienced what I believe is the same problem. Omxplayer believes the display is working, and displaycameras status looks fine, but the display is clearly frozen. Subscribing to the same stream elsewhere shows current images. I have only seen one of eight streams stop in my scenario. We're monitoring cameras across a VPN, so it could be some sort of Internet blip causing the failure.

I could isolate the failed camera Here is what I did to detect from the OS which camera is failing.

pi@raspberrypi:~ $ ps -e | grep omxplayer.bin
  919 ?        00:10:13 omxplayer.bin
  992 ?        00:10:10 omxplayer.bin
 1065 ?        00:10:28 omxplayer.bin
 1138 ?        00:11:11 omxplayer.bin
 1211 ?        00:11:08 omxplayer.bin
 1357 ?        00:10:43 omxplayer.bin
 6801 ?        00:18:17 omxplayer.bin
21210 ?        00:06:45 omxplayer.bin
pi@raspberrypi:~ $ sudo netstat -ntp | grep omxplayer.bin
tcp        0      0 172.26.210.106:58012    172.28.18.24:554        ESTABLISHED 1065/omxplayer.bin
tcp        0      0 172.26.210.106:58646    172.28.18.25:554        ESTABLISHED 1138/omxplayer.bin
tcp        0      0 172.26.210.106:55794    172.28.18.27:554        ESTABLISHED 21210/omxplayer.bin
tcp        0      0 172.26.210.106:60744    172.28.18.26:554        ESTABLISHED 1211/omxplayer.bin
tcp        0      0 172.26.210.106:40034    172.28.18.28:554        ESTABLISHED 1357/omxplayer.bin
tcp        0      0 172.26.210.106:47298    172.28.18.22:554        ESTABLISHED 919/omxplayer.bin
tcp        0      0 172.26.210.106:54908    172.28.18.23:554        ESTABLISHED 992/omxplayer.bin

As you can see, PID 6801 is running but there's no TCP stream to it. I used that to develop this bit of code to go into the repair section of the displaycameras script.

if [ `pgrep -c omxplayer.bin` -gt $cameras ] || [ `netstat -ntp | grep -c omxplayer.bin` -lt $cameras ]
then
        $0 restart
fi

That replaces a bit of code that was already there just looking for too many omxplayer processes. The displaycameras repair runs every minute, so it fixed the problem within a minute. After I tested it, I haven't seen the problem occur again.

[Anonymousdog]

Not currently

On Tue, May 12, 2020, 3:47 AM wifispray notifications@github.com wrote:

A quick question if you can answer. For this example - https://raw.githubusercontent.com/Anonymousdog/displaycameras/master/example_layouts/layout.conf.large_left

Is it possible to have only one of the panels rotate the video display? In this case top left large?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-627174136, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKIJW6HR4FNTHBZHN4TRRD5KXANCNFSM4MLHRC2A .

[WirelessMind]

I use displaycameras with 2 cam. After a few hours, one of them turns black and remains so until the RPI reboot. It has no effect if I restart displaycameras. Obviously the cam actually works as I view it correctly on other clients.

root@rpi:~# /usr/bin/displaycameras status Cortile is NOT playing WMeyes is Playing http://_user:password_@192.168.0.110:8080/stream/getvideo at 119sec

root@rpi:~# cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

I installed a new Raspbian lite yesterday, changed the GPU memory to 256Mb and installed only displaycameras.

[Anonymousdog]

A service restart kills all instances of omxplayer on the RPi; so, honestly, this points to something aside from the package or your configuration. Never the less, please post redacted copies of your config files as attachments.

Are results any different if you stop the service, allow the RPi to idle for a minute or so, then start the service?

It does appear that omxplayer is aware of the playback failure, is reporting that properly through DBUS, and that means the service is trying to repair that feed every minute (and is unable to). That repair process terminates the omxplayer instance responsible for that feed and restarts that instance. That should work.

For more diagnostic data, after symptoms present, please, try to play the offending feed via VLC on another computer and/or on the RPi (via VLC command line) immediately after stopping the displaycameras service.

Thanks, Andy

On Wed, May 20, 2020 at 4:35 AM WirelessMind notifications@github.com wrote:

I use displaycameras with 2 cam. After a few hours, one of them turns black and remains so until the RPI reboot. It has no effect if I restart displaycameras.

root@rpi:~# /usr/bin/displaycameras status Cortile is NOT playing WMeyes is Playing http://*user:password*@ 192.168.0.110:8080/stream/getvideo at 119sec

root@rpi:~# cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

I installed a new Raspbian lite yesterday, changed the GPU memory to 256Mb and installed only displaycameras.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-631327566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKM5LQDWIIBKILGUNDTRSOI5LANCNFSM4MLHRC2A .

[WirelessMind]

Conf.zip

Hi, I have attached the files. For the moment I had set up a raspberry reboot, via crontab, every day at 00.00 AM and 00.00 PM, so if it got stuck, with the restart it would work again. Now I took it off to do the tests you asked me.

As soon as it freezes, I try to stop the service and restart it after a few minutes.

I will also test with VLC and let you know. However when the symptoms showed up, I had already tried (but without stopping the service) to open the feed on VLC and it worked.

Thanks

[WirelessMind]

Since yesterday, it has never been freeze until now!

[Anonymousdog]

Remove the window name "on_screen3". You only have two positions defined; so, there should only be two named windows.

Minor (not probably contributing to the issue). Window positions should be, 0 0 439 239 0 240 439 599 Particularly if the streams are natively 480x240 and 480x360(?), existing config forces omxplayer to scale to 481x241 (which consumes resources). Existing config technically overlaps one pixel horizontally. Are these the native resolutions of your feeds? The second is standard 4:3 ratio, but the first is 2:1 (which is odd). This whole layout is odd though: Do you honestly have a 480x600 display (maybe 600x480 in portrait mode)?

Thanks, Andy

On Mon, May 25, 2020 at 6:54 AM WirelessMind notifications@github.com wrote:

Conf.zip https://github.com/Anonymousdog/displaycameras/files/4676836/Conf.zip

Hi, I have attached the files. For the moment I had set up a raspberry reboot, via crontab, every day at 00.00 AM and 00.00 PM, so if it got stuck, with the restart it would work again. Now I took it off to do the tests you asked me.

As soon as it freezes, I try to stop the service and restart it after a few minutes.

I will also test with VLC and let you know. However when the symptoms showed up, I had already tried (but without stopping the service) to open the feed on VLC and it worked.

Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-633513226, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKK5C6FMK4LAOIARMGTRTJE6LANCNFSM4MLHRC2A .

[WirelessMind]

Ok, I removed "on_screen3". I forgot it when I was trying to display the black part instead of the shell. My screen reasolution is 800 x 480 pixels (https://thepihut.com/products/official-raspberry-pi-7-touchscreen-display), but the two webcams have strange resolutions. Now I set them up like this: window_positions=(

Cortile

"0 0 479 239" \

WMeyes

"0 240 479 599" \ ) However, since yesterday he has never been freeze.

[WirelessMind]

Are results any different if you stop the service, allow the RPi to idle for a minute or so, then start the service? I stopped the service for a minute and restarted it. But nothing to do, it doesn't work :( May 27 10:48:48 DomusEye displaycameras[25601]: Camera Display Stopped May 27 10:48:48 DomusEye systemd[1]: displaycameras.service: Succeeded. May 27 10:48:48 DomusEye systemd[1]: Stopped Displays camera feeds for monitoring. May 27 10:49:01 DomusEye CRON[25623]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:50:01 DomusEye CRON[25647]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:51:01 DomusEye CRON[25658]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:52:02 DomusEye CRON[25669]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:53:01 DomusEye CRON[25681]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:53:39 DomusEye systemd[1]: Starting Displays camera feeds for monitoring... May 27 10:53:39 DomusEye displaycameras[25690]: Blanking screen May 27 10:53:39 DomusEye displaycameras[25690]: Starting omxplayer for Cortile May 27 10:53:44 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 0 May 27 10:53:45 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 1 May 27 10:53:47 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 2 May 27 10:53:48 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 3 May 27 10:53:50 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 4 May 27 10:53:52 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 5 May 27 10:53:53 DomusEye displaycameras[25690]: Cortile failed playback May 27 10:53:53 DomusEye displaycameras[25690]: Starting omxplayer for WMeyes

For more diagnostic data, after symptoms present, please, try to play the offending feed via VLC on another computer and/or on the RPi (via VLC command line) immediately after stopping the displaycameras service. Cam in VLC works

[Anonymousdog]

Works on the RPi in VLC?

On Wed, May 27, 2020, 4:55 AM WirelessMind notifications@github.com wrote:

Are results any different if you stop the service, allow the RPi to idle for a minute or so, then start the service? I stopped the service for a minute and restarted it. But nothing to do, it doesn't work :( May 27 10:48:48 DomusEye displaycameras[25601]: Camera Display Stopped May 27 10:48:48 DomusEye systemd[1]: displaycameras.service: Succeeded. May 27 10:48:48 DomusEye systemd[1]: Stopped Displays camera feeds for monitoring. May 27 10:49:01 DomusEye CRON[25623]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:50:01 DomusEye CRON[25647]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:51:01 DomusEye CRON[25658]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:52:02 DomusEye CRON[25669]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:53:01 DomusEye CRON[25681]: (root) CMD (/usr/bin/displaycameras repair) May 27 10:53:39 DomusEye systemd[1]: Starting Displays camera feeds for monitoring... May 27 10:53:39 DomusEye displaycameras[25690]: Blanking screen May 27 10:53:39 DomusEye displaycameras[25690]: Starting omxplayer for Cortile May 27 10:53:44 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 0 May 27 10:53:45 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 1 May 27 10:53:47 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 2 May 27 10:53:48 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 3 May 27 10:53:50 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 4 May 27 10:53:52 DomusEye displaycameras[25690]: Waiting for Cortile omxplayer startup 5 May 27 10:53:53 DomusEye displaycameras[25690]: Cortile failed playback May 27 10:53:53 DomusEye displaycameras[25690]: Starting omxplayer for WMeyes

For more diagnostic data, after symptoms present, please, try to play the offending feed via VLC on another computer and/or on the RPi (via VLC command line) immediately after stopping the displaycameras service. Cam in VLC works

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Anonymousdog/displaycameras/issues/48#issuecomment-634524934, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIYIKJNFDUEXJ2NTBVSU43RTTIRJANCNFSM4MLHRC2A .

[WirelessMind]

I had tried with VLC on my pc because on the raspberry I only have raspbian lite and displaycameras. There is nothing more.

As soon as it crashes again I try, although I will have to install VLC.