Skipping asset when removed from playlist

Anthias
1

Now we have upgraded from an older screenly/anthias to the recent anthias version and have noticed that if we remove an asset from the playlist and it is currently playing - it gets skipped and removed. In the old version the asset continued played, and was just not played again.

I guess this is deliberate and it works fine, but the old way suited our procedures - so I was wondering if it would be possible to get the old “way” back - e.g. by enabling/disabling a setting ?

But otherwise the new version looks and feels nice :slight_smile:

2

Sure. But I’m more curious about the actual workflow. Can you tell me more about that?

3

Sure. We have 1 video running continously. When we want to start an instruction video we add it to the list and the video starts - in “the old days” - we could remove the video as soon it had started and it would only play once. Now we have to wait for it to complete before we remove it. To us the old way was better. Another “solution” could be to add a functionality to “show video once and immediately” - instead of modifying the playlist. But otherwise I would say the product has improved greatly :slight_smile:

4

Thanks — that workflow detail changes the answer, because you don’t need to touch the playlist at all.

Use the playback-control endpoint instead of adding and removing

Keep the instruction video as an asset, but leave it disabled so it never enters the rotation. When you want it on screen:

curl "http://<device-ip>/api/v2/assets/control/asset&<asset_id>"

It cuts in immediately, plays once for its full duration, and then the playlist resumes with your continuous video. Nothing is added, nothing is removed, and there’s no waiting for the current play to end.

That is exactly the “show video once and immediately” you asked for as an alternative — it already exists, it just isn’t surfaced anywhere in the web interface.

The asset_id is the hex string in the URL when you open the asset for editing (/assets/<asset_id>/update/), or from GET /api/v2/assets. If you’ve set a password on the device, add -u user:password. Note the & needs quoting in a shell, as above.

I ran this on a Pi 4 here with the target asset disabled:

Skip detected, moving to next asset immediately
Getting specific asset
Showing asset QA3275-RED (image)
Sleeping for 14.9 of 15s
Generating asset-list...
Showing asset QA3275-GREEN (image)

Immediate, full duration, once, back to the playlist.

On getting the old removal behaviour back as a setting

I’d rather not, and I think the above makes it unnecessary. The immediate cut-off is deliberate: it came from #2430, where deleting an asset that was on screen left it there for the rest of its duration — with a one-hour image that meant an hour of content you’d just deleted still showing. A setting would mean every device has to pick which of the two surprises it prefers, and the operators who hit #2430 weren’t wrong either.

The play-once route serves your case better than the old behaviour did, in any event: no add-then-remove dance, and no window where a mistimed removal leaves the video in the rotation.

What I’ve filed

#3402 — to put a Play now action on the asset list so this doesn’t require curl, and to document the playback-control endpoints. The backend is already there; it’s the discoverability that’s missing, and your post is what made that obvious.

And thanks for the kind words about the release.