This is my version number reported on the System Info screen . . .master@f2cbd9f
Still not there I’m afraid. After about 45 minutes, green light solid on (does this indicate the processor is maxed out?) and display stuck on BBC weather. System Info still shows ‘Generating asset list’ and rotating the URLs being displayed, but they are not showing on screen - just the BBC weather.
I’m beginning to wonder whether I might have another problem? e.g. a faulty SD card (it is a fast one) or power supply?
I see there is a switch in settings for ‘debug logging’. Is it worth my trying that - not that I will be able to interpret the logs, and perhaps it would just generate too much log over the 30 - 40 minutes when it does run OK, before hanging?
Hi, some success. I see from the System Info page that it has restarted the viewer service at 11:00 and again at 11:45 (At least I interpret that from the 3rd line of the View Logs.) The Pi shows it has been running for 1:54 hours, but the viewer service has restarted itself. Also it looks as though the memory USED gradually climbs from about 250/300 towards 550/600+, and then drops. Which is I suppose what you were aiming for! Well done. I’ll continue to keep a close eye.
Ah. I think there are two problems. This morning things ran for a couple of hours - much longer than I’ve managed before - with several restarts of the viewer service, about every 40 minutes. Then it reverted to the green LED full on, display hung for some time. I waited to see if it would sort itself out, and it looks as though it restarted something, as the memory used has dropped to 232M. However, screen is now just black. System info is not updating at all. Actually, it keeps updating the Up Time for both Pi and viewer service, but nothing else new for over an hour in the viewer service log. No option but to reboot.
Yes, the viewer restarting itself after it maxes out it’s memory limit is what we want.
As the browser opens the different websites we will see the memory varying depending on what the page loads, some time after it has cycled through all assets you put, the memory will keep going up and down because of buffers, cached, and shared memory, but will ultimately go higher with recurring page loads, the memory management of linux is complex, this is pretty much the best we can do to prevent a process from eating up all the memory it requests without doing things like dropping memory caches at every cycle, also because we dont have swap since that would kill the SD card, we limit the viewer so that it leaves memory for other resources.
Just a few questions:
Can you take a screenshot or copy and paste what the system info page shows for the viewer area? I just want to make sure the viewer has the Memory limit actually set. (sample screenshot below)
Also, did you increase the GPU mem to 192 like I suggested? This is sort of the best balance between system memory and graphics card memory for the Pi 3 as far as I know.
Yes I think the memory restart of service is happening about every 40 minutes, which is great. I’ve taken the text rather than a screen shot, as you can then see that the Pi memory is up to 659 used, which is about when it thinks of restarting the viewer service.
When I looked at Pi memory it was set at 196, but I changed it down to 192 - but that was a day or two ago, before I reflashed the image etc. Is the difference between 196 and 192 significant? If so I’ll change that too. Actually just checked, and it is set to 192.
This is timed just right, as it has just restarted the viewer service, so here is the log text just before and just after . . . sorry I was not allowed to upload a text file, so there is now a lot of text!
Option Value
Load Average 0.27
Free Space 26G
Memory Total: 811 | Used: 659 | Free: 31 | Shared: 29 | Buff: 6 | Available: 70
Uptime 0 days and 0.67 hours
Monitor Info state 0xa [HDMI CEA (4) RGB lim 16:9], 1280x720 @ 60.00Hz, progressive
Display Power On
Raspberry Model Model 3B+ Revision: 1.3 Ram: 1 GB Sony UK
Screenly Version master@f2cbd9f
MAC Address b8:27:eb:ca:55:4d
Latest Viewer Logs
● screenly-viewer.service - Screenly Viewer
Loaded: loaded (/etc/systemd/system/screenly-viewer.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-03-04 14:25:31 GMT; 40min ago
Process: 604 ExecStartPost=/bin/rm -f /tmp/screenly_html/* (code=exited, status=0/SUCCESS)
Process: 602 ExecStartPost=/bin/rm -f /tmp/uzbl_* (code=exited, status=0/SUCCESS)
Process: 597 ExecStartPre=/usr/bin/xset s noblank (code=exited, status=0/SUCCESS)
Process: 594 ExecStartPre=/usr/bin/xset -dpms (code=exited, status=0/SUCCESS)
Process: 591 ExecStartPre=/usr/bin/xset s off (code=exited, status=0/SUCCESS)
Main PID: 601 (python)
Tasks: 19 (limit: 4915)
Memory: 486.3M (limit: 486.6M)
CGroup: /system.slice/screenly-viewer.service
├─601 /usr/bin/python /home/pi/screenly/viewer.py
├─685 uzbl-core --config=- --uri=file:///tmp/screenly_html/black_page.html --print-events --connect-socket /home/pi/.cache/uzbl/event_daemon
└─690 /usr/bin/python /usr/bin/uzbl-event-manager -va start
Mar 04 15:02:40 raspberrypi python[601]: Showing asset Google Slides (webpage)
Mar 04 15:02:40 raspberrypi python[601]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 04 15:02:40 raspberrypi python[601]: Sleeping for 60
Mar 04 15:03:40 raspberrypi python[601]: Generating asset-list…
Mar 04 15:03:44 raspberrypi python[601]: Showing asset BBC News (webpage)
Mar 04 15:03:44 raspberrypi python[601]: current url is https://www.bbc.co.uk/news
Mar 04 15:03:44 raspberrypi python[601]: Sleeping for 20
Mar 04 15:04:04 raspberrypi python[601]: Generating asset-list…
Mar 04 15:04:04 raspberrypi python[601]: Showing asset Screenly Clock Widget 2 (webpage)
Mar 04 15:04:04 raspberrypi python[601]: current url is https://clock.srly.io
Mar 04 15:04:04 raspberrypi python[601]: Sleeping for 10
Mar 04 15:04:14 raspberrypi python[601]: Generating asset-list…
Mar 04 15:04:15 raspberrypi python[601]: Showing asset Google Slides 2 (webpage)
Mar 04 15:04:15 raspberrypi python[601]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 04 15:04:15 raspberrypi python[601]: Sleeping for 60
Mar 04 15:05:15 raspberrypi python[601]: Generating asset-list…
Mar 04 15:05:16 raspberrypi python[601]: Showing asset BBC Weather (webpage)
Mar 04 15:05:16 raspberrypi python[601]: current url is https://www.bbc.co.uk/weather/2636935
Mar 04 15:05:16 raspberrypi python[601]: Sleeping for 20
Mar 04 15:05:36 raspberrypi python[601]: Generating asset-list…
Option Value
Load Average 0.38
Free Space 26G
Memory Total: 811 | Used: 286 | Free: 350 | Shared: 29 | Buff: 13 | Available: 442
Uptime 0 days and 0.81 hours
Monitor Info state 0xa [HDMI CEA (4) RGB lim 16:9], 1280x720 @ 60.00Hz, progressive
Display Power On
Raspberry Model Model 3B+ Revision: 1.3 Ram: 1 GB Sony UK
Screenly Version master@f2cbd9f
MAC Address b8:27:eb:ca:55:4d
Latest Viewer Logs
● screenly-viewer.service - Screenly Viewer
Loaded: loaded (/etc/systemd/system/screenly-viewer.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-03-04 15:11:59 GMT; 2min 6s ago
Process: 2132 ExecStartPost=/bin/rm -f /tmp/screenly_html/* (code=exited, status=0/SUCCESS)
Process: 2129 ExecStartPost=/bin/rm -f /tmp/uzbl_* (code=exited, status=0/SUCCESS)
Process: 2125 ExecStartPre=/usr/bin/xset s noblank (code=exited, status=0/SUCCESS)
Process: 2123 ExecStartPre=/usr/bin/xset -dpms (code=exited, status=0/SUCCESS)
Process: 2120 ExecStartPre=/usr/bin/xset s off (code=exited, status=0/SUCCESS)
Main PID: 2128 (python)
Tasks: 18 (limit: 4915)
Memory: 167.5M (limit: 486.6M)
CGroup: /system.slice/screenly-viewer.service
├─2128 /usr/bin/python /home/pi/screenly/viewer.py
├─2146 uzbl-core --config=- --uri=file:///tmp/screenly_html/black_page.html --print-events --connect-socket /home/pi/.cache/uzbl/event_daemon
└─2151 /usr/bin/python /usr/bin/uzbl-event-manager -va start
Mar 04 15:12:05 raspberrypi python[2128]: Generating asset-list…
Mar 04 15:12:05 raspberrypi python[2128]: Showing asset Screenly Clock Widget (webpage)
Mar 04 15:12:05 raspberrypi python[2128]: current url is https://clock.srly.io
Mar 04 15:12:05 raspberrypi python[2128]: Sleeping for 10
Mar 04 15:12:15 raspberrypi python[2128]: Generating asset-list…
Mar 04 15:12:15 raspberrypi python[2128]: Showing asset Google Slides (webpage)
Mar 04 15:12:15 raspberrypi python[2128]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 04 15:12:15 raspberrypi python[2128]: Sleeping for 60
Mar 04 15:13:16 raspberrypi python[2128]: Generating asset-list…
Mar 04 15:13:16 raspberrypi python[2128]: Showing asset BBC News (webpage)
Mar 04 15:13:16 raspberrypi python[2128]: current url is https://www.bbc.co.uk/news
Mar 04 15:13:16 raspberrypi python[2128]: Sleeping for 20
Mar 04 15:13:36 raspberrypi python[2128]: Generating asset-list…
Mar 04 15:13:36 raspberrypi python[2128]: Showing asset Screenly Clock Widget 2 (webpage)
Mar 04 15:13:36 raspberrypi python[2128]: current url is https://clock.srly.io
Mar 04 15:13:36 raspberrypi python[2128]: Sleeping for 10
Mar 04 15:13:46 raspberrypi python[2128]: Generating asset-list…
Mar 04 15:13:47 raspberrypi python[2128]: Showing asset Google Slides 2 (webpage)
Mar 04 15:13:47 raspberrypi python[2128]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 04 15:13:47 raspberrypi python[2128]: Sleeping for 60
Glad it’s working.
The reason it should be 192 is because in computer memory address we need multiples of 2 for addressable bytes, let me explain in a simple way, so I assume you’re familiar with memory sizes of 32, 64, 128, 256, 512, and so on, if you try to make a total memory of 196, you wont be able to, but with 192 you can (128+64), so this memory called addressable memory.
References:
https://www.raspberrypi.org/documentation/configuration/config-txt/memory.md
http://edwardbosworth.com/My5155Textbook_HTM/MyText5155_Ch08_V06.htm
Now, with regards to the viewer, good, I see the limit set on the cgroup, this is looking how we wanted.
40 mins sounds about what I get with all of the heavy assets I tested with.
You can play around with the limits if you want it to reset itself less, but then you run into the risk of not allowing enough memory for the CPU to do what it needs which would then bring you back to the Pi freezing when it runs out of memory.
We can tweak the Pi a tiny bit more, like removing system services you dont use on the Pi, for example, if the Pi is being used only for screenly-ose and you only control it from the web dashboard, then things like bluetooth, avahi daemon, might not be needed, and thus you can uninstall them from Raspbian, you basically want a more slim (on a resource diet) Pi so that it can give best performance possible.
Thanks. If I’m right that the green light full on indicates processor overload, then I don’t think tweaking will help. Most of the time the green light is just flicking on every few seconds (indicating it is not stressed at all?) and then something happens to make it full on. My guess is a runaway process has gone ‘wrong’. In windows I would look in task manager to see which process was using 100 CPU, but not familiar enough with Pi and Linux to try to do the same. I’m beginning to think that my best bet is to repower the Pi every 40 minutes. I have it on an electronic clock anyway (with 10 possible on/off time per day), so it would be easy to do. Do you not get yours hanging with green light on?? Have you tried bbc.co.uk/news and bbc.co.uk/weather?
Ah. Interesting one this morning. After about 40 mins I thought it was restarting the viewer service, but in fact now has a black screen (not the usual hang, as that usually shows one of the assets). Green light is not full on, just flicking occasionally. It’s now 10:53 and no assets have been checked since 10:20 . . . The memory used is down at 231, which usually shows a recent restart, but the Viewer log says it has been up for 1 Hour 17 mins. I guess the viewer service restart did not complete properly?
Sorry to keep adding problems!
Option Value
Load Average 0.18
Free Space 26G
Memory Total: 811 Used: 231 Free: 485 Shared: 12 Buff: 9 Available: 515
Uptime 0 days and 1.29 hours
Monitor Info state 0xa [HDMI CEA (4) RGB lim 16:9], 1280x720 @ 60.00Hz, progressive
Display Power On
Raspberry Model Model 3B+ Revision: 1.3 Ram: 1 GB Sony UK
Screenly Version master@f2cbd9f
MAC Address b8:27:eb:ca:55:4d
Latest Viewer Logs
● screenly-viewer.service - Screenly Viewer
Loaded: loaded (/etc/systemd/system/screenly-viewer.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2020-03-05 09:34:32 GMT; 1h 17min ago
Process: 614 ExecStartPost=/bin/rm -f /tmp/screenly_html/* (code=exited, status=0/SUCCESS)
Process: 611 ExecStartPost=/bin/rm -f /tmp/uzbl_* (code=exited, status=0/SUCCESS)
Process: 605 ExecStartPre=/usr/bin/xset s noblank (code=exited, status=0/SUCCESS)
Process: 601 ExecStartPre=/usr/bin/xset -dpms (code=exited, status=0/SUCCESS)
Process: 600 ExecStartPre=/usr/bin/xset s off (code=exited, status=0/SUCCESS)
Main PID: 610 (python)
Tasks: 7 (limit: 4915)
Memory: 26.3M (limit: 486.6M)
CGroup: /system.slice/screenly-viewer.service
└─610 /usr/bin/python /home/pi/screenly/viewer.py
Mar 05 10:16:31 raspberrypi python[610]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 05 10:16:31 raspberrypi python[610]: Sleeping for 60
Mar 05 10:17:32 raspberrypi python[610]: Generating asset-list…
Mar 05 10:17:32 raspberrypi python[610]: Showing asset BBC News (webpage)
Mar 05 10:17:37 raspberrypi python[610]: current url is https://www.bbc.co.uk/news
Mar 05 10:17:37 raspberrypi python[610]: Sleeping for 20
Mar 05 10:17:58 raspberrypi python[610]: Generating asset-list…
Mar 05 10:17:58 raspberrypi python[610]: Showing asset Screenly Clock Widget 2 (webpage)
Mar 05 10:18:08 raspberrypi python[610]: current url is https://clock.srly.io
Mar 05 10:18:08 raspberrypi python[610]: Sleeping for 10
Mar 05 10:18:19 raspberrypi python[610]: Generating asset-list…
Mar 05 10:18:20 raspberrypi python[610]: Showing asset Google Slides 2 (webpage)
Mar 05 10:18:30 raspberrypi python[610]: current url is https://docs.google.com/presentation/d/e/2PACX-1vQFoZ2DUxdeCjNl5d5UFi-9MGVCefYlUKBJg1tQjfTK5apw0y14yHsDyfdLvq5KCnukC810eFkXL-GJ/pub?start=true&loop=true&delayms=10000
Mar 05 10:18:30 raspberrypi python[610]: Sleeping for 60
Mar 05 10:19:30 raspberrypi python[610]: Generating asset-list…
Mar 05 10:19:31 raspberrypi python[610]: Showing asset BBC Weather (webpage)
Mar 05 10:19:41 raspberrypi python[610]: current url is https://www.bbc.co.uk/weather/2636935
Mar 05 10:19:41 raspberrypi python[610]: Sleeping for 20
Mar 05 10:20:01 raspberrypi python[610]: Generating asset-list…
Mar 05 10:20:02 raspberrypi python[610]: Showing asset Screenly Clock Widget (webpage)
Yes the green light is processor activity, this is normal though when the viewer is active and running, it spawns different processes, but regardless we have to see why yours doesn’t restart and mine does (has been during my tests (development branch).
I have tested by putting more assets then you including bbc news (not the weather one) , but if you see this page Update screenly-viewer.service by ealmonte32 · Pull Request #1304 · Screenly/Anthias · GitHub
You can see my screenshots of assets and all the ones I tested with, and the Pi does not freeze anymore, it just restarts the process when memory is reached, and if it does at some point just stay black, it still is for now much better than before without the memory limits because it would hang and freeze because the oom-killer was for some reason not fully killing enough processes to allow me to SSH into the pi and troubleshoot it, and yes my green light would be lit in a forever loop because the process that made it that way was not killed…
Yes you could for now make a sudo crontab -e job and tell it to restart the viewer every 40 mins, I had that as the workaround before I made the memory limits.
open the job scheduler as sudo:
sudo crontab -e
make the job by adding this line all the way at the bottom:
40 * * * * sudo systemctl restart screenly-viewer.service
save the file: ctrl+x , y, enter
Just to make sure we are both running the same Pi and screenly versions, you have Pi 3 and screenly development/master branch? That way, I can test and see what is the difference between the installation i had that would restart the viewer along with all processes vs your setup…
@RobertE
P.S. forgot to say, since it’s always good to have multiple people test something like this, when you have some time, can you change your KillMode from control-group to mixed, as stated here just to see what effect that kill method has when it deals with multiple child processes while python being the main one:
https://www.freedesktop.org/software/systemd/man/systemd.kill.html+&cd=2&hl=en&ct=clnk&gl=us
KillMode=mixed
and add this underneath that too:
SendSIGHUP=yes
Thanks… let me know how it goes (remember try this before creating the cron job just to see if this solves it) I want to probably leave the SendSIGHUP=yes and then go back to KillMode=control-group (i’ll test with control-group while you test with mixed mode), but definitely adding the SendSIGHUP=yes is something I want to do since it is the closest thing we have as a restart process signal.
I forgot to set CPU limits on the service… I wrote this self reminder on a github issue after noticing that the uzbl-core process would consume 100% of cpu for extended periods of time without being killed because the memorylimit would not reach the threshold, thus at least the self healing of the Pi (not freezing) is working with memory limits, but now we need to add the CPU limits as well.
Working on the right setting and hopefully I can figure out what the proper limits should be for this to work.
Ok, this is what my current screenly-viewer.service looks like, if you could make your settings look like mine and test that would help since it seems to work for me…
updated screenly viewer service that was more stable (with celery service memory limits disabled)
Thanks again ealmonte32. This is my Pi and version.
Raspberry Model|Model 3B+ Revision: 1.3 Ram: 1 GB Sony UK
Screenly Version|master@f2cbd9f
It’s a 3B+ if that makes any difference. I’ve made the CPU quota changes, and the SendSIGHUP=yes. I see you have allocated CPUQuota=100%??? Won’t this allow Viewer Service to consume ALL the CPU? Anyway, you’re the expert here, not me. Not made other chages yet (one thing at a time) so not yet changed from KillMode=control-group. I’ll let you know whether the CPU changes help.
Yes that version is fine, I have multiple, 3 and 3+ so I just wanted to confirm, they are both capable of same raspbian lite version and have the same amount of RAM so not really a factor here.
I have tested with the same 3+ as you, with those values on the screenshot I attached, and I restarted of course after making those changes…
This part is a bit complicated and confusing (maybe for some?) and I am still researching the proper setting, but basically as far as I know (if anyone reading this wants to chime in and correct me) the raspberry pi 3+ and others have 4 CPUs, but some programs arent compiled to use multi-threading, like some python programs, so setting CPUQuota 100% is actually 25% of the “CPU” because it has 4 cores, so the quota is being set to the entire viewer service, and if you were looking at the processes as your Pi is running (use top or htop command) you would see that when the browser or any loading begins, the processor is usually ramped up to over 100%, so what I wanted to accomplish is to not let it sit at 100% for longer than the default, which can also cause the system to not function properly, and while the CPU could be at 100% or higher, the memory could be below the limit because the correlation between memory usage and CPU usage as you know is not necessarily the same, you could load a website that eats up 500MB of memory, but once everything is done loading, you have the CPU back at normal since it has nothing else to process in that site, while the memory is still sitting at 500MB… this is why we want both limits, the CPU and memory because we want a sort of self-healing viewer that does not cause the Pi to become unusable/hang/freeze/etc…
To have a real fix, I am going to do some more research into the CPU limits because the Pi can also freeze by not reaching memory limits but by having a process stuck at 100%+ and so for example right now I have my screenly properly restarting with all those assets, but it sometimes “freezes” on a page because the CPU stays in R state (running), so I need to find the proper CPU quota to prevent this from staying running by limiting the time the process can stay in this “R” state.
So for most of screenly-ose users, my current limits should suffice for the number of assets and types of websites they use, especially considering that if these limits weren’t in place, you would need to physically power cycle the Pi unless you had some cron job that would restart it daily but would still need to wait for that to happen, so this “stopgap” limit method is my current way of at least keeping the pi running screenly-ose from completely becoming unusable.
Self-notes:
Ongoing tests… trying to find the right mix of limits between screenly-celery.service and screenly-viewer.service, and how to handle the processes when they affect the system resources… increasing memory limit to 65% did not help, made Pi freeze due to memory exhaustion while mixed killmode did not execute pkill for viewer, set back to 60%… removed limit on celery since logs showed continuous oom-killer for celery but not for uzbl except once (for documentation purposes, screenshot attached)
Ok, so with the current setup of removing limits from celery service and the viewer settings below, I am able to put all those assets shown on screenshot and the service is restarted as soon as the pi reaches the memory limit… and as you have found out, making the asset time more than 1 minute allows the pi more time to load the website, so i suggest you make your assets at least 1 minute or 2 each…
I even added these demo dashboards for good measure since they consume plenty of cpu and memory, and allowing it 2 minutes to load, and no black screen yet (its been running for 2 hours and at every memory limit reached it did its job)…
Sample dashboard ( https://public.datapine.com/#board/BgneeI1yWQMcSXIy4Se53P )
Hi, I’ve got a bit sidetracked, as I’ve hit a more serious problem . . . My Google Presentation which has been fine for months now isn’t. See new topic Google Presentation problems . . . don’t know if you might have ideas about that? Thanks
@RobertE
I’ve actually got good news for both:
- For this issue with screenly-ose after a certain amount of time being stuck in one page, this causes the uzbl-core to get stuck in a Running state, after so much trial and error and searching for best way to alleviate this, the only thing I’ve been able to do to resolve it once and for all is to limit the time that each process spends in the CPU with LimitCPU.
This is my final working viewer service as a workaround while on the master/dev branch which uses uzbl which is most likely the primary cause of this…
- For the google slide issue is simple: the problem is the way the viewer parses the URL to the browser, you simply need to change the URL from the long google slides one into a bitly one, so that the browser parses normal like this https://bit.ly/336A2Bi - instead of the long google one with special encoding characters, thus your loop and time delay will be properly executed in the browser… this is your google slides presentation URL in bitly form: https://bit.ly/336A2Bi , give it a try, you can do that for all URLs that have certain characters in the address…
Wonderful. My display has now been up for over 3 hours. Better than it’s done for months, and looks like 3+ hours = ‘for ever’. Thanks so much for all your hard work. I can now take my Pi back to the Hall where the display is (I’ve had it at home for all this testing).
Might it be worth trying again with my Pi Zero W? I have several of these, and only one 3B+. Or might that be tempting providence? (I’m sure I read when I started that Screenly OSE should run on Pi Zero?
I shan’t complain if it doesn’t work, though - I have a working solution.
Do you think Screenly OSE will continue to use uzbl-core? It does seem to cause problems?
Hi, Just for interest I plugged in my old Pi Zero, with Production version production@6c2c2fd and it copes with the Google Slides URL without problem?? I plan to change to Master/Development and the changes you’ve done, and see what happens.