Suggestion to improve the Mini-Scheduler

English Feature Requests
1

Suggestion to improve the Mini-Scheduler

A friend of mine and myself have been trying to think of a way to improve the Mini-Scheduler. As we experienced ourself, songs will be played in more or less the same order after a certain amount of time. In the support forum, this has been mentioned by other users as well. (https://www.mairlist.com/forum/index.php/topic,6819.0.html)

Deleting (part of) the playback history does not solve this “problem”. I think it’s even making things slightly worse.

If you look at the last played date of a song in the properties, you will most probably find that the previous songs were played on the same day, sometimes in the same hour and sometimes even in the same order just a few weeks ago (depending on the size of the database of course).

With individual songs, it won’t be noticed that easily. But when a new album of one artist has been added to the database, the songs of this album will be played within a couple of days. This will repeat itself in a few weeks, and again, and again. Once you hear a song from album X, you know you will hear more songs of that album the coming days.

We wanted to improve the Scheduler by thinking of an addition to the existing mechanism. An addition that should not be too difficult to implement, an addition that could be adjusted by the user easily or could be completely ignored by the user when not desired.

In order to do so, we had to make some assumptions to the way the Scheduler works at present. Fortunately Torben made a small list recently:

[quote=“Torben, post:14, topic:8893”]What the scheduler does when picking a song from a particular folder:

  • Load list of songs in that folder.
  • Apply title/track/artist separation, calculcating a score/penalty for each song.
  • Only consider the songs with the lowest penalty score.
  • Sort by time last played (extracted from the previous playlists)
  • With a chance of 50%, pick the first song from the list (the one that hasn’t been played for the longest time), with a chance of 25% the second song, with a chance of 12.5% the third song and so on.[/quote]

For clarity reasons, we’ll ignore the title/track/artist separation, the penalty score and the 50% chance etc. etc.

Most important thing is sorting the songs by time last played. I am assuming (and hoping) that the moment the song is played, the date last played is updated in the database.

The best way to understand the present mechanism is comparing it with a deck of cards as can be seen on the figure below. Just pretend we’re playing a game of Patience.

The pile of cards is based on the last played date. The card on top is the card with the oldest last played date.

When the Scheduler needs a song, it will pick the card on top, checks if the song matches the requirements, if so the song will be scheduled. If not, the second song will be checked but the first song stays on top of the pile and will be picked next to see if it matches the requirements for the next slot. And so on.

This way, the chance that consecutive songs will stay more or less in the same order is very large.

In the next post I will try to explain our thoughts of changing this. Remarks and suggestions are very welcome.

mAirlist 001.jpg

2

Suggestion to improve the Mini-Scheduler (II)

In the former post, we’ve described the way we think the Mini Scheduler picks the songs at present. In this post we’re making a suggestion to improve the Scheduler. Again, your remarks and suggestions are very welcome.

In order to make this work, a new entry in the Database is necessary: A new “internal” last played date.
Same example as the previous post, see the figure below. When the Mini Scheduler needs a new song to fill the next slot, it will look at the card on top of the pile. When the song meets the requirements it will be picked.
If not, the (internal) last played date will get changed by X hours, the card will now be inserted somewhere in the pile of cards instead of staying on top of the pile.
X is user-defined and can be somewhere in between 0 and infinite. If X=0 it will stay on top of the pile (just like it is at present), if X=infinite it will end up on the bottom of the pile.

This way the chance of songs being played in the same order after a certain amount of time is very dimm.
We think X should be somewhere around 24-48 hours to be effective depending on the size of the database of course.

We could think of one drawback. the Scheduler might end up in some sort of loop which could cause huge extra time of scheduling. In order to solve that problem we thought of a “counter”.
When a song is actually played, the counter is reset to 0 and the internal last played date is updated. The moment a song is rejected, the last played date will be changed by “X” and the counter is set to “1”. If this song is rejected for the second time, the last played date is changed by “1/2 X” and the counter is set to “2”. Meaning the song will be on top of the pile quicker than the first time it got rejected. When a song is rejected for the third time, the last played date will be changed by “1/4 X” and so on.

One could also specify “Z”. “Z” being the maximum for the “counter”. When the maximum is reached, the card will stay on top of the pile so it will be picked shortly.

We think this will “shuffle” the songs in an appropriate way, won’t be too difficult to implement and can be controlled and adjusted by each user to their liking.

Again, all your remarks and suggestions will be very much appreciated.

Michel and Ed

mAirlist 002.jpg

3

Sorry, I can’t really go into detail in this very moment - will write a longer reply next week.

Just some additional comments:

You cannot ignore the 50% chance, as this is very important…

When the Scheduler needs a song, it will pick the card on top, checks if the song matches the requirements, if so the song will be scheduled.

…because this is not true. It will not necessarily pick the topmost song. It will take all matching cards from the stack first, and then pick one of them in a particular way (the 50/25/…) mechanism, putting the other cards back onto the pile.

So this is not a strict rotation, there is some variation in it. With a strict rotation, the songs would appear in the exact same order. This is not true for the Mini Scheduler.

However, when you have many songs in a folder, and use that folder many times within an hour, it can still happen that you end up with more or less the same songs in the hour, albeit in a different order.

The “stateless” approach of the scheduler (where it derives the rotatation/order from the playlist data) is generally much easier to implement than an internal “counter” or “last play” date. In particular, there are two situations where such an internal counter would make things very difficult:

  • When you move songs around folders (changing their rotation level) - where are they going to be inserted into the “stack”?
  • When you choose to re-run the scheduling for a particular hour/date - how to reset the counters beforehand?

I am aware that the current scheduling algorithm may have some abnormal side effects. That’s why it’s called the “Mini Scheduler” after all :wink: I think we cannot catch up with the guys from MusicMaster or Powergold who have been developing some intelligent algorithms for some 20+ years. The Mini Scheduler should produce some fair results - but if you want a perfect solution, go and buy (or rent) a professional scheduling package :slight_smile:

That being said, I do see some points where the Mini Scheduler can be improved, and I am thankful for your comments and suggestions. I hope we can continue to discuss this here, to find out what’s possible or now.

Based on earlier discussions with other users, I have a couple of possible improvements on my list already, for example:

  • Three modes of picking the song from the stack: 1. semi-rotation with 50/25/… (current), 2. strict rotation, 3. entirely random

  • The 50/25/… could also be tweeked so that you rather have a 10/10/10/… (or whatever the user enters) chance for the songs.

  • A time restriction for the playback history: All songs that haven’t been played for 24 (or whatever) hours are treated equally, regardless of whether they haven’t been played for 25 hours or 1000.

  • “Artist packaging”: Scheduler picks an artist first, then a song from that artist. Useful if you have many songs by the same artist in the folder.

Looking forward to hearing your thoughts.

4

Dear Torben,

Thanks for your reply. It’s wasn’t my intention to ignore the title/track/artist separation rules and the 50% chance, but as an extra addition on top of the existing mechanism. Apparently, and unfortunately, I understand it isn’t that easy to do.

[quote=“Torben, post:3, topic:10181”]The “stateless” approach of the scheduler (where it derives the rotatation/order from the playlist data) is generally much easier to implement than an internal “counter” or “last play” date. In particular, there are two situations where such an internal counter would make things very difficult:

  • When you move songs around folders (changing their rotation level) - where are they going to be inserted into the “stack”?

  • When you choose to re-run the scheduling for a particular hour/date - how to reset the counters beforehand?[/quote]

  • If the “stack” is based on the last played date solely, it doesn’t make a difference to what virtual folders the songs belong, the song should be inserted between the song with a slightly older last played date and the song with a slightly younger last played date.

  • I don’t think the counter will have to be reset when a there is a re-run. The counter only advances by one when the song is on top of the stack but isn’t picked because it doesn’t fit. The counter is only reset when a song is played (but not scheduled).

[quote=“Torben, post:3, topic:10181”]Based on earlier discussions with other users, I have a couple of possible improvements on my list already, for example:

  • Three modes of picking the song from the stack: 1. semi-rotation with 50/25/… (current), 2. strict rotation, 3. entirely random
  • The 50/25/… could also be tweeked so that you rather have a 10/10/10/… (or whatever the user enters) chance for the songs.
  • A time restriction for the playback history: All songs that haven’t been played for 24 (or whatever) hours are treated equally, regardless of whether they haven’t been played for 25 hours or 1000.
  • “Artist packaging”: Scheduler picks an artist first, then a song from that artist. Useful if you have many songs by the same artist in the folder.[/quote]

All four are nice suggestions actually, especially if some can be combined: 10/10/10… and a time restriction for instance.
Entirely random might be great too, but isn’t that difficult to program?

Still looking forward to suggestions from other mAirlist users by the way :wink: :wink:

5

Just wanted to bring this topic to your attention again Torben. Any change that in a future release you could implement some of your thoughts above into the Mini-Scheduler?
I know it is a Mini-Scheduler after all, but some improvements would be very welcome. I would even gladly pay an additional fee for an improved version.

As mentioned in this post: https://www.mairlist.com/forum/index.php/topic,7248.msg54361.html#msg54361 it would be nice to have some extra options:

[ul][li]Being able to use more Boolean Operators: Pick a song from folder x containing y AND z, or containing y NOT z.[/li]
[li]Being able to use more attributes at the same time: Pick a song from folder x “Genre=!Rock” AND “Genre=!Jazz”.[/li]
[li]Being able to use “.”: Pick a song from folder x with love in the title.[/li][/ul]

Also nice to be able to implement some simple rules: e.g. never more than x female (or male) songs back to back.

6

More sophisticated attribute filters with boolean operators wouldn’t be a major problem, I guess. Parsing the expressions is the most difficult part.

On the other hand, inter-song rules (e.g. no two female songs back to back) are a major problem. The scheduling algorithm follows a “never go back” approach, which makes it simple and fast: Once it has picked a song for position #1, it will never revise this decision when looking for a matching song for position #2, and so on. So there is no recursion (which could lead to exponential runtime in the worst case).

7

I think, when you implement the inter-song rules a bit like the artist-separation rules, it should not lead to a massive runtime. So the rule has to be breakable with a certain penalty, just like the artist- or trackseparation rules.

Just a thought though :wink:

8

Another suggestion Torben: Implement an Album Separation rule just like the Artist- or Song Separation. This might mingle the songs a bit more.