I think we’re speaking from two completely different perspectives.
From a developer’s point of view, the answer is: “Yes, this is possible, RadioBOSS can do it.”
From the day-to-day reality of running a radio station, the answer becomes: “Yes, RadioBOSS can do it, but the workflow is so complex that it’s close to unusable in everyday operation.”
When I say that in practice this means 77 presets → 77 lines/definitions inside one event (or spread across multiple events), the response is essentially “RadioBOSS can handle that.”
My point is: RadioBOSS may handle it, but the operator still has to maintain it. With larger setups, this quickly becomes fragile and error-prone.
You suggested using Create Multiple Playlists. Yes, that is technically possible, but the workflow then becomes:
- first, create and maintain all presets
- then use “Create Multiple Playlists”, which still requires explicitly selecting each preset and manually assigning an output name for every generated playlist
- then create an event that generates a large number of M3U files
- and only after that create additional events to load and start those generated playlists
For something that used to be straightforward, this is a significant increase in complexity and maintenance.
You also mentioned that these changes were needed to ensure precise timing.
However, users who needed that level of precision already had it before by using “Save generated playlist to a file.”
Users who didn’t need that level of precision could simply use the Generate preset workflow.
Now the simpler option is gone, and everyone is forced into the more complex “generate-to-file” approach.
So this doesn’t really add precision — precision already existed — it removes choice and pushes everyday operation into a much more complicated and messy process.
Dayparting itself is a nice feature, but in this model it effectively requires working with timestamped M3U files. In real-world radio operation, this becomes impractical very quickly.
For a weekly schedule, we’re talking about 7 × 24 = 168 time slots.
With time-based playlist files, you end up with folders full of M3Us, and there is no clear or reliable way to verify at a glance that every hour is actually covered and nothing is missing.
Your suggestion to split this into 7 folders (one per day, 24 playlists each) doesn’t really solve the problem — it just spreads the same complexity across multiple folders.
It still doesn’t provide a clear overview of coverage and makes it easy to miss a missing hour or a misconfigured event.
I’d also like to clarify that UI cosmetics (icons, emojis in tabs, nicer clocks, visual tweaks) are not what I’m looking for. Nice to have, but...
What I need is a system that works reliably, is logical, easy to maintain, and easy to oversee in daily operation.
I need a playlist generator, dayparting, and rules like do not repeat (including for intros) that solve real programming problems without adding operational complexity.
At times, it gives me the impression that some changes are being pushed mainly to ship a new version with new features, rather than because the overall workflow is fully thought through and ready for real-world use.
From an operator’s perspective, parts of this feel unfinished rather than truly complete.
This approach may work for a small internet radio or a very simple 24 hour playlist, but for a normal, full-format radio station with structured programming, it’s simply not practical.
