Question/Feature Request: Order or priority of playlists

[a1466d44-d3dc-4c0b-90c7-315b088731d7]

Hi, and thank you for this awesome project!

I was just wondering on how larapaper determines which playlist to "use" if you have multiple ones with overlapping Time and day settings.

I'd like to have a default playlist for when no time matches, and override them with specific ones.
But I'm only getting de default one, if I don't limit the "default" playlist to a specific time.

Would be nice to have some limes written about that on the playlist page. Or give some priority option (simple int value?) to make it more obvious which playlist gets played out in case the current time and day hands over more than one?

Best regards and thanks again!

[bnussbau]

Have you tried using their cloud service "Core"? They introduced a new playlist system a few months ago, where each device has its own playlist and you can configure active time slots (which days at which times) per playlist item.

This should solve your problem and may provide a better UX? Interested in your opinion.

[niv-d]

i actually +1 the OPs suggestion, I think playlists that have "times" should take priority over ones that do not.
There are times I want to override the default, to show relevant information for a time period (like, morning show news)
If I want to do that, and have a "default", i need 3 playlists, with duplicate screens, and right now the screens cannot be copied easily, so its a fair amount of work.

it might also be nice in this case to show the playlist that created the screen.

[bnussbau]

I think your use case would be also covered by the new playlist system in Core. There is only one playlist for each device and you define on each item when it is relevant. News item, relevant 8-10 pm and so on.

[niv-d]

I think your use case would be also covered by the new playlist system in Core. There is only one playlist for each device and you define on each item when it is relevant. News item, relevant 8-10 pm and so on.

I guess, I have no core subscription, and I'm using larapaper so everything stays local to my net. If it's useful in core, it might be useful here :)

[jasonwaters]

Thanks for the context @bnussbau . From a self-hosted user’s perspective, I wanted to raise one concern: a lot of us are here specifically because LaraPaper is self-hosted and not Core, so when feature requests are redirected to Core it can make the future direction of LaraPaper feel a little unclear.

Is the intention for LaraPaper to remain an actively developed, first-class self-hosted option with its own feature roadmap? I’d love to hear how you’re thinking about that.

Asking genuinely, because I really value what this project provides. Also happy to help contribute if that would be useful.

[bnussbau]

I think there’s been a misunderstanding, it was not my intention to "redirect" to Core. I was considering migrating the current playlist implementation to a new logic (similar to Core) and was looking for some input.
PR #235 has already been merged and will be included in the next release. Contributions are very welcome (thanks to niv-d in this case) and I am glad that you find this project useful.

[jasonwaters]

Ah, that’s a relief 😅, sorry for the misunderstanding.

For my use case, I’d personally love a single playlist where each item can define its own rules for whether it should be included.

Time-of-day and day-of-week rules are the obvious examples, but I could also see value in device-specific rules, like assigning one playlist to multiple devices and only showing certain items on TRMNL A.

Maybe this starts to get into feature creep, but I could even imagine plugin-aware conditions being useful too. For example, skipping an agenda item when there are no events scheduled that day.

Overall, a flexible per-item rules system inside one playlist feels like it could be really powerful.

[bnussbau]

Version 0.33 allows you to create multiple playlists for a device. One can override the other by being more specific

if it has a time, its very specific,
if it has a day, its mildly specific
if it has both, extremely specific !

Thanks for your input, I also think rules on the playlist item are the way to go. I don’t have a timeline yet, as I will be tackling other things first.

[niv-d]

Ah, that’s a relief 😅, sorry for the misunderstanding.

For my use case, I’d personally love a single playlist where each item can define its own rules for whether it should be included.

Time-of-day and day-of-week rules are the obvious examples, but I could also see value in device-specific rules, like assigning one playlist to multiple devices and only showing certain items on TRMNL A.

Maybe this starts to get into feature creep, but I could even imagine plugin-aware conditions being useful too. For example, skipping an agenda item when there are no events scheduled that day.

Overall, a flexible per-item rules system inside one playlist feels like it could be really powerful.

i'm curious, can you elaborate on more of your use case?

this past weekend i worked to get some stuff prototyped out with some vibecoding, and at this point i can handle the following scenarios:

1. a news playlist which appears twice a day and has the same layout Earth | News | Weather where the news rotates topic every 3 minutes
2. a travel playlist that shows metra times only during the week in the afternoon, and certain days in the morning
3. copying/moving playlists between devices as well as satus of what playlist is active
4. renaming mashups/editing plugins in mashup with settings

i feel personally its missing things you mention:

1. i'd like some widgets inside mashups to show/hide depending on if they have information
2. i'd like to externally trigger if playlists are active

