random: add --time option, update docs #2322
Conversation
|
I just realized that this does not work with -a. I need to figure out how to list the individual tracks of an album in order to get the total length. |
|
Ah, tricky! Someone was asking on IRC about adding a pseudo-field to calculate exactly that. But in the mean time, you can use something like |
|
It's pretty slow with -a, maybe someone knows how to optimize it. Otherwise, it seems it all works. Oh, in case someone comes across this randomly, it's album.items(), and not .tracks(), as written in the above post. |
|
It seems fast enough for me with -a. I love it! Are there still plans to integrate it with the 'beet play' command? |
|
I have #2304 open that adds --random to the play plugin, but if this gets merged, I'll close that one and open a new one because I had made some changes that didn't need to be made. |
|
awesomeness. |
|
Are there any other steps I need to take in order to get this ready to be merged? |
random: add --time option, update docs
Also, avoid setting an unnecessary field on the album objects. :/
This is the payoff from the earlier refactorings: the control flow is now consistent and clear, and the two factors (time vs. number, equal-chance or not) are orthogonal. See also #2322.
|
Nope; I was the bottleneck here, sorry! I've merged, and I've also done some substantial refactoring. Can you please take a look to check that I didn't mess anything up too badly? Also, one thing came up when I was looking over the code: I noticed that your strategy will often include the shortest songs in a person's library. That is, if I have a 2-second song somewhere, then it's quite common that there will be a 2-second shortfall when selecting other songs, so that short song is very likely to be picked at the end. I don't have any great ideas for how to resolve that, but I thought I'd mention it. |
|
Those changes to the code look great, thanks for taking the time to clean it up. My simple tests show everything is all good. As far as the short song issue, I though of that too, but couldn't think of any way around it. A user-based solution might be to use queries like length to filter out a known short song that keeps being used, but with a big library there usually are several short songs that would fill the gap, and maybe not be repeated as often. |
|
Another option could be to have an option of a minimum duration for a song to be considered. For instance, I might not want any song less than 1 min to be added to the playlists: I have no way to check this right now, but I, for one, expect all such songs of my collection to have no interest out of context. ;) |
|
I like the minimum-length heuristic. It might be worth noting that the problem of finding a playlist of music that comes closest to a given maximum time (without going over) is exactly the bin packing problem, which is NP-complete. That implies that it might be tricky to get a great solution here, although the addition of randomness makes the question a little more complicated. |
|
Can a minimum length not be specified with 'length:0:02..' to get tracks longer than 2 seconds? That's what I was suggesting earlier, but I've never used that query... |
|
Yes, good point—that query does work out of the box for avoiding short songs, @diomekes. I've also spent a little while thinking about the algorithmic problem (randomly sampling a bin packing solution) and I still don't see a clearly better solution than the current greedy algorithm. Maybe one small improvement, however, would be to shuffle the resulting list before returning it. This way, at least the short tracks won't always appear at the end of the playlist? |
|
Yes, the list could be shuffled a second time after going through the timed selection process. |
Adds feature #2305