GMMP 3.0 Custom Metadata Info

[paolo]

I am coming back to this thread after a few months and I have a question: if I use %fp% and %cp% in custom_albumlist_metadata.json for use in a smart search result, I find both of them empty whereas, for instance %al% works fine. I understand that composer support may not be complete everywhere, but I read here (in fact, in response to a post of mine) that %fp% should work. Although I am never really really clear of which view is which, the following seems to suggest too that practically wherever I see %al% working, both %cp% and %fp% should work (whereas after a smart search %al% is fine but not the others):

ALBUM = %al% - (Now Playing, Album, Queue, Song/Album Details, Bookmark, Playlist, AudioFile)
COMPOSER = %cp% - (Now Playing, Composer, Queue, Song/Album Details, Bookmark, Playlist, AudioFile)
FULLPATH = %fp% - (Now Playing, Queue, Song/Album Details, Bookmark, Playlist, AudioFile, File, Folder)

I feel like I am doing something wrong, but what?

Thanks!

p.

[paolo]

Oh, I found back this answer which I had forgotten. But I am a bit puzzled: because albums could have multiple paths or multiple composers there is no way for me to get either of them for an album with a single composer or stored in a single folder? I had raised the issue of the artwork, bcause I believe the same is true about the artwork (there could be one embedded in each file of an album and maybe an additional artwork in each folder of an album): yet, for artwork there is some heuristic to select one and it works fine (at least for me). Couldn't the same heuristic be used for selecting a composer or a folder path? Or simply have %cp% take the COMPOSER field of the album files if these happen to have all the same composer? Or %cp% take the COMPOSER field of the first file in an album? It seems to me that almost any reasonable heuristic would work for well behaved situations; on the contrary, the current system, if I understand it well, results in me being completely unable to obtain in any possible way or workaround the composer for an album (which, in my case, is always a single work or opus and thus naturally has a common COMPOSER).

[MotleyGord]

There is really no association of an “album” between individual files. Each one needs to have fields like composer completed if that is what you want. Any tag editor should be able to help complete these for you. But the media player should not assume these if this are no tag fields in those cases.

[GoneMAD]

Feb 21, 2022 3:53:20 GMT -5 paolo said:

Oh, I found back this answer which I had forgotten. But I am a bit puzzled: because albums could have multiple paths or multiple composers there is no way for me to get either of them for an album with a single composer or stored in a single folder? I had raised the issue of the artwork, bcause I believe the same is true about the artwork (there could be one embedded in each file of an album and maybe an additional artwork in each folder of an album): yet, for artwork there is some heuristic to select one and it works fine (at least for me). Couldn't the same heuristic be used for selecting a composer or a folder path? Or simply have %cp% take the COMPOSER field of the album files if these happen to have all the same composer? Or %cp% take the COMPOSER field of the first file in an album? It seems to me that almost any reasonable heuristic would work for well behaved situations; on the contrary, the current system, if I understand it well, results in me being completely unable to obtain in any possible way or workaround the composer for an album (which, in my case, is always a single work or opus and thus naturally has a common COMPOSER).

the fields available to a certain view are determined by how the database is set up (its fairly normalized to prevent any sort of duplication.. so a single query can potentially do a lot of table joins). Everything needs to be done in a single database query. There is no post processing done. All database queries are dynamically generated. Since albums have no concept of file path, one would have to get all tracks associated with an album and then parse the filenames to get the parent folder. This is not possible in a single sql query (or maybe it is but such a query is not doable in gmmps dynamic query system)

%cp% at the album level is another tricky query. composer is associated at the track level and there is no guarantee that a track will have a composer which makes getting all the results back (with and without composer) is fairly complicated. composer was expanded at some point in 3.2 or 3.1 to be exposed to the track based views because that was a lot more simple for me to implement. Also any given album could have 5+ composers (at least thats the case with the music i have with the composer tag)

[paolo]

Sorry, I was probably unclear.

Here is the thing: All my MP3 files have a COMPOSER tag, an embedded artwork, and all of them have, of course, a filesystem path. "Albums" in my case correspond to folders but they are appropriately tagged, so GMMP understands them perfectly. Each folder has also a folder.jpg file with the artwork. In my case (but I understand people may have different habits), all artworks in an album and in the containing folders are the same. With only some exceptions (largely irrelevant to this discussion) all composer tags in an album are identical.

