Screenly Forum

Display often hangs

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?

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.

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

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

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

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

@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.

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.

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 =]

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?

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.