Grid programming in database instead of m3u8 files

About automatic programming. When I generate a playlist, I have to do it a few minutes before the time, because the playlist generator pro takes time to generate the playlist. Then, another event loads the playlist on time for broadcast.

I already know that I could generate several playlists in a single process with the playlist generator pro. But I do it that way, so I don't have to manage several m3u8 files and load them at the corresponding time.

My proposal is that the programming be generated from a grid in the database. For example. Playlist generator pro places the audios from each of the hours of the day, according to the schedule, in the database structure and then RB loads the audios of that hour into the broadcast playlist. That would make it easier to manage the grid, review the content before broadcast and keep it organized, instead of managing dozens of m3u8 files.

Translated from Spanish with Google translator
 
Last edited:
That would make it easier to manage the grid, review the content before broadcast and keep it organized, instead of managing dozens of m3u8 files.
I don't see how it's different from using m3u8 files. Database or playlist file is simply a storage method, what matters it's how it's presented. You can open and view/edit any of the generated m3u8 playlists in RadioBOSS (e.g. using additional playlist tabs).
 
It's true. But if you generate a playlist for each hour, and you have different programming at various times, and on different days of the week, managing those playlists can be quite complicated. The difference between using a playlist and a database is that a week of playlists can be many playlists, and in the database everything is stored in one place. Additionally, this database can be the same .db file, where the music library is stored. However, the user could choose to use the grid in the database or use m3u8 files.

That grid could be structured by stations (to share a single database by several stations). Programs or blocks (usually hours, half hours or fractions). Furthermore, this structure could avoid having to create events to load the playlists, since each program would start at its time (established in the database), automatically. Only events should be created for the generator pro.

Translated from Spanish with Google translator
 
Last edited:
this structure could avoid having to create events to load the playlists, since each program would start at its time (established in the database), automatically. Only events should be created for the generator pro.
This doesn't look good, to be honest. Currently there's a single point from where timed events start - the Scheduler, so it's much easier to manage and control. If we also add a new thing like "start time for a playlist" in addition the scheduler, this will only make things more complicated. This also duplicates scheduler features. So I don't think it'll work this way.

Also, if you use playlist generator, it means playlists are already created as you need them (that's the point of creating playlists by template) - so generally there's no need to manually post-process them.
 
Back
Top