Song ratings

[okneloper]

Thanks for the detailed explanation! 

The slot/MPD-defined tag, is this something that can be defined by moOde or is it MPD internals and can only be implemented by MPD developers? 

[Tim Curtis]

Generally if a tag is not supported by MPD then it won't get reflected in moOde. Below is the list of MPD supported tags.
https://www.musicpd.org/doc/html/protocol.html#tags

Given that there is no tag in MPD's list for "song rating" it would appear to be a non-starter.

[okneloper]

I see, thanks. Can you please confirm if this is possible at all (I asked previously):
can the filename be read from mpd and the rating tags pulled directly from/into the file?

[Tim Curtis]

Not possible because there is no ratings tag supported by MPD. This means that the data would have to be maintained externally in something like the MPD sticker database which would not be a trivial undertaking.

[TheOldPresbyope]

Basically, to enable this through MPD you have to

1. convince the MPD developer that a new MPD tag is needed by posting an issue and arguing persuasively for action. This gets it into the documentation. (Note: this step is not for the fainthearted. I and others have suffered humiliation at the hands of the BDFL when we failed to be sufficiently well prepared.)
   
2. create pull requests for changes to the existing MPD plugins to deal with the new tag---or convince others to do so
   
3. get the PRs accepted into the MPD codebase
   
4. make sure that your software app (moOde in this case) is using a new enough version of MPD to realize the fruits of your labor
   

Not to say it can't be done. Some time ago, I made it past step 1 when I succeeded in getting "work" added to the MPD tagset, arguing on the basis both of use cases and of its existence in musicology and the recording industry. Fortunately, I had an accepted definition I could point to.

This tag makes possible a sensible mark up of classical music, operas, etc., where  a single, titled work is composed of multiple tracks, each with its own title. Without it, one has to settle for album title as a substitute. Semantic nonsense, of course, and a ploy which often breaks down in practice because there was no "1 album = 1 work" rule in the recording industry. Not so big a problem in this age of streaming media, perhaps, but a biggie when dealing with tracks ripped from LPs and CDs.

I'm not comfortable enough with the MPD architecture and with C++ to propose PRs to the plugins myself. At one point I was building test files to see which MPD tags---not just mine but the entire list---are mapped from what fields in various metadata tagging schemes (ID3V2, VORBIS COMMENT, etc) but got stalled last year because of other activities (You know; what my grandkids call "IRL".). If I live long enough....

And now we return you to your regularly scheduled program.

Regards,
Kent

[okneloper]

Thanks guys. Sometimes things are more complicated than they should be... 

[okneloper]

I've taken a quick look and found 2 candidates for implementing the feature for the browse screen. Either the JS `function renderBrowse(data, path, searchstr)`, it could perform an additional request to a ratings subsystem and attach ratings the DOM, or modify the results right in the `command/moode.php`. Might affect the performance of browsing and might be an issue for really large lists, but as an optional feature, this would be infinitely better than no ratings at all. May I ask why you are so opposed to non-mpd tags?

[Tim Curtis]

I'm not opposed to any reasonable feature request regardless of what it involves and this one is certainly a reasonable request. I'd have to check the TODO list but I believe it's already on there somewhere and has probably been there for a long time but has not gotten any priority.

There is only so much developer time available and so items on the TODO list compete with one another and compete with bug fixes, troubleshooting and support, Forum administration, release administration, etc.

Which particular feature gets developer time is determined by using common sense, developer preference, user demand, outcomes from discussions here in the Forum and on Github and so on. It's a highly dynamic activity. Note that Features are always lower priority that fixing serious bugs.

Another way features get done is if another developer implements it and successfully integrates it into moOde in a way that can be supported by the projects more or less permanent members.

-Tim

[okneloper]

That was my next question - if you would be willing to accept this feature if it was implemented by someone (me) this way? Some guidance would also likely be required as at this stage I've got more questions than answers.

[Tim Curtis]

Generally you would either fork the Moode development repo on Github or download the sources zip into your local development environment and then start modifying the sources, creating new sql table, etc., whatever is required to implement your feature.

If the adds/changes are relatively simple you can just email me and get a discussion going so I can start to understand the feature and begin to test the code out. If the feature involves more extensive changes then you will need to learn how to construct a Git pull request.

I think for the ratings feature you would need a new sql table for example cfg_ratings which has columns id, song,rating and then code that does add/edit/delete on the entries in that table, and also UI code to display and accept ratings entries.

Also decide where you want the ratings to appear for example in Tag view tracks list, Playlist, underneath cover in Playback and CoverView, etc.

-Tim