URL Assets restart the browser

[denfau]

Overview of the Issue
Hi, I have a few Web assets that are making the viewer hang.

1. One is a link to a specific Instagram Post. The page displays correctly for the allocated time, the next image asset appears, but the viewer freezes with that jpeg image.
2. The other link is to a Widget page that should display a class weekly schedule. A message appears briefly, then the viewer stops, and eventually restarts.
   The links work without issues in Firefox, Edge, IE.

Reproduction Steps

• Press Add Asset
• Enter the Asset URL "https://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1"
• Display shows a page showing "loading/connecting"
• Display becomes blank and reverts to startup splash screen
• I can turn that specific asset off, and the viewer will restart to show other assets (JPG files)

Environment

• Raspberry Pi Hardware Version: Raspberry Pi 3 B
• Screenly OSE Version: Development Branch

Thank you.

[qbicdesign]

I can confirm a similar problem with image_2018-11-23-Screenly-OSE-lite

Screenly's own widget URLs load fine. Most other URLs cause the browser to crash.
For me the URL doesn't load at all, Instead I get black screen for a second while the browser reloads, then the playlist starts again from the beginning.
I have a slideshow that is published from Google slides which loads perfectly on 2018-05-04-Screenly_OSE_4GB. I have also tried installing the same 2018-11-23 on 3 different RPi's and different SD cards. I hit the same issue on all of them.

I have to uninstall and use a previous version as this version unuseable.

[vpetersson]

This is very strange, because we haven't really changed anything related to this in Screenly OSE (other than in the experimental branch). Can you try to run an upgrade to the latest developer release? That should also upgrade the system packages.

[qbicdesign]

How would I do that exactly? can't find instructions. If you mean just run the upgrade script, $ bash <(curl -sL https://www.screenly.io/install-ose.sh) then yes I can do that. Anything more you'll need to give me pointers.

[vpetersson]

You're spot on. That's it.

[qbicdesign]

I seem to be stuck on TASK [system : Perform system upgrade]
Screenly itself is still working and I can still access web console etc. Just the script seems to be doing nothing. Its been like 20 mins since it last moved. Is that normal?

[qbicdesign]

go figure - as soon as I posted it woke up :)

[vpetersson]

@qbicdesign that's a heavy operation. Depending on your interenet connection, SD card and Pi, 20 minutes+ isn't unexpected.

[qbicdesign]

So...

After upgrading to dev branch, instead of crashing it seems that Screenly now just skips assets that it (for some reason) thinks are not available.

The clock widget loads, as does one of our internal URLs

The weather widget (which is customised for our locale) won't load:
Feb 21 16:15:24 raspberrypi python[478]: Asset Ilm at https://weather.srly.io?lat=59.42816382263877&lng=24.533778739874272&lang=et&24h=1&wind_speed=1 is not available, skipping.

And my Google slides presntation is also skipped:
Feb 21 16:21:00 raspberrypi python[478]: Asset pohiesitlus at https://docs.google.com/presentation/d/e/[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx]/pub?start=true&loop=true&delayms=10000&slide=id.g47be5881ff_1_8 is not available, skipping.

There is no reason I can see that these URLs should be unavailable.
Can it maybe some kinda latency issue? That the browser quits looking if page load latency is beyond a certain number of milliseconds?

[qbicdesign]

I should add that I'm currently running on Raspberry Pi 2 model B+

[denfau]

An update to this issue.
When I put only two assets which are URL, the application gives errors, related to utf-8.
The page has accented characters (french).

The first URL is loaded to set the Widget language to french:
https://www.gorendezvous.com/fr/homepage/108450/

The second URL is the call to the Widget:
http://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1

I just updated the RPi to the latest development branch.

See attached log file.

Logs1.txt

[denfau]

About the other issue with an Instagram URL Asset, the Instagram post page is shown correctly, then the next Asset, a JPEG image, is shown, but the browser freezes at that point and the last image stays on.

The logs indicate:

current url is file:///tmp/screenly_html/black_page.html

The page is not black, the last image is always on, and the viewer never restarts.

See logs.
logs2.txt

[denfau]

I closed this by mistake... re-opening...

[ealmonte32]

Hmmm.. I was also getting the black page, but I removed all assets, then added the following assets:

https://www.gorendezvous.com
then
https://www.gorendezvous.com/BookingWidget/
then
https://www.gorendezvous.com/BookingWidget/?companyId=108450
then
https://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1

Just for testing purposes to see at what point it stopped loading, and I can't seem to find the reason as to why now it started working..

@denfau - are you still experiencing this issue?

can you tell me what version of uzbl you get when you do the following:
sudo apt-get install uzbl

example:
uzbl is already the newest version (0.0.0~git.20120514-1.2+b2).

Do you happen to know what version of libwebkitgtk and libjavascriptcoregtk you have? just wondering.

[denfau]

@ealmonte32
This is what I get for uzbl:
uzbl is already the newest version (0.0.0~git.20120514-1.2+b2).

As for libwebkitgtk and libjavascriptcoregtk, I do not know what versions...

I will be able to provide additional info only in a few days

[ealmonte32]

@ealmonte32
This is what I get for uzbl:
uzbl is already the newest version (0.0.0~git.20120514-1.2+b2).

As for libwebkitgtk and libjavascriptcoregtk, I do not know what versions...

I will be able to provide additional info only in a few days

ok no problem, i just want to always check first to see if something that works for me and not for someone else has to do with some version of a library or something else..

here are the commands sorry for not posting it before:
dpkg -l | grep libweb
dpkg -l | grep libjava

[ealmonte32]

@denfau @qbicdesign - this is probably a guaranteed fix for these websites..

This is a sort of not very well liked setting out there in the python world because it sets a global default that may not work with some websites, but to fix this edit the following file:
sudo nano ./screenly/viewer.py

then somewhere on the top add the following:

#encode all utf-8
import sys
reload(sys)
sys.setdefaultencoding('utf8')

ctrl+x to save, press y, then enter..

then you can just reload screenly viewer like this:
sudo systemctl restart screenly-viewer.service

I haven't had a lot of time lately to try and figure out why the current unicode converter currently set in the viewer code is not working as expected, so for the time being this solution is only one I found, unless someone else has different one..

[qbicdesign]

Seems to have fixed it for me.
Restarting the viewer just made Screenly get stuck on its current asset.
After a reboot all the assets including URLs are showing correctly.
Lets see if it sticks.

[ealmonte32]

Seems to have fixed it for me.
Restarting the viewer just made Screenly get stuck on its current asset.
After a reboot all the assets including URLs are showing correctly.
Lets see if it sticks.

We're working on a better fix to deal with URLs containing unicode and non-ascii characters through encoding.

[rusko124]

@denfau Hi!
The problem you are talking about rather belongs to uzbl(Screenly-OSE based on it at the moment).
/usr/bin/uzbl-browser --config=- --uri='https://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1' --print-events
Uzbl crashed in my case.
I can advise you to try to switch the Screenly to experimental branch as it is based on QtWebKit.

[qbicdesign]

@ealmonte32 After applying your fix, and now after a reboot, no URL assets at all are showing, it just skips to show only video assets

[qbicdesign]

I just don't get it tho, cos this has worked flawlessly in previous versions.
My other TVs are running 2018-05-04-Screenly_OSE_4GB.img and no problems at all...

[ealmonte32]

The setting of system default to utf8 made it not show any assets at all?
Ugh..
Can we see what the error is now?
Running that journalctl command again should tell us something..

And about working flawlessly before , you know lots of changes have happened over time, and raspbian and the uzbl browser itself have changed too, but yes it's something between Screenly and the browser uzbl most likely.. it's hard to isolate it without debugging it.

[qbicdesign]

Weird that the log is showing me that the URL isn't skipped on all, but as far as I have seen so far, they don't show at all.
The only URL noted as skipped is weather
Mar 04 13:57:59 raspberrypi python[514]: Asset Ilm at https://weather.srly.io?lat=59.42816382263877&lng=24.533778739874272&lang=et&24h=1&wind_speed=1 is not available, skipping.

[qbicdesign]

@ealmonte32 what journalctl command are you talking about?

[ealmonte32]

@qbicdesign

So I left two screenly Pi's over the weekend running the same assets/URLs, so far one of them continued and did not stop at all, but I removed the weather.srly.io asset on both, and I also removed the boardclock one, both gave the same Unable to load error with those on. I have google slides running on both and that never gives the Unable to load error.

But, now I got an "Unable to load: Message corrupt" on one of the Pi's, but this url that gave the corrupt message is also on the other Pi as well and that one did not give such error, so it is very hard to isolate the issue. As you know when figuring something out we need to isolate piece by piece and see what works and what doesn't, but since this is a random works-now-doesn't-later type issue, it must be with uzbl browser.. the screenly viewer has not changed so it must be the process that is retrieving the URLs, aka uzbl browser..

