View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002036 | MMW v4 | Now Playing | public | 2005-09-25 19:04 | 2010-06-03 15:56 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 3.2.1 | Fixed in Version | 3.2.1 | ||
| Summary | 0002036: Auto-DJ isn't random enough | ||||
| Description | As reported in http://www.mediamonkey.com/forum/viewtopic.php?t=5770, Auto-DJ can sometimes result in duplicates. At least directly repeating tracks should be prevented. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1295 | ||||
|
|
I would have thought that duplicate prevention (bug 0001966) would solve this issue and that there's no need for an independent solution. |
|
|
Apart from the fact I don't like all the aspects of 1966, this is a bit different. Here user shouldn't get any warning (in red) or so, Auto-DJ shouldn't be fully random, i.e. it should for example check last 10 tracks in NP and if the new one to be randomly added matches one of them, a new random sample should be made. (Only in case the playlist Auto-DJ chooses from has less than 10 tracks the rule must be broken). |
|
|
I have done it according to Jiri's idea. Fixed in build 910. |
|
|
I have a couple of problems with this implementation: 1) If we hardcode a check for the last 10 tracks, then this wouldn't solve the problem since repeats would still occur (just after the 10 track limit). Moreover, this setting can possibly conflict with whatever the user chooses for the duplicate prevention setting (0001966) and the user will not understand why their setting wasn't used. 2) If we give the user the ability to set the # of tracks within which to check, then we're just needlessly replicating functionality of duplicate prevention (0001966). |
|
|
Tested and 910, and although this seems to work as specced, I don't think it actually fixes the reported issue. e.g. I have 250 tracks in my auto-dj playlist. And yet: Track#12: Simon & Garfunkel - Feeling Groovy Track#24: Simon & Garfunkel - Feeling Groovy I think that we're on the right track, but that we need to solve this and 0001966 at the same time in a manner that is consistent. |
|
|
I think that the only problem is that hardcoded limit of 10 tracks, it should be more dynamic. Let's denode TRACK_COUNT the total number of tracks that can be added to NP - i.e. either the total number of tracks in Library or number of tracks in a selected playlist. Then the number of tracks to be checked in NP could be: max( 5, TRACK_COUNT/2) or even TRACK_COUNT/2 This way we are sure tracks won't repeat too soon. |
|
|
Yes, good idea! Fixed in build 912 according to 6171 note's suggestion ( 10 --> TRACK_COUNT/2 ). |
|
|
Isn't it accurate to say that: After half the playlist is used, the chance is 50% that a track will repeat. After 75% of the playlist is used, the chance is 75% that a track will repeat. After 90% of the playlist is used, the chance is 90% that a track will repeat. etc... If so, all that the revised implementation does is delay repetition until halfway through the playlist. e.g. Instead of getting 4 hours of 'good' non-repetitive music from a playlist, the amount of time for which that playlist is usable is reduced to 2 hours. I'll discuss this with Jiri tomorrow. |
|
|
Per discussion with Jiri, using an SQL query for a time-based approach wouldn't work for all playlist types. Consequently, the best compromise would probably be to switch the 50% to 75%. i.e. Track_Count * .5 --> Track_Count * .75 |
|
|
Assigning to Ludek. Btw, the most effective approach is using MulDiv( x, 3, 4). |
|
|
I don't understand note 6201. Currently (if Track_count/2 is used instead of 10 - build 912) Note: playlist = playlist selected on the Auto-DJ panel. After half the playlist is used, the chance is 0% that a track will repeat. After 75% of the playlist is used, the chance is 50% that a track from not recently played half of playlist will repeat. After 90% of the playlist is used, the chance is 80% that a track from not recently played half of playlist will repeat. etc... i.e. if the recently played half of playlist retains in NP it is checked. = tracks are selected from the second (not recently played) half in this case. The problem is if the user have set 'Keep only x tracks' in NP. There is a chance that a track from recently played half will repeat. Re: Track_Count * .5 --> Track_Count * .75 It is quite restrictive, cause if Track_count = 100 and 80 tracks from playlist is used there is no chance that one of 5-80 tracks will be used again as 81. i.e. 75% of tracks we can't use again. I thing 0.5 is better. |
|
|
Ok, per discussion with Jiri RepeatNumber changed (Track_count*1/2 to Track_count*3/4). Fixed in build 912. |
|
|
Verified 912. |
|
|
I re-opened, because this was fixed, but actually works only when source is a playlist, but if source is entire library or a filtered library then this doesn't work. Fixed in build 1195. i.e. RepeatNumber = Track_count * 3/4 where Track_count is count of tracks in Playlist/Library/Filter |
|
|
verified no regressions introduced 1224 |
|
|
Re-opened due to a regression. It no longer works for regular Playlists. Steps to reproduce: 1. Create a playlist with 20 tracks. 2. Set it as Auto-Dj source playlist 3. Test Auto-DJ => track X is sometimes added again although there are others tracks in the playlist that haven't been added yet. |
|
|
Fixed in build 1301. |
|
|
Merged to build 1295. |
|
|
verified 1295, tracks are replayed only after 3/4 of the playlist has been played already without repeats. |
