File timestamp accessible in smart playlists?

[paolo]

Hello.

I discovered recently the Smart Playlist feature and I plan to use it extensively to identify recent additions to my music collection--which naturally corresponds to what I am most likely to play. It is great and I do not know how I missed it thus far.

A small issue is that "Date Added" is some internal notion created by GMMP which is not always great for me (for instance, I find as newly added all files whose path I simply renamed--something which, for some reason, I do fairly often).

I was wondering if (in addition to "Date Added", which I suppose satisfies most users) there is a chance to identify files through the filesystem last-modified timestamp. I did not find it in the variables of the Rule menu, so I suppose it is not possible today. But would it be possible to add it? My hope is that it would be easy to implement....

One comment I imagine is that, when identifying albums, there is not such a thing as a filesystem timestamp for the complete album but only one timestamp for every file belonging to the album. Personally, I could live perfectly well with any reasonable heuristic to attribute a timestamp to the album (e.g., the oldest or newest timestamp of all files belonging to the album).

Thanks!

p.

[GoneMAD]

smart playlists only have access to data stored in the database. on first scan, date added is set to the last modified time of the file.. since those files were already there. After the initial scan it'll use the scan time. Originally i had it always use the last modified time, however this caused a lot of issues. If you transfer files over from a PC over USB.. it keeps the last modified time of the file on your PC.. so those files new to the device would never show up in recently added.

There is really no good solution that handles every case unfortunately. If you delete the database and rescan it'll read all of the last modified times

[paolo]

Thanks, deleting the database and rescanning would work for me, as I update the collection on my phone only relatively seldom.

It should have worked already, but there may be some mistake in my filesystem timestamps (indeed, it is not always perfectly clear to me how many timestamps there are in each filesystem and when exactly they are preserved in a copy). I will revert back if I cannot solve the issue, but in principle the fact that on first scan the filesystem timestamp is taken should work for me.

Thanks--for the excellent player and for the incredibly fast reaction time! :-)

p.

[paolo]

I am trying to understand why what you describe did not work for me and I think I am understanding. My guess is that you use the timestamp of files for individual tracks and the timestamp of folders for albums (although, you explained to me in another thread that folder != album, so I am not sure if there are multiple folders which one matters). Is this correct?

Personally, I find timestamps of folders pretty fragile for most practical purposes (e.g., if you rename a file or a folder, they retain the last-modified timestamp, at least in most OSes and filesystems I know; yet if you rename a file, the containing folder gets a new timestamp; also, I think most copy commands and tools would respect the last-modified timestamp of copied files but not of folders--but I would need to check this in detail, this is only my feeling). In general, I would think that the behaviour of timestamps of folders, although certainly perfectly logical per se, seldom reflects one's own notion of changed contentof the folder (e.g., if I correct a typo in the filename of a track, it does not really become a new album, does it?!).

If my hypothesis above is correct ("the initial timestamp of an album is the timestamp(s) of (one of) the containing folder(s)"), would it be possible and sensible to change it into the following: "the initial timestamp of an album is the latest (or earliest, or average) timestamp of all files included in the album"?

Thanks!

p.

[GoneMAD]

"I am trying to understand why what you describe did not work for me and I think I am understanding. My guess is that you use the timestamp of files for individual tracks and the timestamp of folders for albums (although, you explained to me in another thread that folder != album, so I am not sure if there are multiple folders which one matters). Is this correct?"

nope. album added time is first track's (first scanned track of the album) file lastModified date (https://developer.android.com/reference/java/io/File#lastModified())


" I think most copy commands and tools would respect the last-modified timestamp of copied files but not of folders"

if you are using an android app to move/copy or rename then this is most likely not the case. Android's file apis are quite horrible now that scoped storage was forced on all apps. I am not sure they let you access the file properties anymore since you dont get to directly interface with it. Are you using a file manager to look at the last modified date of the renamed files?

" (e.g., if I correct a typo in the filename of a track, it does not really become a new album, does it?!)."

Folders arent used for times or any property.. just to decide on how to group. To answer your question the newly named file would get scanned in and associated with the existing album. The next database clean would remove the old file from the library

[GoneMAD]

oh are you restoring after deleting the database? That restores times i believe

[paolo]

My apologies: I should have deleted and rebuilt the database before my last post--I am not sure how the database got to the state it was. It turns out that rebuilding the database works like a charm, thanks!

Jul 8, 2021 18:46:51 GMT -5 GoneMAD said:

album added time is first track's (first scanned track of the album) file lastModified date (https://developer.android.com/reference/java/io/File#lastModified())

This is just perfect and produce the result I desire.

Jul 8, 2021 18:46:51 GMT -5 GoneMAD said:

Are you using a file manager to look at the last modified date of the renamed files?

