Bugzilla – Bug 1330
new music should work on creation date
Last modified: 2012-03-10 06:33:49 UTC
The new music section appears to work on the modified date of a file, rather than the created date. It would be nice to have the option to specify that it work on the latter (as otherwise, editing a tag moves items to the top of this list).
*** Bug 1332 has been marked as a duplicate of this bug. ***
At the risk of adding more options to the interface, it would also be nice to have an option to specify how far back to go to define something as "new". I have a "new music" smart playlist in itunes, and I use 30 days. I can't really tell what SS is using. Some of my albums currently listed under "New Music" haven't been added (or even edited) for at least 6 months.
there is a setting in server settings->behaviour called "new music limit" which simply sets the number of items to show.
This will require a change to the db schema - as we don't currently keep track of ctime.
I strongly agree that New Music should reflect creation time and not modification time. 'New Music' is useless as it stands.
Erland's third-party plugins support "new music only" browse menus. It's fairly easy to configure "New Albums" and "New Artists", that don't include updated music.
*** Bug 10775 has been marked as a duplicate of this bug. ***
I want this too, I'll add it for 7.5. I will also add a pref to the My Music tab with the following choices: Sort new music using: Date modified (sorts by mtime, default) Date created (sorts by ctime desc) Date added (sorts by track id desc)
(In reply to comment #8) > Sort new music using: > > Date modified (sorts by mtime, default) > Date created (sorts by ctime desc) > Date added (sorts by track id desc) Date added would use the 'id' column in tracks_persistent, I presume? There's an integer 'added' column in that table... is it for something else, or does it just go away? I thought that from past discussions, ctime isn't present in all file systems. Would you just fall back to mtime in that case? What if you have a mixture of tracks both with and without ctime?
You're right there is an added column, that might be better. And ctime should exist on all filesystems I think, if not then yeah, fallback to mtime.
The purpose of the "added" column is that we don't want it to be changed, it should just be set the first time a track is added to the library. This is how it was implemented initially, I'm not sure if it has changed since then. Since it's only set the first time it doesn't really matter if it's set by using the ctime or mtime, in most cases they are going to be approximately the same the first time a track is scanned with Squeezebox Server.
(In reply to comment #11) > Since it's only set the first time it doesn't really matter if it's set by > using the ctime or mtime, in most cases they are going to be approximately the > same the first time a track is scanned with Squeezebox Server. You wouldn't store ctime or mtime in the added column. You'd just store now() when the track is first scanned.
not sure whether the solution will be via "added" or otherwise. agree mtime and ctime probably don't matter in the process of adding new tracks to an existing library, but if a library has to be recreated from scratch then ctime should be the first choice to populate, falling back to mtime.
Moving P3 and lower bugs to next release target
Oops, meant to move that to 7.6.
*** Bug 12145 has been marked as a duplicate of this bug. ***
I see that bug 12145 has been marked as a duplicate of this bug (1330). But I don't see in the bug 1330 documentation, any explicit inclusion of the 12145 requirement that when an album is continually added to, over a period of weeks or months, it's desirable that the album be seen as having a time equal to the most recent track added. If it does indeed include this requirement, I'd happily stand corrected!
(In reply to comment #12) > You wouldn't store ctime or mtime in the added column. You'd just store now() > when the track is first scanned. That's the way to go. Windows may be storing a file's creation time in ctime, but most other POSIX-compliant systems use ctime to store the file's inode change time (i.e. changing a file's permissions or moving it will update its ctime). I guess using something like min( ctime, mtime, now() ) would be a smart way to initialize the ctime column in the database, since it probably would prevent old tracks to appear in the new music list. Not sure whether Windows updates mtime or not when you change one file's properties, but in case it doesn't, it should be safe to use it to track true changes (e.g. tag updates).
*** Bug 17697 has been marked as a duplicate of this bug. ***