I use smart searches and I specify "Grouped by Album". Since "albums" are for me complete musical works (e.g., a concerto or a symphony), this is perfect to find, for instance, the last musical works I added to the collection. It is great.

The glitch is that I cannot put a composer on them. The reason is that, as I understand, albums have intrinsically neither the notion of a composer (because they could have as many as one per track in the album) nor a filesystem folder name (because the files of an album could be anywhere in the filesystem). Even without the composer, if I had the name of the enclosing folder of any of the files (it is the same for all), I could extract the composer from there.

While I understand all this and the reasons why there is no immediate solution to my problem, I wonder whether it could be possible to implement a slightly different strategy when constructing the database: for instance, the composer %cp% could be the COMPOSER of any of the tracks, if they all have the same composer; similarly, the folder %fo% could be the folder of all, if all tracks are in the same folder; otherwise, they are left empty as of today. It seems easy to implement, should not create problems to anyone else, and would give me (and anyone caring for classical music) a solution. I could also go for something sensibly simpler albeit less elegant: %cp% could be the COMPOSER of *any* of the tracks (at random, or the first track); likewise for %fo%.

I was trying to suggest in one of the previous post that it seems to me that the same problem applies also to the artwork and, contrary to the composer problem to which I seem to be the only one interested, affects everyone. And GMMP already implements some strategy by associating a single artwork to each album. I have no clue about the heuristic GMMP implements to select which one to pick, but (for me and, apparently, for most users) it works perfectly fine. I was suggesting that exactly the same could be applied to COMPOSER, folder, and perhaps a couple other fields.

I hope it is more clear now.

[paolo]

@gonemad, our messages crossed on the internet. I see your point, alas.

[paolo]

To repeat one of my suggestions above, could you return a COMPOSER at random from any of the tracks? Me, I would be happy with it and should be a single query, albeit an ambiguous one. Or?

[GoneMAD]

"I wonder whether it could be possible to implement a slightly different strategy when constructing the database"

The database structure is certainly not changing. db structure changes are not to be taken lightly

exposing %cp% is doable but like i said its just more complicated. I understand your need but none of this is a priority for me. Pretty sure its listed somewhere on trello but its nothing i planned on looking into anytime soon. As you can see there are hundreds of requests.. plenty which have come like 5+ years ago

[GoneMAD]

Feb 21, 2022 10:44:31 GMT -5 paolo said:

To repeat one of my suggestions above, could you return a COMPOSER at random from any of the tracks? Me, I would be happy with it and should be a single query, albeit an ambiguous one. Or?

No. There is no halfway solution. As is right now if i would make it %cp% available, anything without a composer would just not return in the results at all (not a blank composer.. the album just wouldnt appear at all). That's a major issue which is why its disabled for the album list

[GoneMAD]

and just to be clear. %cp% in the album view is not a "impossible to do" / "not going to do it" type thing. Its simply a prioritization of what im working on. I know you want something on the more immediate timeframe

[paolo]

Thanks, got it. I appreciate you taking the time to think about it. :-(

[viper21]

Hi.

I'd happy if someone could help me with the custom metadata syntax in GMMP for the following condition:

If either the playcount (%pc%) or the skip count (%skp%) is greater than zero, then display the track rating (%ra%). In other words, if the track has neither been played nor skipped, then don't show its rating.

Thank you.

[MotleyGord]

Mar 24, 2022 16:04:22 GMT -5 viper21 said:

Hi.

I'd happy if someone could help me with the custom metadata syntax in GMMP for the following condition:

If either the playcount (%pc%) or the skip count (%skp%) is greater than zero, then display the track rating (%ra%). In other words, if the track has neither been played nor skipped, then don't show its rating.

Thank you.

Have you tried the $notempty() function?

[GoneMAD]

id do something like:

$ifgreater($max(%pc%,%skp%),0,$rating(%ra%),)

[viper21]

Mar 24, 2022 20:41:51 GMT -5 GoneMAD said:

id do something like:

$ifgreater($max(%pc%,%skp%),0,$rating(%ra%),)

That didn't seem to work. Rating is always displayed even when track has neither been played nor skipped.