Scheduling and e-mailing from a script

Just 2 simple questions:

  1. Is there a way to generate playlists from within a script with the mini scheduler?
  2. Is there a way to send an e-mail from within a script?

You don’t even need a script to do that. There is an event, you can set in the event scheduler. Under “Database” there is a command “Generate Playlist”. I only have screenshots in german available.


I think you get the idea.

Not directly from within a script but you can utilize any command line eMail tool and run it via “ShellExecute” or even wrap it with a batch file and call that batch file.
I have some batch examples here, you could adapt it into a scipt.

Thanks shorty.xs. I know about that option in the event planner but as far I can see you can only generate playlist for 24 hours ahead… I need to have playlists for at least a weak ahead and add a day every night so that it stays that way. Is there a way to do that? Through scripting or a standard event doesn’t matter.

About the other question, that’s great I can work with that, thank you!

Well it seems basically this command is not made for that. If you need that many playlists planned ahead, I’d assume that there is somebody managing these playlists and can also kick of the generation for a week. This is, how we did that, before this event was available.

Can you explain a bit more detailed, why you need that many playlists planned ahead? Maybe there is a different soluttion for your problem.
We run our station with a generation hour by hour. If you set your templates right, this works absolutely smooth.
I just increased the number to 3 hours today, because it is a bit more handy for a single use-case.

We have a radio station with voicetrack programming from 7 am to 7 pm so our dj’s need the time to record this all. Most do it the day before but some record the whole coming week in the weekend so we really need the 7 days ahead.

The thing is that it all runs on a server at the transmitter site and we can only generate playlist on the server itself because at home we all use home licenses and they can’t do that because they don’t know the commercial item type. So it’s basically the only thing for which we need to go onto the server through a remote desktop app. Reviewing all playlist etc can be done remote.

Pity that it’s not possible, would be a good feature request to add a field “days” in the second tab to adjust the time, then it should work.

We come from a system where practically everything was done with macro’s, now I can completely do everything with scripting and built in events so it would be pity if I would still need to use a macro just for that only. :slightly_smiling_face:

OK, I could not imagine that there is a radio program, that works this way. So I learned something new today.

Well it seems a script would probably be your solution indeed, unfortunately I have no clue about the scripting access for the mini-scheduler.
There is some kind of REST Access via the mAirlist DB Server but there is no complete documentation of the command set. At least none that I am aware of.

There is some event Offset, but that also works for 24h only.
@UliNobbe or @Torben need to jump in here, I guess.

Haha really? It’s quite common in Belgium :slightly_smiling_face:

Yes that’s what I meant, if @Torben would add a field for a day offset there my problem would be fixed :slightly_smiling_face:

I know many stations who schedule only once a week - but they do it manually most of the time (and only use the hourly event as a failover in case someone forgot to run the scheduler).

About your question - actually you should be able to put a number of hours higher than 24, have you tried? And yes, there is no offset, but you could just add the number of hours between the time the event is run, and the first hour, on top of it, and keep “overwrite existing” unchecked.

Simple example: Run every night at 20:00 with hour count set to 28 and “include current” checked; will generate 0-23 for the next day, and also report that 20-23 for the current day already exist and just skip them.

Very simple workaround.

Oh okay, that’s interesting. The only thing I am wondering is if it takes into account (in your example) the hours between 20-24 for rotation? To be more precise: which tracks are played in that hours for artist, title and track separation and just for the rotation itself. That’s quite important, if that’s not the case we can’t use it…

The MiniScheduler Artist Separation works based on the planning, not the actual Play out.
If you have planned a couple of hours, into the future, I don’t think that the MiniSheduler will take care of it. As far as I understood the mechanism, it only looks backward, not forward.

Yes that’s also how I understood it. But the question is if you plan let’s say 7 days ahead (168 hours) every night (once a day) and don’t overwrite so that every night 1 day is added, does it take into account all the tracks that are already planned then for these first 6 days? I’m afraid not and that makes it unusable for us :slightly_frowning_face:

Well I assume, that this is the case. The Scheduler takes the Date and hour of the day an looks from that point backwards. As you have planned up to that point already, it should work for you, as expected.
Before there was the option to trigger the scheduler from an event, wa also used weekly planning, just triggered it manually. That worked well for the rotation.

The Scheduler works based on the planning Data only, not on the actual Playout. So for your scenario, this is exactly what you need, while I put down a feature reaquest to base it on the actualy Playout of a song or to have the choice, how you want it to work, as both data: Planning and last Playout are available in the DB.

Ok, interesting :slight_smile:
@Torben can you confirm this?

I never got an answer to this, but today we found out the answer, unfortunately it is not what we expected :slightly_frowning_face:

Until yesterday we ran it every night for the next 24 hours, but now 2 days ago we switched to 2 days ahead (48 hours). So today is the first day we hear the playlist that was then generated, and guess what… All tracks we heard yesterday are back today! :slightly_frowning_face:

So if you plan 48 hours and the first 24 are already generated, these first 24 are not taken into account. That makes the functionality useless in our case… Guess we have to go back to planning manually.

I’m not completely sure if this is a bug now or it is meant to act that way? Because like this the only way you can use the event scheduler to generate playlists is when you are in the last hour before you completely run out of playlists. I don’t see how this is usefull in any real life situation…

It’s exactly as @shorty.xy says, the scheduler uses the already scheduled hour in order to calculate separations etc. when you continue scheduling.

I had to think about it for a while, but it seems that what you found there is actually a bug, or unexpected behaviour. It is caused by the fact that the scheduler doesn’t “know” whether it is going to re-generate or skip already existing hours, by the time it is intialized. It assumes you are re-generating, in which case it would make sense to discard the statistics for the first 24 hours.

I will provide a fix for this ASAP.

1 Like

Great to hear that! :slight_smile: :+1:

Please try snapshot 4119. You should see a message “24 hours already scheduled, advancing…”.

It’s somewhat experimental. Hadn’t have the time to test it thoroughly. Please give feedback.

Unfortunately it doesn’t… I get this error in the log:

Format '%s: %d hours are already schedu' invalid or incompatible with argument

And no playlists are generated, so I think it is broken now?

Fixed it, try b4120 please.

1 Like

Something very strange happened now.

I have 72 hours in the field in the event planner now of which the first 48 (2/9 and 3/9) are already done. In the log I see now it says “48 hours already scheduled, advancing…”. So far so good, but then it suddenly scheduled 6/9 instead of 4/9…? Looks like it skips the 48 hours twice…

So we’re almost there but not completely :slightly_smiling_face: