Display often hangs

Anthias
41

Yes screenly-ose works on the Pi Zero W as I have one and tested, but yes you need to definitely tweak it with things like setting gpu_mem to 192 (as you did with your Pi 3B).
The programmer who works on screenly-ose has started the move to a different browser because yes, uzbl is one of the main problems, but that is the experimental branch, long way to go before getting an experimental to production use. After all, this is all open source so we need volunteers who can help with the code.

Production and Master branch use the same browser yes, but the encoding of URL and parsing it (passing the URL onto the browser in a way it understands the characters and symbols) is done at the viewer.py (the main python program running the show) and imported modules and utilities all combined, and so rusko the programmer who works on that might have changed some things around in some part that takes the URL and parses it to the browser in order to accommodate something where maybe the production version did not do properly but the master version did, and maybe hasn’t had time to go into that part of the code to fix, or maybe it is a imported module issue, the reason why might not be something he is going to spend time with is because if the experimental browser will fix a lot of issues, he might as well not waste time with uzbl version and instead move onto working on the experimental branch instead… get it?

42

Agree totally. I’m happy to use OpenSource software, and wish I could help with coding . . . but my days of working with Assembler Code in the 1970s (yes really!) are long behind me. I’ve had one or two dips into Python, but . . . I love problem-solving, and I hope helping with problem solvers! Good luck to you and Rusko in developing a more stable product.
I’ve just done all the tweaks on my Pi Zero, and set it off overnight (you probably guess I’m in UK?) to see how it gets on.

43

I tried this and afterwards, the version didn’t change, still had production@6c2c2fd and there were complaints about version of python .

After, I tried /usr/local/sbin/upgrade_screenly.sh and that gave bunch error near the end during database migration…

My end goal is to get the changes in as suggested by ealmonte32 to get a stable system. I made the changes to the production OSE as ealmonte32 suggested but still hangs , so now I’m trying to install the latest development version.

Any idea what I could try next?

TASK [screenly : Run database migration] *******************************************************************************************************************************************
fatal: [localhost]: FAILED! => {“changed”: true, “cmd”: [“python”, “/home/pi/screenly/bin/migrate.py”], “delta”: “0:00:00.148256”, “end”: “2020-04-08 10:09:21.854662”, “msg”: “non-zero return code”, “rc”: 1, “start”: “2020-04-08 10:09:21.706406”, “stderr”: “Traceback (most recent call last):\n File “/home/pi/screenly/bin/migrate.py”, line 163, in \n migrate_drop_filename()\n File “/home/pi/screenly/bin/migrate.py”, line 153, in migrate_drop_filename\n with open_db_get_cursor() as (cursor, _):\n File “/usr/lib/python2.7/contextlib.py”, line 17, in enter\n return self.gen.next()\n File “/home/pi/screenly/bin/migrate.py”, line 53, in open_db_get_cursor\n with sqlite3.connect(database, detect_types=sqlite3.PARSE_DECLTYPES) as conn:\nsqlite3.OperationalError: unable to open database file”, “stderr_lines”: [“Traceback (most recent call last):”, " File “/home/pi/screenly/bin/migrate.py”, line 163, in “, " migrate_drop_filename()”, " File “/home/pi/screenly/bin/migrate.py”, line 153, in migrate_drop_filename", " with open_db_get_cursor() as (cursor, _):", " File “/usr/lib/python2.7/contextlib.py”, line 17, in enter", " return self.gen.next()", " File “/home/pi/screenly/bin/migrate.py”, line 53, in open_db_get_cursor", " with sqlite3.connect(database, detect_types=sqlite3.PARSE_DECLTYPES) as conn:", “sqlite3.OperationalError: unable to open database file”], “stdout”: “”, “stdout_lines”: []}

PLAY RECAP *************************************************************************************************************************************************************************
localhost : ok=36 changed=14 unreachable=0 failed=1 skipped=7 rescued=0 ignored=0

44

just curious, instead of running the upgrade, can you simply run the install script again?

the upgrade script is the same as the master install.sh

Screen Shot 2020-06-15 at 12.02.32 PM
Screen Shot 2020-06-15 at 12.02.32 PM708×288 26.4 KB

47

I deleted a couple of posts because of errors during the upgrade caused by running the upgrade as root. After upgrading as pi user upgrade completed Ok, so I’ll monitor now to see if it hangs on certain assets.

side note: system info … Unable to run tvservice. Unable to determine display power.

manually it works:
pi@media-x:~ $ tvservice -l
1 attached device(s), display ID’s are :
Display Number 2, type HDMI 0

48

I think moving away from uzbl browser has really helped, so far no hanging on an asset that used to hang.
Thank You.

49

@luisscreenly

If you happen to need to use the development/master version/branch but the only problem you run into is the uzbl browser causing too much memory consumption (which is the biggest issue) and making the pi unstable/unusable/hang, I can suggest you simply edit the python viewer file to limit the resources thus two lines added to the code will make it that any time the process viewer.py + uzbl-core consumes more than what you set, the process gets closed down and the browser starts again with fresh memory after restarting the browser.

Until qt browser becomes the default browser in the master branch, this is one of the easiest stop-gap methods you can use. Other methods i worked on like MemoryLimit in the service are too much compared to this simple way.

