Hello,
The question must be asked frequently I guess, but I have looked on General and Scripts topics and could not find any solution for it. If posted earlier, sorry but please reply with the link to the topic.
In an full hour you can end up with one track playing for 30 seconds. What are the (automated) solutions for this?
The track in the example is 3:43 but only 1:44 will be played. Are there other ways to handle this?
Thanks for your reply.
Hi John,
this has been discussed here before, indeed, but maybe in the German section. (I haven’t got a link at hand at the time, either.)
The question is: What do you expect mAirList to do in such cases? Do you like some fadeable instrumental to be played? Or have mAirList puzzle out a sequence of songs which fit in the timing slot perfectly? If so, how should we deal with incalculable (as timing is concerned) elements like live announcements or a lately-delivered feature?
Backtimed regards
TSD
This has been around for a long time, here is something I was working on in 2014; it was a very simple experiment. It worked as far as I can remember, but I haven’t done any scheduling since then.
Thanks again.
I have kind of found a way to minimise the song being cut off by using the attached template. I must stress that I have only used it for 1960s music, which has a lot of instrumentals. The “rules” being: try not to fade an actual song too much, however, it is fully acceptable to fade an instrumental track at any duration.
The template (so far) is:-
Fixed Start of hour.
Specific item (jingle) with a hard fixed time 0f 00:00:00
Fill with Random items from folder = 60s. With Normal timing.
Random item from instrumental folder with a Soft fixed time of 00:58:00
Specific item (a jingle) which is Backtimed
End of hour marker.
Although this indicates an under-run, it actually works in practice.
The results - either the last song fades reasonably and then the fixed jingle, or the last song completes in it’s entirety and the instrumental fills the gap up to the fixed jingle.
Reply
Yes, that’s a possible solution. Edit item #4 (the filler) and enter 00:02:00 as the estimated duraion, it will make the Underrun go away.
(At the time you set up the template, mAirList does not know the duration of the song that will be picked later - so you have the option to enter an “estimated duration” to make a rough calculation on template-level possible.)
I have investigated the “last song” optimization in the meantime. The updated algorithm works quite well. There are some interesting side effects though. I have some rather long songs in my pool, 6 minutes or longer. With the new “try to find a single song that fills the gap” policy, the scheduler tends to pick one of those very long songs, rather than two 3:30 songs. That’s the downside of this “greedy” approach. Perhaps we should make the whole thing optional. I’ll keep thinking about it.
Hi there,
Thanks both for your response.
@Tondose: I was hoping that since it happens on every user, there already would be a solution somehow. I searched the German forum as well but could not find it there either.
Since a playlist is generated with these values it would be great to have it all matched time-based. The current situation for times that a track is playing. The first column shows the actual time that a track is played:
It would be great to create a solution for all items that are less that 50 % played. That could be based on blocks <30 sec, <60 sec, <90 sec, etc and setting an alternative. That could be an Automated hook with x tracks, but maybe there are other options as wel. Using alternative blocks to see what fits best or reshuffle the current block to look for better times or maybe not breaking the current song but the previous song in half? These are some ideas.
What I discoverd creating the table above that also jingles are shortend. It would be great if the jingle in that case would be replaced with a shorter one.
Thanks for your response as well. I can imagine that this solution works for you since you have only 60’s(shorter songs) in your format with instrumentals as wel. This is not the situation in my case. But I thank you for sharing the info.
I will think about how to solve it, if someone has alternatives to avoid this, please respond. Thank you in advance.
After having thought some time about this topic, I might have found kind of a solution:
The problem is, we cannot access some backtiming folder in the database, neither directly, nor randomly. We have to supply the variety of backtimers in some other way.
So you may want to overfill your hourly template with a considerable number of titles, all suitable to be played as the penultimate item before TOTH. I actually cannot estimate how many, maybe ten, for a start, but all with considerably different durations. I leave this to the music planning experts. At some time before TOTH, some script will
look up the gap between penultimate (i. e. the last fully-playable) item and TOTH,
decide, whether the very last item is worth to be played (timing-wise),
if not, skip the penultimate item and look for a title in the backup section of the hour that fits better.
Maybe run this procedure again.
Gold version: If this doesn’t work either, skip the title before the penultimate item, look for a random item in the backup section and run the filler procedure again. (And e-mail the music planner to provide more backups in the future.)
If you do not set the timing boundaries too tight, this might work. Possibly.
Swapped regards
TSD
Thanks again, so this is more a feature request or a bug?
I am still experimenting how to solve this. Since your remark about backtiming I have deleted this in the music hours scheduler to see how it goes. I have to optimize it a bit further to see what the result is.
Kind regards,
John
Neither, nor – this is a brainstorming result what to imply in a script to automatically fit songs into the gap before TOTH. The question is now: Were you willing to involve above said changes into your templates?
Hot regards (35 °C hereabout)
TSD
Aha… thanks again for your reply. A script for this will be very helpfull.
I noticed that the backtiming should be based on the shortest track time of the folder where the last track is picked from. Since your remark about not being able to consult the backtiming time, I decided to skip the backtiming for now.
The result has really improved, but what really would make my day is I think easier to implement when no backtiming is set.
Maybe I am thinking about this solution to simple. Sorry for that. I appriciate your help and solution!
Once again, thank you very much.
Normal temperature regards (30+ C),
John
@ [Tondose]: Ok I guess you are not interested in my possible solution?
I am willing to try your solution but I think that a track should be played at least 2 minutes.
Oh, I’m sorry! Your solution is feasible likewise. I even like your aproach better because there is no need for your workflow to be changed. I just thought you have found your way to proceed so I kept quiet.
However, scripts for any of these are yet to be written, what I cannot provide at the moment, alas.
Â
Occupied regards
TSD
Ah ok… no worries.
Thankfull regards 
John
Still looking for a good solution for this since a regenerate of an hour(of a pre generated week) causes tracks played double in a short period. So if someone has a solution for this I would appreciate that.