The command to see the logs of what is going on in the background processes is called journalctl, if you type that in the console of the Pi it should give you lots of messages, but if you want to post here, you can either echo all to a text file and upload or paste the filtered log here by typing:
journalctl | grep "Mar 04"
That for example will display only logs from march 4th..
Also, when you post lots of logs here you should use the markdown ``` before the pasting of output and after it so that it makes it easier to read.

[ealmonte32]

@denfau @qbicdesign

Just to let you guys know that I am able to load the page now every time without a problem in terms of browser restarting, read my comment:
#806 (comment)

Remember this is on the production branch.

[nwdigital]

@qbicdesign

So I left two screenly Pi's over the weekend running the same assets/URLs, so far one of them continued and did not stop at all, but I removed the weather.srly.io asset on both, and I also removed the boardclock one, both gave the same Unable to load error with those on. I have google slides running on both and that never gives the Unable to load error.

But, now I got an "Unable to load: Message corrupt" on one of the Pi's, but this url that gave the corrupt message is also on the other Pi as well and that one did not give such error, so it is very hard to isolate the issue. As you know when figuring something out we need to isolate piece by piece and see what works and what doesn't, but since this is a random works-now-doesn't-later type issue, it must be with uzbl browser.. the screenly viewer has not changed so it must be the process that is retrieving the URLs, aka uzbl browser..

The command to see the logs of what is going on in the background processes is called journalctl, if you type that in the console of the Pi it should give you lots of messages, but if you want to post here, you can either echo all to a text file and upload or paste the filtered log here by typing:
journalctl | grep "Mar 04"
That for example will display only logs from march 4th..
Also, when you post lots of logs here you should use the markdown ``` before the pasting of output and after it so that it makes it easier to read.

Hi, I'm the owner/create of boardclock.com. I was doing some searching on the web and saw your thread describing the issue with the TLS problem causing screenly to freeze. I just want to let you know, I and another friend of mine both had the same issue with boardclock, not sure what the issue is as the SSL certs should be fine. But, I can tell you this, I reinstalled screenly and chose the dev version during install and I have not had an issue since.

If there is anything I can help with please let me know.

[ealmonte32]

@nwdigital

Correct, it is not an issue with boardclock.com , it just happened mostly on boardclock and screenly URL because during testing phase those were the most commonly used URLs added to the assets, thus it just happened to be that it got mentioned the most because when assets were on google.com domain it would not give TLS handshake error.
But I have been getting error on all other sites as well with production version.

This TLS issue actually belongs on another post, it sort of got intertwined by mistake into this because some users were getting both, TLS error and browser crashing because of uzbl uri unicode errors.

P.S. boardclock is still displaying daylight savings time =]

[nwdigital]

@nwdigital

Correct, it is not an issue with boardclock.com , it just happened mostly on boardclock and screenly URL because during testing phase those were the most commonly used URLs added to the assets, thus it just happened to be that it got mentioned the most because when assets were on google.com domain it would not give TLS handshake error.
But I have been getting error on all other sites as well with production version.

This TLS issue actually belongs on another post, it sort of got intertwined by mistake into this because some users were getting both, TLS error and browser crashing because of uzbl uri unicode errors.

P.S. boardclock is still displaying daylight savings time =]

Thanks for following up with me. As for daylight savings time, the old way I was getting time was from the device it was being displayed on. I have since added a new feature to get UTC time and convert it to whatever timezone you choose, feel free to login to https://boardclock.com and adjust the setting according in the Timezone Selection section.

[qbicdesign]

A little update from me.

I made a new install of Screenly for a new TV in our school. During initial install I had the Raspberry on same VLAN as all our desktop PCs, I used OSE version 2018-05-04-Screenly_OSE_4GB.img
After I moved the Raspberry onto another VLAN (where all my other Screenly raspberries are) the external URL assets were again being skipped. After a little investigation we discovered that the second VLAN was using our ISPs DNS servers.
I added Google as secondary DNS 8.8.8.8, and hey presto, the external URLs started working again after a reboot.

So this does actually relate to my earlier suggestion :

There is no reason I can see that these URLs should be unavailable.
Can it maybe some kinda latency issue? That the browser quits looking if page load latency is beyond a certain number of milliseconds?

Is there anything that can be done programatically to make Screenly's DNS queries a little more patient?

[vpetersson]

@qbicdesign

Is there anything that can be done programatically to make Screenly's DNS queries a little more patient?

Interesting find. We don't really do anything fancy with networking tho. Just using the built-in functionalities really.

[qbicdesign]

Having said that, I'm now finding that the Screenly weather and clock widget pages don't always load fully. Different results on different TVs yet all running identical versions.
Sometimes I get black screen
Sometimes I get just the background
Sometimes I get the fully loaded widget

I may try turning of the ISP DNS completely and see if that makes a difference.

I'm seeing these errors in the logs

• python[614]: InsecureRequestWarning)
• python[614]: /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connectionpool.py:821: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  Not sure if this is related at all

[ealmonte32]

Having said that, I'm now finding that the Screenly weather and clock widget pages don't always load fully. Different results on different TVs yet all running identical versions.
Sometimes I get black screen
Sometimes I get just the background
Sometimes I get the fully loaded widget