I use Total Commander. On Windows I find it simply essential (I would be unable to use my laptop efficiently without); on Android I know it less, but appears as good as it is on Windows.

If now I could only get %cp% working on all screens and menus, everything would be just perfect... :-)

Once more, thanks!

[paolo]

Concerning dates, everything is clear, but something else puzzles me still: what is the function of "Order By" in a smart playlist? I have set it to be Composer Asc but the actual results returned are then ordered by the sorting field specified on the top right menu (the one besides the three vertical dots) which, by the by, does not contain Composer.

I thought that maybe the "Order By" in the smart playlist would only play a role in trimming the number of results, but, in fact, it is, again, the sorting menu on the result page (controlled by the 'custom_albumlist_metadata.json' file, to be clear) which decides; proof is that if one changes the sorting field in the result menu, the results change.

Maybe the simplest question is whether it would be possible to have Composer in the result sorting menu--that would be sufficient.

Yes, it is true: I do think the Composer field is arguably the most important for people listening to classical music!  :-)

[GoneMAD]

"I have set it to be Composer Asc but the actual results returned are then ordered by the sorting field specified on the top right menu (the one besides the three vertical dots) which, by the by, does not contain Composer."

'Order by' is what the database uses to sort the results by default if grouped by track (and if you have the "smart" sort order selected in the sort menu). Smart playlists were added in gmmp like 8 years ago as track lists only. Being able to group by other things and make custom views was only added in 3.0. I am pretty sure its the only player with this ability in smart playlists.

The only way to sort by composer is to group the top level by composer. I can add a feature request to add a sort by composer on the views that support %cp% trello.com/c/RAwnI1Ek

Composer has never been a priority and up until 3.0 was only accessible in the tag editor and now playing. 3.0 significantly improved support but its still not treated as a first class citizen. I dont listen to classical and based off feedback from users, only a handful of them do. I just say this because based off your posts you seem confused why everything doesnt work perfectly as you would expect for composers. I'll no doubt try to continue improving support but its just not a high priority

[MotleyGord]

paolo Keep in mind that there are no other Android music player apps that come even close to allowing the amount of display and sorting customization that GMMP does. I have tried many others, and still use another for a specific playback purpose in a hi-res application until GMMP is ready for this. But the library management and customizable list and now playing info in GMMP are leaps and bounds ahead of all others.

While I have only a few classical albums in my own collection, the Composer tag is something I use as well for who may have assembled a more modern collection, if applicable. Maybe this is a stretch for serious classical collectors, but it is actually similar to the idea of different Conductors, like the comparable Artist/Conductor. Having the %cp% tag available someday as the dev has suggested is in the works will just make GMMP that much better.

[paolo]

Thanks!

I guess I owe you an explanation for all the annoyances of the last few days (I am on holidays and it is a good time to try to "fix" a few things in my Android setup... ;^)

I am coming back with all these composer issues all over the place but I do not mean them as negative criticism. Please understand that, after trying several players, I use and purchased GMMP because it is already doing out of the box much better than *any* other Android player I tried. I personally care for very few features, overall, but indeed the composer in classical music is the starting point for just about everything: I do not think "let's listen to a Symphony no. 7" but "let's listen to Beethoven's Symphony no. 7"; the fact that I could select in a library a "Concerto for Piano and Orchestra in C major" tells me nothing until I know whether it is Mozart's, Beethoven's, or Busoni's. This is self-evident to any serious listener of classical music and makes it particularly horrifying when high-end commercial systems ignore this simple fact. A major manufacturer of (expensive) digital audio equipment answered me some 15 years ago, once I complained that Composer was supported only in some rare cases, that I should place the Composer as part of the Album title--and to date the same company has no Composer on their Now Playing screen!

Again, GMMP is doing much much better than them and for only a few USD/EUR! My suggestions are only that: suggestions by a user passionated about presenting well and using at best a fairly large music collection. Please understand that I thoroughly appreciate your help--and I know that clearly almost nobody else cares!

p.

[paolo]

Jul 9, 2021 11:45:42 GMT -5 MotleyGord said:

paolo Keep in mind that there are no other Android music player apps that come even close to allowing the amount of display and sorting customization that GMMP does. I have tried many others, and still use another for a specific playback purpose in a hi-res application until GMMP is ready for this. But the library management and customizable list and now playing info in GMMP are leaps and bounds ahead of all others.

While I have only a few classical albums in my own collection, the Composer tag is something I use al well for who may have assembled a more modern collection, if applicable. Maybe this is a stretch for serious classical collectors, but it is actually similar to the idea of different Conductors, like the comparable Artist/Conductor. Having the %cp% tag available someday as the dev has suggested is in the works will just make GMMP that much better.

I did not see this while I was writing my post, but I hope I made it clear that I definitely appreciate that!  :-)

p.