(see the attached screenshot for how i have mine running)

if you can SSH or ctrl+alt+f1 into the console:

edit the viewer.py file with nano:
nano ./screenly/viewer.py

  1. on the top, just add:
    import resource

  2. on the area before the author, add:
    resource.setrlimit(resource.RLIMIT_AS, (600000000,700000000))

these numbers are in bytes (soft limit, hard limit), for example it may seem like 600 MB soft limit and 700MB hard limit are a lot, but you have to remember in linux theres virtual and resident, and if you were to use the command top while testing this, you would see that your uzbl-core process terminates when the VIRT memory reaches that you have set, and the VIRT size will almost always be larger than RES size.

Give it a try, let me know how it goes, you can play around with the memory but since my pi 3 has 1GB and I use 192MB for GPU, it only gives like 800 of usable, and other services running take up memory as well, so you should not limit that high, usually the soft limit gets hit first and that kills the browser for 10 seconds or so, and this at least keeps your pi alive and reachable.
I also run different tests with the Pi and Screenly so for example right now this pi is running DietPi which is a slimmed down version of Raspbian Lite, so if you are running the regular raspbian lite or screenly-ose image from github, your memory usage might differ from mine, but it’s all closely similar and you should be able to play around with the 600 MB and 700 MB in order to find your sweet spot.

Screen Shot 2020-07-12 at 10.53.38 PM
Screen Shot 2020-07-12 at 10.53.38 PM893×715 76.3 KB
Screen Shot 2020-07-12 at 11.00.19 PM
Screen Shot 2020-07-12 at 11.00.19 PM765×365 50.7 KB

50

Hi guys, great to hear that things are still moving. During the virus crisis, I’m afraid my system is ‘on hold’ so I can’t help with testing at the moment. But I’ll keep watching what goes on here, and hope to join you more actively - in a while.

51

Hey @RobertE
I tested on multiple Pi’s and can confirm that this simpler method works. The person that adds those 2 lines will not have to worry about their Pi freezing/hanging/unresponsive due to memory consumption of viewer service.
If you add many many memory consuming web assets, you will just reach the limit sooner and the browser/service will restart itself, but no longer have to worry about coming to a display that has crashed =]

52

Hi, I’ve just noticed that a new version was released only a week or so ago, so I downloaded that. Will that include these tweaks, or the new browser, or should I go back to installing as above, and making the tweak to the viewer.py file? Also I’m testing again with a Pi Zero W so only have 512 M RAM I think?

53

That version was not really a new version, it was a rebuild according to vpetersson.
The tweak I made is a pending PR which means that until one of them looks at it and tests it themselves, the tweak does not go into the master branch.
Until that happens, you can simply look at the current pending PRs here:
Screenly-OSE Pull Requests

These are the current lines of code that need to be set in viewer.py in order to set limits based on percentage of RAM and not a hardcoded number:

import resource
from psutil import virtual_memory

# setting memory resource limits to prevent viewer from rendering the pi unresponsive due to memory consumption
mem = virtual_memory()
mem_soft = (mem.total * .75)
mem_hard = (mem.total * .90)
num_format = "{:.0f}".format

setlimit = 'resource.setrlimit(resource.RLIMIT_AS, (' + num_format(mem_soft) + ',' + num_format(mem_hard) + '))'
exec(setlimit)

logging.info("The current memory resource limit is set as:")
logging.info(setlimit)
#

As you can probably guess, the mem.total * .75 just means set the soft memory limit to 75% of the total current memory of the Pi, the soft vs hard is explained this way:

The soft limit is a value upon which the operating system will notify the process via a signal or typically restrict it.
An upper bound on the values is defined by the hard limit.

If you want, you can customize yours for the Pi Zero since it has less memory to be 90% on both soft and hard, that way, you at least get the most of the available memory before the process restarts itself, the good news is that you wont have to worry about the Pi hanging and freezing and becoming unreachable anymore as far as all my tests have shown.

54

Hi, Just returned after a few months, as our Pi stopped working. Diagnosed a failed SD card, so downloaded a new Sprint 10 (latest) and its working . . . but same problem as I reported some time ago, that Home - BBC News and Stevington - BBC Weather both show for about half a second, and then go black for the rest of their ‘time’. Is there something about the bbc.co.uk website . . . or?
Any help appreciated. Robert

55

Hi @RobertE , this is simply the UZBL browser and memory limits, etc.
You should be running the development version and not production if you want the latest browser that works with pretty much all websites and does not run into these memory issues.

56

Hi, It’s been a while but I am now trying to get this going again. Using a B+ Pi.
Used bash <(curl -sL https://www.screenly.io/install-ose.sh) to install development version, and Pi update/upgrade.
Now at boot it sticks at rc-local.service, which I had months (or years) ago but can’t find how I got round it.
Any thoughts? Thanks, Robert

57

Sorry I havent really been able to touch this project in months.
I would say that the best way to get this installed properly would be to first install Raspbian OS Lite, not the screenly image, and then after installing raspbian OS lite, then you run the bash command to install. That has been my preferred method because it is a clean install rather than an imaged/prepackaged OS, which is best for when you will use the prepackaged OS and not install different one after.