This may not be python/screenly related, but probably uzbl and libwebkit because it is what handles the content that loads on the screen. We would need to see logs:
journalctl <command to show logs, use with | grep "Mar ##" to only show the specific day

---

I may try turning of the ISP DNS completely and see if that makes a difference.

I'm seeing these errors in the logs

• python[614]: InsecureRequestWarning)
• python[614]: /usr/local/lib/python2.7/dist-packages/requests/packages/urllib3/connectionpool.py:821: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  Not sure if this is related at all

That warning is related to the urllib package as you can read from the URL it gives you, it doesn't prevent the page from loading the contents. Also, that is another topic/issue, you can search the forums and Issues for the keyword "tls error" and you can read all things we tried to do to isolate and pinpoint the problem, and only recommendation I have as the best workaround is to create a Google Sites page and literally just use the insert URL feature and put the website you are trying to reach into it, you will be connecting to sites.google.com instead of the other pages, which has not given me the TLS error.
If you want to read about this workaround: #974 (comment)

---

Ok, last but not least:
Remember that when you flash the SD card using the screenly image, it was built almost a year ago as you can see from the build date. Lots of changes to shared libraries and packages have happened since then, thus I recommend that when you want to set up screenly, even though it takes more time because it is not preinstalled, I would suggest you take a raspbian lite image (https://www.raspberrypi.org/downloads/raspbian/)
and properly set up the localisation options (utf-8 should be default), hostname, network, etc, and then use the curl method to install screenly
bash <(curl -sL https://www.screenly.io/install-ose.sh)

If I were you I would add the NTP pool address of your corresponding timezone to the following file:
sudo nano /etc/systemd/timesyncd.conf
where it says [Time], for example I use NTP=0.north-america.pool.ntp.org
just to keep the Pi time synced properly.

After all has been installed and setup, etc, I highly recommend updating all libraries/packages:
sudo apt update && sudo apt full-upgrade -y
then the optional
sudo rpi-update
If you need to read any firmware related changes: https://github.com/raspberrypi/firmware

P.S. I know it sounds like a lot to do but sometimes the long way is the best way, if doing these things make your URL/assets work properly, I personally would like this issue to close since I am not experiencing it after doing what I wrote above.

[denfau]

@ealmonte32

I did a fresh install following your suggestions.

I have setup only two URL assets for now, Screenly Weather and Screenly Clock.
I have chosen the Development branch when I installed Screenly.

I will monitor over the next 24h, and let you know how things go.

Thanks to all for helping.

[ealmonte32]

@ealmonte32

I did a fresh install following your suggestions.

I have setup only two URL assets for now, Screenly Weather and Screenly Clock.
I have chosen the Development branch when I installed Screenly.

I will monitor over the next 24h, and let you know how things go.

Thanks to all for helping.

No prob.
Looking forward to hearing how it goes.
When you added the two URLs, you did direct URL or embedded into a google sites URL?
I just want to make sure everything is noted down exactly as you are doing.

[denfau]

The two Screenly web assets are still running without any issues.
They are direct URL, not embedded.

I will try a few Instagram URL assets for a few days, which I had trouble with...
Such as https://www.instagram.com/p/BvZZZz5BV8j/

[ealmonte32]

@denfau
Any updates regarding the assets and browser issues?
I have narrowed down that depending which URL you add as asset, that is what causes TLS error..
I am still doing research on certificates on the Pi, certificate differences on the sites which cause the TLS error and the ones that dont by checking certificate info using site such as https://ssltools.digicert.com

To stop getting InsecureRequestWarning, simply do this:

(all other suggestions to suppress this warning should be ignored)

[denfau]

@ealmonte32
The two Instagram assets are still showing without any issues.

I still see this warning in the logs, but it does not stop the viewer.

/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

Thank you for the research and help.

[ealmonte32]

The two Instagram assets are still showing without any issues.

I still see this warning in the logs, but it does not stop the viewer.

/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

Thank you for the research and help.

@denfau
I forgot to tell you, the verify = True is done in the file located in
sudo nano /home/pi/screenly/lib/utils.py
As far as I know, this will stop that unverified request warning.

[rusko124]

@vpetersson
So https://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1 url equally does not work as on 2018-05-04-Screenly_OSE_4GB and image_2018-11-23-Screenly-OSE-lite.

This problem concerns UZBL browser and not Screenly.

/usr/bin/uzbl-browser --config=- --uri=https://www.gorendezvous.com/BookingWidget/?companyId=108450&classesOnly=1 --print-events
Command doesn't work, browser crash.

But we also have some issues related to a similar error. These were solved here #1039

Thus I suggest move this issue here https://github.com/uzbl/uzbl/issues and close it.

[vpetersson]

Ok let's move away from UZBL as soon as possible then.