@RobertE
I’ve created a PR for the fixing of this with memorylimits to the viewer-service which prevents the pi from hanging/freezing which is mainly due to uzbl browser consuming a lot of resources and not doing good memory management as a process, thus we need to force a direct memory limit on the service…
If you need this asap (while we wait for rusko to review the changes I’ve made) you can simply edit your service files (if you know how to SSH into the Pi or using attached keyboard and mouse and pressing ctrl+alt+f1 to get to console) , then you just do the following:
Make this file /etc/systemd/system/screenly-viewer.service , look like the one below (only the added parts , i put asterisks on them, but obviously when you add the lines dont put the asterisks):
[Service]
WorkingDirectory=/home/pi/screenly
User=pi
*MemoryAccounting=yes*
*MemoryLimit=60%*
*KillMode=control-group*
Environment=DISPLAY=:0.0
and this file: /etc/systemd/system/screenly-celery.service , the same:
[Unit]
Description=Screenly celery worker
After=redis-server.service
[Service]
WorkingDirectory=/home/pi/screenly
User=pi
ExecStart=/usr/local/bin/celery worker -A server.celery -B -n worker@screenly --loglevel=info --schedule /home/pi/.screenly/celerybeat-schedule
Restart=always
RestartSec=5
*MemoryAccounting=yes*
*MemoryLimit=100M*
*KillMode=control-group*
Then restart and you should not have a freezing Pi anymore.
This basically restarts the screenly service anytime the assets you add reach / consume more than 60% of the Pi’s memory, we dont want this too small because it would cause the viewer to restart a bit of unnecessary times, while setting it too high will cause it to have no effect because by the time you consume 60% with just the screenly service, the other processes/services running would have consumed the rest and thus the Pi would still hang/freeze. I found this 60% to be best balance.