RadioBOSS 7.2 [beta] - "generate" command

[tomimatko]

I’m not sure whether this is a bug or a new way the playlist generation works.
When I go to Add event → Generate a playlist → Select Template, I get the error:
“Please specify the playlist file name.”

This is not in a Multiple Actions event (where the Generate command is not allowed), but in a regular Generate a playlist event.

If I enter the Generate command manually and specify the playlist file name, everything works as expected.

I hope this is a bug and not that we are now supposed to first create one event to generate the playlist and then another separate event to start the playlist.

 

[djsoft]

Recentemente adquiri uma licença do RadioBOSS Ultimate e tenho testado o software extensivamente, e gostei muito dos recursos que ele oferece.
No entanto, notei alguns erros na versão 7.1.6.2, que persistem na versão Beta 7.2 que estou testando atualmente.

Please write in English.

I’m not sure whether this is a bug or a new way the playlist generation works.

This is a new way how it works. For certain features to work (e.g. Dyaparting) it is required to specify playlist start time and day, the generate command does not support this. This is why this command is deprecated starting with RadioBOSS 7.2.

I hope this is a bug and not that we are now supposed to first create one event to generate the playlist and then another separate event to start the playlist.

This is actually how it's supposed to be done now, create playlists in one events then start them using separate events. This way you control when the playlists will start, as opposed to using the generate command, when the playlists were started at some random point in time, depending on how much time it took to create a playlist.

 

[tomimatko]

Please write in English.


This is a new way how it works. For certain features to work (e.g. Dyaparting) it is required to specify playlist start time and day, the generate command does not support this. This is why this command is deprecated starting with RadioBOSS 7.2.


This is actually how it's supposed to be done now, create playlists in one events then start them using separate events. This way you control when the playlists will start, as opposed to using the generate command, when the playlists were started at some random point in time, depending on how much time it took to create a playlist.

This is exactly what I was afraid of. I’ll try to explain this logically, from the perspective of a radio program director who edits and programs RadioBOSS on a daily basis.

At the moment, our station uses 77 different events. Under this new approach, that would mean creating another 77 events — one set to generate playlists and another set just to start them. In practice, that’s a mission impossible, and it’s a setup where mistakes are almost guaranteed to happen. This is far from what I would call a functional workflow; it feels like complexity taken to the extreme.

The explanation that “playlists were started at some random point in time, depending on how much time it took to create a playlist” doesn’t really hold up in real radio operation. On my system, generating a one-hour playlist takes between 1 and 5 minutes, depending on the settings. That has never been a practical issue.

Other radio automation systems have supported dayparting for years (Jazler, RadioDJ), with this logic integrated directly into playlist or log scheduling, without requiring separate “generate” and “start” events.

There is also another important aspect. Radio programming is not static — to avoid sounding repetitive, I regularly adjust the timing of individual events, shifting them slightly earlier or later. With this new model, I would constantly have to ensure that two separate events remain perfectly aligned. Keeping everything synchronized under these conditions would be very difficult and extremely easy to mess up.

I’m a technician and a program editor. I don’t have the time to constantly monitor whether the “generate” event and the “start” event are both correct and in sync. This would significantly complicate daily operations.
And imagine an even worse — but very realistic — scenario: if, for any reason, the separate “generate” event fails or is forgotten, the same playlist could easily be started twice on the same day. That would mean repeating the exact same playlist within a single day, which is a nightmare in real radio programming.

Yes, there are users who run a single 24-hour playlist, and for them this approach is easy. But a serious radio station runs many playlists, depending on the day, time of day, weekends, and special programming.

I’m sorry, but this new approach is very difficult for me to accept. The idea that I should pay for the most expensive version and the most expensive yearly subscription, only to get a much more complicated workflow in return, is not something I can realistically justify.

Of course, it’s nice to have new features — a new Clock tab, icons and emojis, dayparting, a cleaner design, options like “not play tracks at the same time as yesterday”, and other small improvements. All of that is welcome.
But the real question is whether these additions are worth it if, in return, we get a much more complex and fragile workflow. For day-to-day radio operation, simplicity, reliability, and predictability are far more important than having more features on paper.