im curious about your usecases to see how different solutions might be applied.

i've been thinking how to do number 1. and my most recent thought was to make modifications to the PlaylistItem to support checking a list of rules, but in my vibe coded slop i already ended up with a lot of arm twisting to get the "settings per plugin in a mashup" working. it does expose the instance data objects tho, which is what i was intially planning to add a list of fields to check with a conditional attached. i'm not sure this is the best plan tho, and the ui/ux seems bleak, so wondering if there are other ideas on how all these scenarios might be acomplished in a intuitive way.

for 2, i was thinking of just adding a webhook option to a playlist, and let you control it however you want. it seems a little misleading though, because it just sets the active playlist for the next request, which could be whenever.

some of the features from the above scenarios are posted below. the code is very slop, and the ux is not great, but currently its working okay-ish:

playlist shown on device screen: (active playlist + screen, nameable mashups, editable mashups, add mashup button, settings for a plugin per mashup)

playlist in the playlist list: (move, copy)

playlist with multiple times: (horribly formatted times, time dialog)

[jasonwaters]

I had another thought based on your comment.

I have an agenda plugin that shows my calendar items for the day. On days when I have no events, it still renders on my TRMNL devices, which feels unnecessary. Ideally, I’d want that plugin to render only when there’s actually something to display.

Since I already post agenda data to the plugin daily via webhook, the plugin already has the information needed to make that decision. That made me wonder whether this could be handled through templates instead of a separate rules engine.

For example, what if a plugin or recipe could optionally define a visibilityConditions.liquid template? If it doesn’t exist, LaraPaper behaves as it does today. If it does exist, LaraPaper evaluates it and expects a simple true or false result to determine whether the item should render.

That seems like it could be a flexible way to support conditional visibility without needing a dedicated rule builder in the UI. In my case, the agenda plugin could check whether there are any events in the posted data and return false when there aren’t. It also seems like the same pattern could support device-based conditions too (for example, show the plugin only on TRMNL OG but not TRMNL X).

I like the idea because it gives plugin and recipe authors a lot of flexibility while keeping LaraPaper itself relatively simple.

Curious what you think. Would an approach like that fit the direction you’re considering?

[niv-d]

I had another thought based on your comment.

I have an agenda plugin that shows my calendar items for the day. On days when I have no events, it still renders on my TRMNL devices, which feels unnecessary. Ideally, I’d want that plugin to render only when there’s actually something to display.

Since I already post agenda data to the plugin daily via webhook, the plugin already has the information needed to make that decision. That made me wonder whether this could be handled through templates instead of a separate rules engine.

For example, what if a plugin or recipe could optionally define a visibilityConditions.liquid template? If it doesn’t exist, LaraPaper behaves as it does today. If it does exist, LaraPaper evaluates it and expects a simple true or false result to determine whether the item should render.

That seems like it could be a flexible way to support conditional visibility without needing a dedicated rule builder in the UI. In my case, the agenda plugin could check whether there are any events in the posted data and return false when there aren’t. It also seems like the same pattern could support device-based conditions too (for example, show the plugin only on TRMNL OG but not TRMNL X).

I like the idea because it gives plugin and recipe authors a lot of flexibility while keeping LaraPaper itself relatively simple.

Curious what you think. Would an approach like that fit the direction you’re considering?

so youre saying the plugin itself would hold a signal, and during the render path of the playlist, if a screen/mashup contains that signal, it would skip the screen? i think technically, it buries the lead a little, but it would maybe be possible to just have a _shouldSkip liquid variable that when set anywhere in a view means the playlist is skipped.

i think it might be easy enough to try and setup tho, i can try later tonight.

[bnussbau]

Before someone starts to implement something, trying to be as compatible as possible with Core (because of the many user recipes), support for this feature should look something like this:

{% if condition %} 
  <script> 
    window.TRMNL_SKIP_SCREEN_GENERATION = true; 
  </script> 
{% endif %}

https://help.trmnl.com/en/articles/13615138-skipping-screens-within-plugin-markup

[niv-d]

Before someone starts to implement something, trying to be as compatible as possible with Core (because of the many user recipes), support for this feature should look something like this:

{% if condition %}

<script> window.TRMNL_SKIP_SCREEN_GENERATION = true; </script>

{% endif %}
https://help.trmnl.com/en/articles/13615138-skipping-screens-within-plugin-markup

reading the docs here, this seems to be cacheing the screen, not skipping it directly; then a second feature lets you skip if theres been no update for 2 days?

edit, actually, looks like it should be:

{% if condition %} 
  <script> 
    window.TRMNL_SKIP_DISPLAY = true; 
  </script> 
{% endif %}