2.0.3.7: Track repeats

[ignitenz]

So this morning I noticed the same song played again with two songs separating them. When I looked at the log, I think I saw why.

At the TOTH we have an event set which at the end has a random track from our 2000s category (this is to create a buffer so IDs which are part of the current rotation don't play immediately after the TOTH set). The 2000s category also makes up the largest part of our daypart format.

So it's now easy to see how the repeat happened. The song was already loaded as part of a rotation, but the database didn't take this into account when it loaded the same song as part of the TOTH event.

However, it causes me to wonder... does the no-repeat settings only apply to songs that are pulled into the rotation, but not to songs that come from the same category, but are pulled as part of an event? It would seem so.

Is this a bug?

Would it not make sense to apply the no-repeat rule regardless of whether the song is part of a rotation, or inserted at the last minute as part of an event?

We have over 600 songs loaded into this category with no-repeat rules set to 5 hours, so that shouldn't be an issue.

Any thoughts?

Cheers,
Baldrick

[Derek]

does the no-repeat settings only apply to songs that are pulled into the rotation, but not to songs that come from the same category, but are pulled as part of an event? It would seem so.

It should respect repeat rules, but had the track already actually played before the event loaded it again? If not, this could be the problem as the track hadn't actually played so the repeat rules would have technically been respected.

We've had this when generating playlists and somewhere sometime ago, I suggested a (possibly invisible) 'last selected' field in the database so that repeat rules could be applied to items that had been selected by AutoDJ or within a playlist, not only those actually played.

[ignitenz]

It should respect repeat rules, but had the track already actually played before the event loaded it again? If not, this could be the problem as the track hadn't actually played so the repeat rules would have technically been respected.

We've had this when generating playlists and somewhere sometime ago, I suggested a (possibly invisible) 'last selected' field in the database so that repeat rules could be applied to items that had been selected by AutoDJ or within a playlist, not only those actually played.
[/quote

Thanks for your reply Derek.

I can confirm the song was already in the rotation, ready to play. The song was then added when the event fired prior to the same track already in the rotation. The track in the event was set to "least recently played". I've since changed that to "Least Times Played" in the hope that might get round the issue.

[mdj]

If you are able to transpose your rotations to SQL queries you can stop this from happening. . . .

SELECT *
FROM songs sn
LEFT JOIN queuelist ql
ON ql.songID = sn.ID
WHERE
-- additional WHERE clauses here.
AND ql.ID IS NULL


This checks the current queuelist and excludes any chosen items based on what's already there.

[Derek]

The track in the event was set to "least recently played". I've since changed that to "Least Times Played" in the hope that might get round the issue.

Keep an eye on that as it might actually make things worse! When we add new tracks I was wondering why they kept getting chosen so often and of course we had a 'Least Times Played' in the event so it was choosing them more often as they hadn't been played as much as other tracks.

[ghm72]

Can't say I've noticed any track/artist repeats and I'm calling my tracks by Random

[thaJack]

Why do so many people use random? I think that's a terrible way to program. I've been involved in radio for about twenty-five years (professionally). I've seen programmers that can do a great job at setting up their music scheduling, and some that do a horrendous job at it... but in all that time, I've never seen anyone randomly select songs until I got on this forum.

[ghm72]

Its only recently I've changed my rotations from LRP and LTP to random and I find for my needs RadioDJ does what I need but then again I'm no longer broadcasting. (High Electricity Rates in the UK)


RadioDJ has so much flexibility for different things when it comes to programming events and rotations you do what works best for you I may run a test tomorrow

[RadioDJ Dude]

I was about to post a similar issue re. SQL queries in rotations not respecting repeat rules.
I use a query to pull a song with a specific intro time to accommodate a production element that runs over the song's intro. In the query I use:

$ForceRepeatRules$ ORDER by `date_played` ASC, RAND() LIMIT 1;

BUT, in my history, I see RDJ has been playing the same song back-to-back. Not good. I've removed all these queries from my rotations until the problem is sorted.

However, you bring up a valid point. If the SQL query in the rotation is before a regular song item with the Repeat Rules box checked and RDJ loads the song from the query and the regular song after it, it counts the regular song as not played, because it hasn't played yet.

mdj has an interesting suggestion, but I'm not sure what he means by, "If you are able to transpose your rotations to SQL queries you can stop this from happening". Can the provided code be added to an individual query OR does the entire rotation need to be converted into SQL? Asking for an SQL dummy. Thanks!

[mdj]

mdj has an interesting suggestion, but I'm not sure what he means by, "If you are able to transpose your rotations to SQL queries you can stop this from happening". Can the provided code be added to an individual query OR does the entire rotation need to be converted into SQL? Asking for an SQL dummy. Thanks!

Each item in a rotation would need to be changed to an SQL query in order to stop duplicates appearing in the queuelist (if there is a way to do this without SQL I'm happy to be corrected).

This is a query that should emulate what you can do in 'Add: Track from Category' in the rotations.

SELECT sn.*
FROM songs sn

LEFT JOIN subcategory sc
ON sc.ID = sn.id_subcat

LEFT JOIN genre gn
ON gn.id = sn.id_genre

LEFT JOIN queuelist ql
ON ql.songID = 1

WHERE ql.ID IS NULL -- << Leave this here.
AND sn.enabled = 1

AND sc.name = "DEC90s" -- << Change to the category of your choice, remove line for all categories.
AND gn.name = "Pop" -- << Change to the genre of your choice, remove line for all genres.

AND sn.mood = "Not Set" -- << Change to mood of your choice, remove line for all moods.
AND sn.gender = "Not Set" -- << Change to the gender of your choice, remove line for all genders.
AND sn.lang = "Not Set" -- << Change to the language of your choice, remove line for all languages.

AND start_type IN (0, 1, 2, 3, 4) -- << Remove or Add for each start type, 0= Not Set, 1= Soft, 2=Hard, 3=Fade, 4=Voice
AND end_type IN (0, 1, 2, 3, 4) -- << As above, but for end type

-- Select ONLY one of the following 'ORDER BY's. . . .

-- For Least Recently Played. . . 
ORDER BY date_played ASC
-- For Most Recently Played. . .
ORDER BY date_played DESC

-- Least Times Played . . .
ORDER BY count_played ASC
-- Most Times Played . . .
ORDER BY count_played DESC

-- By Priority . . .
ORDER BY weight DESC

-- By Random . . .
ORDER BY RAND()

-- By Least Recently Imported. . .
ORDER BY date_added ASC
-- By Most Recently Imported. . .
ORDER BY date_added DESC

-- By Highest Rating
ORDER BY rating DESC
-- By Lowest Rating
ORDER BY rating ASC

LIMIT 1

A few things to note. . . 

• In SQL any text after two dashes is considered a comment, ie, -- By Priority . . ..Feel free to remove these.
• If you are limiting it to 1 (LIMIT 1), there is no need to add RDJ rules as they will be ignored anyay. If you do want to use RDJ rules, change it to (LIMIT 20) (or any other number) and include the RDJ rules in the query.
• The LEFT JOIN queuelist ql and WHERE ql.ID IS NULL is where the magic happens in this query, in a nutshell it is excluding anything that is allready in the queuelist from the results of this query
• SQL statements can only contain 1 ORDER BY. . . line, so select the one that you want to use and remove all others.
• The SELECT sn.* will return all the fields from the songs table, this is useful when testing things, but once you have it set up the way you want, I normally modify that line to SELECT sn.ID so it only returns the IDs

Hopefully that covers most of it 
Mike.

EDIT: There were a few errors in the SQL originally, they should be fixed now.

[RadioDJ Dude]

Wow, thanks for the detailed reply and code. Really appreciate it, Mike!
I'll give it a spin...

[DJTechG]

Why do so many people use random? I think that's a terrible way to program. I've been involved in radio for about twenty-five years (professionally). I've seen programmers that can do a great job at setting up their music scheduling, and some that do a horrendous job at it... but in all that time, I've never seen anyone randomly select songs until I got on this forum.

Variety. Also, I've got a day job, as much fun as it would be to sit there all day picking songs to play, I can't do that. I also don't want to hear things repeat in the same order - which is what I was getting before switching to random.

[stevewa]

I believe the problem here, is that the sql query row in the rotation, cannot know which tracks are in the queuelist, because the rotation has not populated the queuelist yet. So including code in your sql query to ignore track ids in the queuelist won't help. You would need to use an event to run the query so it can see what is in the queuelist. We had this problem when trying to do Two For Tuesday inserts. It would repeat songs.

[thaJack]

I was about to post a similar issue re. SQL queries in rotations not respecting repeat rules.

I've had a similar issue with SQL queries. About half of my songs are picked with a SQL query, and it doesn't do a good job of respecting the rules.

[thaJack]

Variety. Also, I've got a day job, as much fun as it would be to sit there all day picking songs to play, I can't do that. I also don't want to hear things repeat in the same order - which is what I was getting before switching to random.

You don't pick songs all day. You program it to pick songs based on how you want it to pick them, then let it do its thing. With random you could theoretically have a song that plays ten times more often than another song in the same category. You wouldn't want that.. at least I don't think you would.

I have one category that will play all of its songs in the same order every time, which is what I want. For the other categories, which are larger, there is an element of randomness to it to keep them from playing in the same order, but it's random in a sense that a card you pick from a magician's hand is also random.

For example, if I have a category with 200 songs in it, and I set it to Least Recently Played, save for a few times it might change due to a repeat rule, it will keep playing through that category in the same order.

What I do is alternate between Least Recently Played (which ensures EVERY song gets played) and a SQL query. The SQL query will look at the category, and find the 40 (or whatever number I want) least recently played songs that meet my criteria, and then randomly select one of those. The idea is that it's randomly selecting from a small portion of the category that hasn't played lately, rather than having the entire category to randomly select from. Over time, this sort of "shuffles" the category.