And finally, a very important question: if the Standard and Advanced version does not include dayparting, will it keep the old “Generate a playlist” behavior?

 

[tomimatko]

Sorry for the separate post — the edit time has expired, so I’m continuing here.

I think it would be fair to offer a choice.
Those who want dayparting can accept a more complex event structure, while those who prefer a simpler workflow should be able to use the Standard version without dayparting and keep the simple, traditional “Generate a playlist” method.

Forcing the same two-step “generate + start” workflow on the Standard version, which does not include dayparting, does not make sense.

 

[djsoft]

The explanation that “playlists were started at some random point in time, depending on how much time it took to create a playlist” doesn’t really hold up in real radio operation. On my system, generating a one-hour playlist takes between 1 and 5 minutes, depending on the settings. That has never been a practical issue.

This is actually a problem, precise programming is not possible in this case as playlist can start quickly within a minute, or after 5 minutes, or even more, and it's impossible to predict.

There is also another important aspect. Radio programming is not static — to avoid sounding repetitive, I regularly adjust the timing of individual events, shifting them slightly earlier or later. With this new model, I would constantly have to ensure that two separate events remain perfectly aligned. Keeping everything synchronized under these conditions would be very difficult and extremely easy to mess up.

Events don't need to be aligned. Just generate event needs to be in advance of the start event. You can create all playlists in one event, or, create them each hour and use a single event to start them: repeat every hour and use file name templates.
So it's not necessary doubling the event count.

And finally, a very important question: if the Standard and Advanced version does not include dayparting, will it keep the old “Generate a playlist” behavior?

In this regard, the behavior is the same. We can extend (or add new command) to "generate and start" for those who want to use it. The problem with legacy generate command, in addition to unpredictable playlist launch, is that it won't allow using the new features like dayparting or same-time repeat protection.

 

[tomimatko]

Here is what I’m trying to understand. For me, this is a big and fundamental change compared to how RadioBOSS worked before, so I want to be sure I understand it correctly.


1. One event generating many playlists
You said that all playlists can be generated in one event.
How exactly would this work if I have 77 different playlists?
Do I need one long command with many presets and output files, or is there a simpler and more practical method for real radio use?

2. Performance and system load
If one event generates all 77 playlists, this is a lot of work at the same time.
Some of my playlists use complex generator settings, so I am concerned about CPU and disk load.
Also, to be safe when I make schedule changes, I would feel forced to regenerate all playlists every hour.
This would be the only way to make sure that the same playlist does not start twice on the same day.
Is this how this workflow is expected to be used in real radio operation, and is it realistic to generate so many playlists every hour?

3. Daily operation and schedule changes
Radio programming is not static. I often make small changes to the schedule.
With this approach, when I add a new hour or remove one, I must also remember to update the central “generate playlists” event.
This adds extra steps to daily work and increases the risk of human error.

4. Fundamental workflow change
From my point of view, this is a fundamental workflow change.
We are moving from a simple, safe, and easy-to-control workflow to a more complex one with more dependencies and more things that can go wrong.
Please correct me if I am misunderstanding this.

5. “Generate and start” option
You mentioned a possible “generate and start” command.
Is this planned for RadioBOSS 7.2.x, or is it only an idea for some future version?

6. Update decision
My update subscription expires at the end of February, so I need to decide whether to stay on the current version or upgrade.
Knowing if a simpler “generate and start” workflow will be available soon would help me make that decision.

 

[tomimatko]

Here is a real-world problem from daily radio operation.

Before, the workflow was very simple:
I added a Generate a playlist: Rock event, and that was it. The playlist was generated and started. One action, one result.

With the new workflow, this same task is now split into multiple steps:
First, I need an event that generates an .m3u playlist file and stores it in a folder. In my case, that folder contains 77 different playlists.
Then, I need another event where I must manually select the correct playlist file from that folder (for example Rock.m3u) and load it to start playback. At this point, I must be very careful not to select the wrong playlist file, as there is no protection against human error here.

In practice, this means more steps, more manual selection, and more things to remember. For daily radio work, this increases complexity and the risk of mistakes, without improving the actual on-air result.

From a radio editor’s point of view, the previous “generate and start in one step” workflow was simpler, safer, and better suited for real-world operation.

 

