« Take into account expected track start time » option – Repeat protection

[Guillaume]

(I'm starting this thread here to avoid cluttering the Beta 7.2 discussion)​

I'm following up on your responses regarding a repetition issue for an artist that I reported on RadioBOSS 7.2 [beta].
The link is here

You explained how the "Take into account expected track start time" option (part of "Repeat protection with consideration for tracks in the playlist window") works:

When unchecked, it gives the impression that all the tracks in the playlist window have just been played. This is also more reliable, while at the same time excluding some tracks that might have been played.

• Why might tracks be excluded if the box is unchecked?
• "It gives the impression that all the tracks in the playlist window have just been played": If I understand correctly, all the tracks in the playlist window will virtually have the same playback time? For example: the command generates a playlist at 11:45 AM. There are 10 tracks in the playlist window. Will all these tracks be considered as having played at 11:45 AM?

For your information, my artist repetition problem occurred again today (RadioBOSS 7.2.1.3).​

• The "Take into account expected track start time" box is unchecked. Last time, the box was checked;
• The "Repeat protection with consideration for tracks in the playlist window" box is checked;
• I'm using global rules to specify "Do not repeat artist" (3 hours);
• Artist separator is ";"
• There is no replacement of tracks in the playlist (insertion position: at the end of the playlist);
• For today's artist repeat: the rotations and categories are not the same as last time;
• The command's "starttime" corresponds to the correct time and day for playback in the playlist;
• No errors in the log. Everything is correctly taken into account (starttime, tracks from the playlist window, playlist tracks repeat protection time shift).

I have no idea what's going on (and I suspect you do too).​

The only things these two artist repetition issues have in common are:​

• They both involve duets (two artists performing a single piece);
• It's the 10th of the month. My previous repetition issue was on April 10th, and it's happening again today, May 10th. And practically at the same time. Between those two dates, there were no problems. It's bizarre… I don't have any monthly orders for the 10th of each month, let alone during those time slots.

 

[djsoft]

"It gives the impression that all the tracks in the playlist window have just been played": If I understand correctly, all the tracks in the playlist window will virtually have the same playback time? For example: the command generates a playlist at 11:45 AM. There are 10 tracks in the playlist window. Will all these tracks be considered as having played at 11:45 AM?

It only considers tracks after the currently playing track. And not all of them, only up to a max. number specified in the playlist generator settings (20 tracks by default IIRC).

No errors in the log. Everything is correctly taken into account (starttime, tracks from the playlist window, playlist tracks repeat protection time shift).

What does the log show, there should be a line stating how many tracks were loaded from the playlist window. When it was discussed previously in RadioBOSS 7.2 [beta] thread, the problem was that tracks were not loaded at all.

What about playlist start time? If it's specified, the tracks start time is shifted in account for this - this is also logged.

It's the 10th of the month. My previous repetition issue was on April 10th, and it's happening again today, May 10th. And practically at the same time. Between those two dates, there were no problems. It's bizarre… I don't have any monthly orders for the 10th of each month, let alone during those time slots.

There's no code in the Playlist Generator to ignore repeat protection rules on day 10 of the month Also the Playlist Generator and specifically repeat protection is covered by so many tests, I don't think any bugs there are possible. Any repeats are most likely caused by misconfiguration.