I’ve been using Anthias on Raspberry Pi 3B for some years and it works very good. I’ve just installed a new Raspberry Pi 5 and installed the latest Anthias.
It works for following the schedule, but if I want to go to next asset (skipping the current one) nothing happens before the the current asset is finished - if I look in the logs for the viewer docker image there are some errors with “pkill” but I cant see why it doesn’t work ?
regards
Flemming
@Flemse, when the Next Asset button is clicked, Anthias will wait for current content to finish its turn (unless it’s a video asset). Clicking the Previous Asset button will do the same thing, but the content before the current one will be played instead.
Do you want the playback controls (i.e., Next Asset, Previous Asset) to work instantaneously?
If yes, let me check how to make the controls to trigger playback at an instant.
Yes - we are mainly using local (uploaded) videos and it used to be that “next asset” switched instantaneously. If there is any way to get that feature we would be very pleased ?
regards
Flemming
@Flemse, thanks for the clarification. I’ll let you know when I come up with a fix.
If it just waits for the current asset to complete - then what is the point of “next asset” ?
Hope you come up with something 
I have some updates - I have tested on a Raspberry Pi 4 with a little older “bullseye” image and “next asset” works as expected. On the newest Bullseye it seemed to work on local videos but not on a image ??
Raspberry Pi 5 needs “Bookworm” and it seems to be a problem with both my Raspberry Pi 4 and 5 ?
So could it be something relating to the Raspberry distribution ? I can help do further debugging if needed ?
@Flemse, good catch. Thanks for sharing your observations.
Appreciate your offer to help. Thanks!
Yes, it could have something to do with the distro version. I’ll provided the details that you need to get started shortly.
@Flemse, given that you’re able to SSH into your Pi 5, proceed to do the following:
~/screenly/ directory by running cd ~/screenly.anthias-viewer bash.docker compose logs -ft anthias-viewer.Let me know if you wish to proceed with making changes inside your Raspberry Pi 5 and re-building the containers, please let me know. I’d be happy to provide you with the details.
I already looked at hte log-files but didn’t find anything screaming what the problem is. I have worked with docker and used Linux for many years - so let me know what kind of logs I can provide to you ?
Flemming
When pressing “next Asset” - this comes in the logfile for the viewer, but it just continues the video (whereas on Raspberry Pi4 on older distro it skips the rest of the video
Current url is null
pkill: killing pid 1 failed: Operation not permitted
USR1 received, skipping.
pkill: killing pid 1 failed: Operation not permitted
USR1 received, skipping.
@Flemse, thanks!
How assets are skipped will likely need to be changed.
Now I have found a solution/workaround - maybe not “the” solution. But if I stick with Raspberry Pi 4 and use the 32bit image everything works perfectly with the newest image. I will go for that.
I can see there are some issues with RPI 5 and very high cpu-usage which I see as well, but the problem for me is that I can not switch to next asset.
Hope this can help you ?
regards
Flemming
There is still a small thing - if we have a jpeg as asset, it can not be skipped. I’ve looked at the sourcecode and it seems that images are displayed in a browser (which probably doesn’t react to SIGUSR1 - which is sent as part of “next asset”) - where as a local video is handled by the python module which handles SIGUSR1 as expected ?
Flemming
Now I have found a solution/workaround - maybe not “the” solution. But if I stick with Raspberry Pi 4 and use the 32bit image everything works perfectly with the newest image. I will go for that.
Thanks for the details. I’ll keep that in mind.
There is still a small thing - if we have a jpeg as asset, it can not be skipped. I’ve looked at the sourcecode and it seems that images are displayed in a browser (which probably doesn’t react to SIGUSR1 - which is sent as part of “next asset”) - where as a local video is handled by the python module which handles SIGUSR1 as expected ?
Yes, that’s the current behavior.
@Flemse, we already fixed the issue. The changes were already deployed for the Pi 5 running Raspberry Pi OS (Bookworm). You can now do the update.
Thank you - I will test