Hi !
Screenly OSE crashes and causes an error message on the web pages after a while.
Here is the error message:
Unable to load page
Problem occured while loading the URM
https://www …
Error performing TLS handshake: An unexpected TLS packet was received.
This has been reproducible on a Raspberry PI 3 B +, as well as on a Raspberry 2, the problem is identical. Also tested on 2 different internet connections and recurring problem.
It is really binding and it forces to electrically disconnect the device for it to go again.
version of screenly ose: image_2018-11-23-Screenly-OSE-lite
The blocking pages were the screen time we app app itself or a web page itself.
See screenshot
@androidofon - Can you look at your journalctl logs and tell me what was the last asset that worked?
on console type: journalctl
one way i like to skim through is pressing space bar which will advance the page/logs by as many as your screen could display, thus allowing you to reach the end faster or you can filter by typing:
journalctl | grep "Mar 01"
which will display all lines that contain that date… pretty self-explanatory, when you post the results here of the few lines where the last asset played, use three ``` at beginning and at end so that it posts here properly.
( this post could be duplicate of Unable to load page - Error performing TLS handshake )
I’m trying to send you this as soon as possible, my raspberry is off because of this bug.
@androidofon
Since I see the URL you are having problems with, I will add it to my screenly test Pi as well and see what I get.
But for the meantime, I may have a solution for you…
Basically, with the production branch and uzbl, I have seen many sites give these errors except google.com and most non-https sites, but one way I’ve found to workaround this has been to have the pi access a local intranet basic HTML file with an iframe and in this iframe that page would be there, so since the original local page should not get such TLS handshake packets/errors, that page should always load, and if anything goes wrong inside the iframe of the page, it can always reload automatically and have a meta content refresh that automatically refreshes the page every so often you like (in seconds)…
here is one simple html file i created for you to use for your page, you need to save the file as .html
<!DOCTYPE html>
<html>
<head>
<META HTTP-EQUIV="refresh" CONTENT="60">
<style>
body {
background-color: lightgray;
}
</style>
</head>
<title>Class Timetable</title>
<body>
<iframe style="position:absolute; height:99%; width:99%" src="https://www.mywellness.com/keepcoolaixlesbians/classtimetable" frameborder="0" scrolling="no"></iframe>
</font>
</body>
</html>
.
Here is how it looks like when it loads on the iframe of the local file:
And this is how the screenly weather page looks like inside the iframe with 99% height and width so that the scrollbars dont show due to CSS styling used:
@vpetersson -
How would users easily upload local html files to the screenly assets folder to use and not just limited to images? edit mimetypes? not sure if this was ever discussed and a decision was made to only allow certain types… but when the alert or error comes up:
Server Error: Invalid file type
It does not let the user know which file types are accepted though… if I remember correctly an older version of the upload did say the limitations…
I don’t want to start suggesting users use something like WinSCP and put files manually inside the screenly assets folder and then add URL with the actual Pis localhost address to load such uploaded files… method would seem antiquated.
How would users easily upload local html files to the screenly assets folder to use and not just limited to images?
Honestly, it is a bad idea to accept HTML files as assets and it opens up a can of worm. HTML files are designed to be served from a web server. If they are not (i.e. they are served using file://[...], a lot of things will break. Hence, I’ve told previous developers to not allow HTML files.
If we were to accept HTML files, we would have to create some kind of web server to serve these pages from. That in turn opens up a bunch of security issues.
If a user wants to use HTML pages, a much better solution is to serve them from a proper webserver (ideally running elsewhere, but even running them through say Nginx on the Pi would be better).
Definitely hear you about the security issues just allowing other file types…
I just run into these scenarios where I see creating some websites that could be accessed from the Pi itself and screenly being able to access it from localhost, not file://[…], would be an optional feature for those that could benefit from it…
Again, this is just because of the issues that uzbl has where it could and does crash on certain websites or rendering certain components, and since the screenly-viewer itself may not be crashed, recuperating from an unresponsive iframe-URL vs direct URL is easier and does happen… (i have not had the “Unable to load” message ever since I load the URL from within the iframe of a local html file, even if the content doesn’t display, uzbl is able to recover when receiving the python command to move onto next asset, this is an ongoing test that has worked)
I also know once QtWebview is up and running this may not be an issue, but this is just a separate reason, which is to allow local “intranet” websites from being accessed without user having to install their own webserver since nginx is already on Pi after screenly install.
.
Yes this is what I meant, where a user is ideally uploading to the same Pi’s nginx share and can run these local HTML files from there.
I would really like to hear feedback from @androidofon to see if his screenly still crashes after doing this local html file workaround…
@ealmonte32 @vpetersson
Thank you for your help.
So as I understand it and in order to get around my problem (which is also happening with Screenly’s webapp time), I have to create a web page that I host on a server? Then I will use this new address to integrate into my playlist.
Is this a temporary solution pending final debugging?
I’m running out of time to put this in place today, I’m trying to get you back this weekend.
Well, the workaround of hosting on local web server just helps with the uzbl browser not crashing and giving you TLS errors, etc, it does not help or fix the issue of the actual contents from the websites being displayed.
Meaning/example:
I have the screenly weather/time app URL inside an iframe of the local HTML file.
At first it works, but then after a few minutes or hours of cycling through the assets on its own, the contents of the website dont load.
So, by doing this workaround, what this helps with (from my tests) is the “freezing/crashing/unable to load” of uzbl browser because the local hosted html file does not cause the browser to “freeze/crash/unable to load”.
Meaning, you should not see that “Unable to load” page anymore and cause the whole screenly to stop there and not reload or continue to other assets you have.
So in a way, all this solves from my tests is the problem of screenly getting stuck on that white “Unable to load” page, it doesn’t solve the problem of the uzbl browser displaying the contents properly.
I am trying to find a solution to this problem with current uzbl because the Qt Webview application is still in experimental version of screenly and unless you’ve tried it and it works for you, as of right now (someone can correct me if I’m working) the production branch of screenly using uzbl is your only choice.
@ealmonte32
Thanks to you ! I take care of that tomorrow and make you a return.
What is the key combination to access the raspberry command line terminal screen? Thank you
Keyboard combination is:
Ctrl+Alt+F1
@androidofon
Before you do anything please see my updated/edited reply above with instructions on connectionpool.py
I will continue to find a verified way to solve the HTTPS/TLS handshake issue, but for now this is a start.
@ealmonte32
Hello,
I just launched your order lines on my device.
I did not change the connectionpool.py file because I did not understand if you wanted me to do it or not (translation problem).
I also turned on the SSH and changed the password so I could restart the raspberry without having to unplug it violently if it crashes.
For now, no TLS error, I’m watching.
Cyril
I was optimistic too quickly.
New TLS error on the Screenly weather page.
Here are the logs of the system information page:
● screenly-viewer.service - Screenly Viewer
Loaded: loaded (/etc/systemd/system/screenly-viewer.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-03-09 09:19:04 UTC; 56min ago
Process: 600 ExecStartPost=/bin/rm -f /tmp/screenly_html/* (code=exited, status=0/SUCCESS)
Process: 597 ExecStartPost=/bin/rm -f /tmp/uzbl_* (code=exited, status=0/SUCCESS)
Process: 593 ExecStartPre=/usr/bin/xset s noblank (code=exited, status=0/SUCCESS)
Process: 590 ExecStartPre=/usr/bin/xset -dpms (code=exited, status=0/SUCCESS)
Process: 588 ExecStartPre=/usr/bin/xset s off (code=exited, status=0/SUCCESS)
Main PID: 596 (python)
CGroup: /system.slice/screenly-viewer.service
├─596 /usr/bin/python /home/pi/screenly/viewer.py
├─622 uzbl-core --config=- --uri=http://127.0.0.1:8080/splash_page --print-events --connect-socket /home/pi/.cache/uzbl/event_daemon
└─629 /usr/bin/python /usr/bin/uzbl-event-manager -va start
Mar 09 10:05:09 raspberrypi python[596]: Showing asset Meteo (webpage)
Mar 09 10:05:09 raspberrypi python[596]: current url is https://weather.srly.io/?lat=45.572661234614486&lng=5.920352670294422&lang=fr&24h=1&wind_speed=1
Mar 09 10:05:09 raspberrypi python[596]: Sleeping for 10
Mar 09 10:05:19 raspberrypi python[596]: Generating asset-list...
Mar 09 10:05:19 raspberrypi python[596]: /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:847: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
Mar 09 10:05:19 raspberrypi python[596]: InsecureRequestWarning)
Mar 09 10:05:20 raspberrypi python[596]: Showing asset Programme cours (webpage)
Mar 09 10:05:22 raspberrypi python[596]: current url is https://www.mywellness.com/kcchambery/classtimetable
Mar 09 10:05:22 raspberrypi python[596]: Sleeping for 60
Mar 09 10:06:22 raspberrypi python[596]: Generating asset-list...
Mar 09 10:06:22 raspberrypi python[596]: Showing asset logonew.png (image)
Mar 09 10:06:22 raspberrypi python[596]: current url is file:///tmp/screenly_html/black_page.html
Mar 09 10:06:22 raspberrypi python[596]: Sleeping for 3
Mar 09 10:06:25 raspberrypi python[596]: Generating asset-list...
Mar 09 10:06:25 raspberrypi python[596]: Showing asset TV_wifi.png (image)
Mar 09 10:06:25 raspberrypi python[596]: Sleeping for 10
Mar 09 10:06:35 raspberrypi python[596]: Generating asset-list...
Mar 09 10:06:35 raspberrypi python[596]: /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:847: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
Mar 09 10:06:35 raspberrypi python[596]: InsecureRequestWarning)
Mar 09 10:06:36 raspberrypi python[596]: Showing asset Meteo (webpage)
So I modified as recommended the connectionpool.py file
Here is the screenshot.
Problem, now it does not start the playlist anymore and remains stuck on Screenly screen
screenly web-service
I had to make a mistake by modifying the connectionpool.py file ;-(
I have re-downloaded a new image of screenly but I am a little lost with the modification of the file.
@ealmonte32 I wrote you a message privately so that you could connect to my remote raspberry (SSH).
@androidofon
I just realized after all this time we were approaching this wrong, those python https insecure requests can be safely ignored, what we needed to focus on was webkit and uzbl… I recently noticed the uzbl browser was using a different config file and not the default uzbl one, so when I was testing and changed ssl_verify = 0 on that one config file, I wasn’t really changing anything with the browser behavior, so I need to test the ssl configuration related settings on the ./.config/uzbl/config-screenly file instead…
Even though running the google sites embed URL workaround has worked for weeks without one TLS error, I still want to find a way to make uzbl handle ssl/tls errors properly… I will continue testing and report back when possible.
Ok perfect, it’s true that this error is harmful because screenly loses all interest.
After reading uzbl website archives and others with same issue, it seems not a screenly specific issue, it is the uzbl browser and other libraries that deal with ssl.
Are you able to make this one change to your ./.config/uzbl/config file while I prepare other Pi for testing? or are you not using the screenly Pi anymore?
Change to make to your Screenly Pi:
Open config file: sudo nano ./.config/uzbl/config-screenly
Add the line: set ssl_verify = 0
Save changes press Ctrl+X, press Y, press Enter.
Reboot: sudo reboot