[djsoft]

You said that all playlists can be generated in one event.
How exactly would this work if I have 77 different playlists?
Do I need one long command with many presets and output files, or is there a simpler and more practical method for real radio use?

One command, or multiple commands for each preset, or combine like generate 5 playlists with this preset, then 10 playlist with the other etc. It depends on what approach is better for you.
It can be a single command to e.g. create all playlists for the whole day in one go.

It can be a different approach if the presets are named after the hour they are supposed to start at, you can use templates to have a single event to create all playlists and second event to start them.

For example, the "create" event starts at hh:50:00 every hour (use the "Repeat every" - 60 minutes option, or start by Hours, or multiple start times)
run PlaylistGeneratorPro.exe -preset=playlist?hh ...

And then start those playlists at hh:59:59 every hour
C:\path\to\playlist?hh.m3u8

As you see here, playlists and presets are named including the hour and ?hh variable is the current hour (0-24).

With this approach, when I add a new hour or remove one, I must also remember to update the central “generate playlists” event.

Again, it depends, if you just edit the presets it will consider all the changes when it's the next time to create the playlists. Once you have the general template in place (see the example above where it creates a new playlist every hour based on this hour's template), you then just add music and edit presets.

We are moving from a simple, safe, and easy-to-control workflow to a more complex one with more dependencies and more things that can go wrong.
Please correct me if I am misunderstanding this.

As I told you before, the "old" workflow has a fatal issue that you don't know when the playlist will start playing.

Is this planned for RadioBOSS 7.2.x, or is it only an idea for some future version?

It may be added as an option I guess, but I can't promise anything, we need to test it first.

 

[djsoft]

In practice, this means more steps, more manual selection, and more things to remember. For daily radio work, this increases complexity and the risk of mistakes, without improving the actual on-air result.

Please see the example of how it may be done differently. Also, you create all those events once, not that you have to re-do them again and again every day.

From a radio editor’s point of view, the previous “generate and start in one step” workflow was simpler, safer, and better suited for real-world operation.

And what about unpredictable start time?

 

[tomimatko]

Thanks for the detailed explanations. I think I now understand the core technical reasoning behind this, but I’d like to explain why this is still problematic from a real radio workflow perspective.

It seems that we are approaching this from two different angles. You are looking at it from an engine/developer point of view, where it is essential to know the exact start date and time down to the second, so that dayparting rules can be applied deterministically. From that perspective, generating playlists in advance and then starting them later makes sense, even if it introduces more steps and dependencies.

However, I work as a radio editor and broadcaster, using RadioBOSS every single day in real-world operation. For me, RadioBOSS is a daily working tool, not a system that I can continuously audit, debug, and validate internally. I cannot realistically monitor whether each generated playlist is correctly linked to the corresponding event, what happens if I create a new playlist generator preset, rename one, or delete an old one, or whether a file-based playlist was actually generated successfully before it is supposed to start playing.

What is especially important here is that this represents a fundamental change of workflow that has existed since the very early days of RadioBOSS. This was never clearly stated upfront, so at first I assumed I was dealing with a bug or a configuration issue, not a completely different operational model. I had to discover this only through trial and error and forum discussion.

Regarding the specific issue with dayparting: I now understand that when I run a command like
<span><span>PlaylistGeneratorPro.exe -preset=Funky -</span><span><span>out</span></span><span>=Funky.m3u8<br></span></span>
the Playlist Generator has no information about the intended start day and time, and therefore cannot apply dayparting rules correctly. That makes sense from an engine perspective. However, when I am told to “use the Wizard in the Scheduler”, I am still missing a concrete, step-by-step example of what the Wizard actually adds to the command line and how a non-developer user can verify that this information is correctly passed. Simply saying “use the Wizard” is not sufficient unless it is clear what exactly changes and how this should be safely implemented in daily radio operation.

In practice, this means moving from a simple, safe, and easy-to-control workflow (one event, one click, generate and continue playback) to a significantly more complex one, with multiple steps, external executables, file-based playlists, naming conventions, and timing dependencies. Each additional step increases the risk of silent errors. For my use case, the practical gain from features like strict dayparting or “do not play at the same time tomorrow” is relatively small compared to the added complexity and operational risk.

