I know we’ve seen this before many times and it is over in github issues as well, it seems to have happened more often with recent releases than before.
I wanted to move the topic here so that we can troubleshoot and once and for all find a permanent solution if possible.
I thought the viewer would skip the URL/asset if it encountered this problem, is that feature only in the developer or experimental version and not on stable version?
Just wondering, is some sort of email alert feature active on the Pro version of screenly when the viewer is down or experiences this error?
This happened overnight with that brand new setup from scratch of screenly with new Pi and new SD card.
The environment was set up so that I can rule out the causes that dont affect the device itself, such as placing the Pi connected to this TV right next to the access point, the device is still connected and online so it is not an issue of connectivity.
The URL/asset works at first, so what causes it to get this error at some random time later ? if the cause was hard-coded then it would always happen right after adding the asset/URL.
Ok, so I looked at both of the different Pi’s that on the same day had the same error, both showed the same behavior, before the asset stopped (both at the boardclock URL), the cron job started 10+ minutes later. I am not saying this has anything to do with the cron process but just stating the similarities for both.
Will keep updating this as I continue troubleshooting.
I have been taking packet captures on my firewall and have whitelisted the devices, so the possible issue of the asset/URL being blocked by a content filter and that causing the unable to load error gets crossed off. Reason why i thought that was one or the cause is because some people posting the issue mention they are at a school as well, so I just thought maybe the firewall was blocking something on the backend, but doesnt seem like it is.
Will continue to research because it happened today again so I need to look at backend logs for the Pi and the firewall.
I’m having the same problem and I’m not behind a firewall
I am working on this one and a few others as we speak, I will post back here with any relevant information once I isolate the cause.
The logs from today also show the last asset before “crashing” was https://weather.srly.io
I will disable the asset and leave others running to see if it only happens with boardclock asset, and weather/time one.
Also, just a suggestion in case you dont already do it, if you have ssh enabled and are not on your computer, you can use an app like juicessh to remote into the Pi and just run the sudo reboot command and get it up and running again for the time being…
For my part, yesterday I had the default that appeared with the Screenly Clock app that I have disabled but it started again today with another page.
How to enable SSH on screenly OSE? My technical skills are limited.
Thank you
Connect via the Console (CTRL + ALT + F1)
Login using your credentials (default is user: pi , pwd: raspberry)
Execute sudo raspi-config
Select Interfacing Options
Navigate to and select SSH
Choose Yes
Select Ok
Choose Finish
You should now be able to SSH into the Pi
It is highly recommended that you change the default password if you intend to connect your Pi to the outside world.
Reference: https://github.com/Screenly/screenly-ose/wiki#enabling-ssh
1 Like
Just an update to this, the weather.srly.io URL and boardclock.com both gave me unable to load issues, but once I removed them and left google slides or other URLs, the issue did not happen.
This issue has been linked to the uzbl browser and how it loads URLs, I have not tested experimental or development versions of screenly yet to see how this will affect your assets/URLs, but I know that the experimental version of screenly now uses something called Qt WebView instead to display web contents so if you want you can try that version if possible… I hear good things about it… remember to backup your assets… unless you can just simply add them then no need to backup, but always good idea to back up, I just know sometimes after a backup + restore, you might run into tiny glitches so you need to re-run the upgrade script and it’s just easier in my opinion to start clean with new assets database if at all possible…
https://doc.qt.io/qt-5.9/qtwebview-index.html
