Quodlibet: Store ratings and play counts in tags whenever they're modified

[CreamyCookie]

Given that "Save Ratings and Play Counts" is enabled in the option, whenever the ratings are set, or a song has been played, write rating or play counts to the tags of the song.

Currently one has to use the Force Write plugin, but given the bug reports regarding ratings, most users seem to expect "Save Ratings and Play Counts" to mean that QL stores the ratings automatically in the tags, whenever they change and not just, as is currently the case, when plugins such as "ReplayGain" or "Force Write" are used on the songs.

[nodiscc]

Currently one has to use the Force Write plugin, but given the bug reports regarding ratings, most users seem to expect "Save Ratings and Play Counts" to mean that QL stores the ratings automatically in the tags, whenever they change.

I just wanted to confirm this is the behavior that I was expecting. Having to manually "Force Write" is confusing and easy to forget, it has lead me to losing rating data more than once :)

Though some users may not want to have their files forcibly written to. May I suggest implementing as an option for the Force write plugin? I.e. to have ratings saved to file automatically on change

• Enable the Force write plugin
• In the plugin preferences, enable Force write automatically when metadata changes

[lazka]

There was a plan to add a timestamp for when any playback statistic related value was changed (needs_write = state_timestamp > file_modified_timestamp). This would allow to write ratings etc at a later point, manually, or do writes of multiple changed files every 10 minutes or so..

[CreamyCookie]

Though some users may not want to have their files forcibly written to. May I suggest implementing as an option for the Force write plugin? I.e. to have ratings saved to file automatically on change

Maybe I'm wrong about this, but I think making this part of the main application would be better, since there's already an option called "Save Ratings and Play Counts" and as, for example, you and me, have said, we expected this to store the ratings and play counts in the tags, not just in the song database. (btw. Does QL really completely stop storing ratings if this is disabled?) Furthermore, plugins currently can't listen to ratings changes (#963), so the plugin might have to check this manually over and over again.. I guess play count changes can be handled with an events plugin, but I wonder if this is really the cleanest solution.

However, you're right about the point that some people wouldn't want their files to get overwritten. So maybe, to make the distinction between saving them at all, and storing them in the tags more clear, we should add an option beneath "Save Ratings and Play Counts", which states something like "Also write to tags, _if supported by the file type_". (Since not every format has an official rating tag.)

There was a plan to add a timestamp for when any playback statistic related value was changed (needs_write = state_timestamp > file_modified_timestamp). This would allow to write ratings etc at a later point, manually, or do writes of multiple changed files every 10 minutes or so..

That would be great! And it could also be used for tagging changes in general, right? So, users could add a ReplayGain value to hundred of songs, but instead of getting written to the files immediately, this would happen in the background at certain intervals.

[declension]

Surely every O/S (or hardware) disk cache should take care of asynchronous writes better than we could.

Either way I'm also keen that this is supported in the core (configurably).

[ghost]

any updates on this?

[zsau]

I think this would also help my use case. I don't save ratings or playcounts to tags, but still run into the problem that if QL exits abnormally, certain state info gets lost (including last played date as well as view state info such as the current browser selection). Saving more state either immediately or on a timer would mitigate that greatly.

(If you're wondering why that would be a common occurrence, I run QL via X11 forwarding. The connection will time out if I let the client sleep without quitting QL first, eventually causing QL to die on the host.)

If there's support for implementing this in core, I might have a go at it. Any implementation tips would be welcome, of course.