Version 7.1 provides me with stability, predictability, and a very small margin for mistakes. The existing “generate and continue” workflow has worked reliably for many years. Whether playback starts a minute earlier or later has never been an issue for me, and it still isn’t. From a radio point of view, reliability and simplicity are more important than theoretical precision.

Since a simpler, single-step “generate & start” option is currently only a possible future idea, with no confirmation, I will remain on version 7.1 for my daily radio work for the time being.

That said, I will of course continue to follow RadioBOSS development and provide feedback whenever possible. I just need to use the version that best fits real-world radio operation in my environment right now.

Thanks again for taking the time to explain your approach and for listening to user feedback.

 

[tomimatko]

One command, or multiple commands for each preset, or combine like generate 5 playlists with this preset, then 10 playlist with the other etc. It depends on what approach is better for you.
It can be a single command to e.g. create all playlists for the whole day in one go.

It can be a different approach if the presets are named after the hour they are supposed to start at, you can use templates to have a single event to create all playlists and second event to start them.

For example, the "create" event starts at hh:50:00 every hour (use the "Repeat every" - 60 minutes option, or start by Hours, or multiple start times)
run PlaylistGeneratorPro.exe -preset=playlist?hh ...

And then start those playlists at hh:59:59 every hour
C:\path\to\playlist?hh.m3u8

As you see here, playlists and presets are named including the hour and ?hh variable is the current hour (0-24).

Thanks for the explanation, but after reading this several times, I still don’t see how this would work in my case.

My station does not use a single generic hourly structure.
I have different clocks for different hours — different music categories, different jingle sets, different rules, sometimes different program logic. In total, there are around 77 different clock variations.

With that in mind, I don’t understand how a single repeating “create” event (or a template-based approach) is supposed to handle this.
If every hour has a different clock and different rules, how can one repeating event — or even a repeat every 60 minutes setup — reliably generate the correct playlist for each specific hour without manually mapping and maintaining all those dependencies?

From my perspective, this still looks like replacing a clear and explicit workflow (each event clearly represents what happens in that hour) with a more abstract one, where the actual behavior depends on naming conventions, variables, and implicit assumptions. That makes it much harder to verify and control in real daily radio operation.

Could you please explain concretely, step by step, how a station with many different hourly clocks (not a uniform hourly structure) is supposed to implement this using the proposed approach?
At the moment, I understand the theory, but I don’t see a practical, safe way to apply it to a real-world radio setup like mine.

 

[djsoft]

It seems that we are approaching this from two different angles. You are looking at it from an engine/developer point of view, where it is essential to know the exact start date and time down to the second, so that dayparting rules can be applied deterministically.

Dayparting will work with generate command as well (if start time/day is supplied there). The problem is unpredictable start time, and we did receive a lot complaints about it and it's understandable as (almost) everyone wants things to start on time and any randomness here is not welcome.

I cannot realistically monitor whether each generated playlist is correctly linked to the corresponding event, what happens if I create a new playlist generator preset, rename one, or delete an old one, or whether a file-based playlist was actually generated successfully before it is supposed to start playing.

As I said before, you can change how things are configured. There are many different ways, one I described above with using templates. Here's another, and it's just an example, for hourly programming

1. You create a playlist every hour using various presets but always save those playlists to the same file. Let's say it's C:\playlist.mp3 - this should happen every hour.
2. You create an event that runs every hour and starts this C:\playlist.mp3.

This way, you run various "create playlist" events and they overwrite the playlist file.

In practice, this means moving from a simple, safe, and easy-to-control workflow (one event, one click, generate and continue playback) to a significantly more complex one, with multiple steps, external executables

Using the generate command also involves calling the same executable "PlaylistGeneratorPro.exe" but it saves the playlist to a temp file and then starts it. In terms of reliability, there's no difference.

Since a simpler, single-step “generate & start” option is currently only a possible future idea, with no confirmation, I will remain on version 7.1 for my daily radio work for the time being.

It's not a big deal to extend the generate command to specify start time/day. But the point is to encourage approach where everything runs predictable, playlists start when they are programmed to start and not "when it's ready" which is random.

