Bugzilla – Bug 12145
Can 'New Music' order albums based on timestamp of the most recent file added?
Last modified: 2011-01-14 13:07:02 UTC
Can 'New Music' order albums according to the *most recent* file added? For preference, 'most recent' should refer to creation time, but modification time is ok for me. This would be useful when an album gets files added to it over months. An example: BBC radio 3 is broadcasting all 104 of Hadyn's symphonies at the rate of two a week!). I have no idea how that might be done.
see bug 10775. This would fall under the same scope, so worth merging the two and putting any ongoing comments there.
*** This bug has been marked as a duplicate of bug 10775 ***
Please keep this as a separate bug. This is a perfectly reasonable request, while bug 10775 is unlikely to be considered. Glomming them together means that this request will die. New music is presented as a list of albums, but the time used (whether MTIME, CTIME, or the time added to the database) can be determined only based on the tracks that make up the album. The important part of this request asks that the track used to determine an album's sort order in New Music should be the track with the most recent date.
Reopening for continued discussion
also bug 1330. They are ALL the same framework. Having multiple bugs fractures the design and you end up with ONE api getting pulled in multiple directions. No one can claim one way or another is likely or unlikely without putting the discussion focus on a SINGLE design path.
I agree with KDF, this bug as well as 10775 appear to be dupes of 1330. Jim please let me know if you disagree with that and why. Else I will close these in favor of 1330
Here's why: From past discussions going back _years_, developers have made it clear that basing New Music ordering on anything by MTIME is impractical. It's not going to happen. The other two bugs are dupes of one another. This bug has nothing to do with that discussion. It's about how you arrive at the date/time of an album so that it can be ordered in a logical manner in New Music. Normally, all tracks of an album ripped from CD will have the same time (within a minute or two), and this bug isn't an issue. But when an album is continually added to, as in the case mentioned above, it's desirable that the album be seen as having a time equal to the most recent track added.
Created attachment 6257 [details] proposed fix From what I can tell, the query being run to order albums by descending time always uses the time from the first track in an album (as ordered in the database, not by tracknumber). I don't believe this was intentional, just the behavior of the GROUP BY clause. This patch should fix that and use the time from the most recent track instead.
Andy: can you evaluate the attached patch for inclusion to 7.5.x
Seems like a perfectly reasonable request, I'll add it in 7.5.
and the other two should be closed, if this is the end of such discussion. If this is the only needed fix and the others will not be fixed, then it is very much part of this discussion and should be addressed as a result of this discussion.
Any chance I could personally apply something like the proposed fix to my (deliberately not up-to-date) installed Squeezecenter (Version: 7.3.3 - 27044 @ Mon Jun 15 15:14:08 PDT 2009)? Martin
Martin, If you run from source code you can apply the patch manually by changing the line shown in Age.pm. If you are using the installed windows application, then you cannot do so without the developers' kit from activestate.com.
(In reply to comment #13) > Martin, If you run from source code you can apply the patch manually by > changing the line shown in Age.pm. If you are using the installed windows > application, then you cannot do so without the developers' kit from > activestate.com. Ok. So how do I run from source code? And is it lot slower than the installed windows application?
Moving P3 and lower bugs to next release target
Which release did (or will) this fix appear in? It doesn't seem to be in version 7.5.0 - r30464.
*** This bug has been marked as a duplicate of bug 1330 ***