Smartblock - Limited to 1 item of random DJ mix
Smartblock - Limited to 1 item of random jingle
I then a playlist that pulls in both of the above smartblocks. I use this playlist in repeating mode in the auto-playlist feature in shows.
My question - The random selection, seems less than random (I think this is postgres rather than libretime). Does anyone have any tips for avoiding the same mixes being played in close sucsession?
I know there’s a feature for last played and relative dates being actively developed… but maybe theres another trick I’m missing!
I don’t think there is a better way to make it work with your current choice of smartblocks with the functionality of our current codebase. The randomness does indeed come from the PostgreSQL random() added onto addAscendingOrderByColumn which I’m assuming is equivalent to ORDER BY random()
I doubt we are running into an issue with random not being random enough but maybe it isn’t sufficient here is some speculation on the randomness of random() on postgres and a possible alternative.
I want to investigate and see if there could be any other culprits in terms of how the query is made that might improve the randomness of the selection.
But to answer your question, I can’t think of a trick that would fix your current query at the moment. Maybe someone else has ideas.
Ok, so I might be wrong here but I have a theory that the issue with Propel randomness is the usage of FORMAT_ON_DEMAND as the formatter for Propel, evidently this saves memory space by reusing the same object see - https://stackoverflow.com/questions/32095612/propel-modelcriteriaformat-on-demand-reuses-same-object So perhaps the issue is with propel creating a much smaller selection due to the FORMAT_ON_DEMAND and then randomizing on that selection vs. the entire set. Which could explain the tendency towards repeats. There has been even been a bug where there are repeats slipping through. The drawback to changing it could be slower performance and I’m not even sure how we can easily empirically test it.
Ok, so after substantial statistical analysis involving a smartblock choosing 1 track from 509 possible tracks and logging the result 10,000 times for FORMAT_ON_DEMAND and 7500 without FORMAT_ON_DEMAND the actual track selection process appears to be pretty random. My astrophysicist wife did a chi-squared analysis and the results came to 1.03 which would be about what is expected from a random distribution.So I think even though people feel like the results aren’t very random this is probably just because we subjectively don’t expect values to repeat very often and well with a random selection any track has the same chance of repeating each time it is selected.
So the only real fix here is going to be either modifying the smartblock code to keep track of repeats inside of shows or figuring out a way to insert logo tracks etc into a smartblock as per the feature from the airtime community hacks. Another way for people who are trying to avoid repeats would be to use the relative time and filter for tracks that have last played before some periodicity such as a month ago or 6 months etc.
Does relative time filter work yet in alpha 3? I couldn’t see it anywhere, so presumed it was WIP - Filtering to exclude stuff played in the last n hours would be a perfect solution.
The relative time filter is working and ready for testing. It might still have some jQuery based behaviors that I missed when adding and deleting criteria but for the most part it should be worthy of testing and using IMO.
Just about to start testing this… Not sure if it will work… As mentioned:
I’m currently doing playout with the following…
Smartblock - Limited to 1 item of random DJ mix
Smartblock - Limited to 1 item of random jingle
I then a playlist that pulls in both of the above smartblocks. I use this playlist in repeating mode in the auto-playlist feature in shows.
My shows are 6hrs long… I was just about to add another criteria on my Smartblock for DJ-mixes… Saying ‘Lastplayed after 3hrs ago’…
But I guess my show content will get generated 10mins before the show is due to start via the auto playlist… so I could still end up with content repeating in my show, as the ‘last-played’ comparison will be done in bulk when the show is populated, and not take into consideration any ‘last-plays’ during the 6hr show? Is my thinking correct here?
Yes that is the way it currently works. It can only go based upon previous auto playlists. It also builds the playlist about an hour before the show airs currently (this could be made configurable but it hasn’t been as of yet due to a lack of perceived demand). So yeah it would have to be based upon previous playlists. I’m also not sure when exactly a track gets marked as played. Most likely this occurs when the track is actually played but I haven’t looked into the code to verify this.
The only work-around for this would be to do smaller shows. Anything else is going to require making the smartblocks working inside of the shows a lot “smarter”.