If every hour has a different clock and different rules, how can one repeating event — or even a repeat every 60 minutes setup — reliably generate the correct playlist for each specific hour without manually mapping and maintaining all those dependencies?

There's actually a feature request for cases like this, to create a tool similar to the Ads Scheduler, but instead it will create scheduled events to create and run the playlist. Effectively automating your approach to programming. The point of such a tool to reduce manual event management and see everything in a grid.

 

[tomimatko]

OK, I think I understand it now — please correct me if I’m wrong.

The idea is to have one scheduler event with multiple “Generate playlist” actions, for example:

run PlaylistGeneratorPro.exe "-preset=Funky" "-out=C:\Users\tomim\Downloads\Funky.m3u8"

…and then repeat this for all presets.

In my case, this would mean around 77 generate commands/lines inside a single event. I don’t consider this an edge case — in practice, most reasonably serious radio stations operate with a large number of presets, not just 5–10, unless the format is very simple or narrowly specialized (for example, a pure hit radio).

If I later remove a preset, I must manually find the corresponding line among those 77 actions and delete it.
If I add a new preset, I must remember to manually add a new generate line for it.
If I forget to do this, that preset won’t generate a playlist, which could result in dead air.

So effectively, instead of having 77 separate “Generate playlist” events, I would have one event containing 77 generate actions, which is functionally similar but still quite hard to maintain and not very transparent with a larger setup.

My question is:
Is there any command, option, or mechanism that would allow generating playlists from all presets that exist in Playlist Generator (or from the folder where .genprs are stored), without explicitly listing every preset name and having to constantly maintain those lines manually?

Or is explicitly defining each preset (either as a separate event or as a separate generate action) still the only supported way?

Thanks for clarifying.

 

[tomimatko]

One more concern with time-based playlist filenames (day/time in the name) is operational visibility.
With dozens of generated playlists in a folder, there is no clear or reliable way to quickly verify whether all time slots are actually covered or if a specific hour is missing.
In other words, a folder full of time-stamped playlists doesn’t provide a clear overview of schedule completeness and makes it easy to miss gaps.
I also assume that a variable-based name like sun_13.00_Rock does not actually work as a meaningful template for dayparting or preset selection, and is treated as plain text only.
That would otherwise provide a much clearer overview of all covered hours.

In practice, this means I can only end up with static names like Pop_mon_16.00, Rock_sun_13.00, Swing_sat_12.00... which again leads to a folder full of files without a clear way to verify that every hour is covered.
If I want to cover every hour of the week, that would mean 24 × 7 = 168 such time-based M3U files, right? Ufff...

 

[djsoft]

run PlaylistGeneratorPro.exe "-preset=Funky" "-out=C:\Users\tomim\Downloads\Funky.m3u8"

…and then repeat this for all presets.

If this is to create playlists for all day, better would be to create all paylists in one go, as this way they will all share the same repeat protection buffer. In the playlist generator, click the arrow near the Generate button and select "Create multiple playlists". It will create the command for you.

In my case, this would mean around 77 generate commands/lines inside a single event. I don’t consider this an edge case — in practice, most reasonably serious radio stations operate with a large number of presets, not just 5–10, unless the format is very simple or narrowly specialized (for example, a pure hit radio).

This is not a problem, the number of playlists is not limited, but as I say, it's better to create them in one command.

Is there any command, option, or mechanism that would allow generating playlists from all presets that exist in Playlist Generator (or from the folder where .genprs are stored), without explicitly listing every preset name and having to constantly maintain those lines manually?

This is what the new tool (the one I wrote couple of posts before) would allow to do.

About the generate command. We have found a solution to improve this command, allowing it to use the new features, as well as get rid of the "unpredictable start time" problem. The command (event) will have an option to "start creating playlist X minutes before its start time". This way, it's only a single event, generate-and-start, and it would be known when the playlist will launch.

 

[tomimatko]

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.

 

[djsoft]

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.

As was said before, the playlists do not need to be timestamped, in some (most) cases it can simply be a single playlist file that's updated each time a new playlist is created. Overall, it's not complex as you describe. And, in any case, the generate command will be extended, as I told in the previous posts (this is also to prepare it for the new tool to manage playlist creation, as it would be easier to manage one event per preset, than two events per preset).