GNOME Bugzilla – Bug 538549
Use of ID3v2 Popularimeter for Rating (maybe Play Count)
Last modified: 2018-05-24 13:27:01 UTC
It would be nice for Rhythmbox to use the ID3v2 Popularimeter frame for song ratings and maybe even play count. Backing up the database and always maintaining a constant folder/file structure is not a reality for most people. It would also help Interoperability between other Players and Platforms. It would also solve other Rhythmbox bugs, such as this one: Bug 123345 – Handle file/directory moves done within and outside rhythmbox http://bugzilla.gnome.org/show_bug.cgi?id=123345 ------------------------------------------------------- Banshee has already begun work on this: Bug 532650 – [PATCH] ID3v2 Popularimeter (Ratings+Playcount) import/export http://bugzilla.gnome.org/show_bug.cgi?id=532650 ------------------------------------------------------- Thanks a lot for anyones help with this. - Darin
Is any of the devs interested in implementing this?
Seconded.
Third - really it is very annoying for me, since I share my music between two different computers and move files back and forth and backup them on DVD for safety reasons - I would rather not have to restore 100s of ratings, when I change the directory structure of my files to something better or install Ubuntu anew (which happens quite frequently). Pretty please! :-D
Just to add something useful to my whining :-) Here is how foobar tries to tackle the problem: http://winamp2foobar.blogspot.com/2008/09/rating.html There is a thread about Winamp and rating tags here: http://forums.winamp.com/showthread.php?postid=1485468 For ogg music format, there is an article about the comment structure (and possible arbitrary fields [like 'rating' ;-)]) here: http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html and http://www.xiph.org/vorbis/doc/v-comment.html the ID3 tags for mp3 format are explained here: http://www.id3.org/id3v2.3.0
As Rhythmbox will be back as default player in Ubuntu 12.04, this bug will probably get hotter in the next few months. A few points (I hope) worth mentioning: 1. Some users still show strong interest for a feature helping them to switch from one media player to another. This problem may be addressed by either migration tools, or writing to files. http://www.webupd8.org/2012/01/rhythmbox-finally-ported-to-gtk3.html#comment-413683022 http://askubuntu.com/questions/75715/how-to-migrate-from-banshee-to-rhythmbox 2. The question "should we write ratings and playcounts to files?" is still highly controversial and subject to "I HATE losing my ratings" vs. "Ratings are personal and should be stored in some sort of user-level database" flamewars: http://brainstorm.ubuntu.com/idea/5273 Nick, the patcher behind the Banshee implementation, does a pretty good review of the pros/cons (already mentioned above): https://bugzilla.gnome.org/show_bug.cgi?id=532650 . With Windows Media Player, Banshee, and IIRC a few other Linux players like Audacious using this POPM frame, maybe now is a good time to adopt it. 3. Creating "rating1,rating2,rating3,rating4,rating5" m3u playlists in Banshee, importing them in Rhythmbox, then mass-editing the properties of the tracks presents in each playlist works fine. Just tested from Banshee 2.3.3 to Rhythmbox 2.95, both players use filenames relative to ~, and track counts match after import. Maybe just publishing/documenting this workaround would work?
I'd like to chime in here, if I may. The current justifications omit one reason for solving this problem: If you download music legally or illegally, the tags are gonna be wrong, 99.9% of the time. If you manually import those files into RB (or it happens automatically through watch folders), any playcount or ratings info added to the library gets orphaned when you rename and/or move those files. THIS is my biggest rage about this problem: I have no burning desire to leave rhythmbox, and assumedly switching players is a relatively rare event. But listening to the new music you've acquired before sorting out the tags and not wanting to lose ratings & playcounts must surely happen very regularly. I honestly believe that this would be a much more regularly commented-upon issue if it wasn't such a horrifically nightmarish pain in the arse to sign up for bugzilla and find this page. (I assume this hasn't been fixed in 2.99.1; I can't manage to upgrade from 2.98 in xubuntu (problem here: http://askubuntu.com/questions/327007/upgrade-to-rhythmbox-2-99-1-in-xubuntu). If the tagging and always-on sidebar bugs were fixed i'd be overjoyed).
*** Bug 699745 has been marked as a duplicate of this bug. ***
I would love this too. It's probably (maybie the auto-correction tool too) reason, why I still use banshee. Thank you! :)
Dear Devs, Since this 3rd party no longer works (https://sites.google.com/site/airmind/rhythmboxplugins) and cross-platform specs have been drawn up detailing how to handle this (https://gitorious.org/xdg-specs/xdg-specs/source/575138ee6db957618631de56940540d1bcdf8525:specifications/FMPSpecs/specification.txt#L27), what - if any - chance is there of this ever being implemented? This bug alone is 6 years old, the problem has been around longer. Is there scope for a bounty or something to make this happen?
p.s. lots of info & links of how the winamp boys implemented it a few years ago here: http://forums.winamp.com/showthread.php?s=&threadid=315444&highlight=ratings+library+tag
Again as per the gitorious link above, thhe way to implement this for mp3 (others can read it & post the info for other formats if they wish) is: For ratings: Convert rhymthmdb.xml entry <rating>0/1/2/3/4/5</rating> to ID3 frame ID: TXXX Description: FMPS_Rating Text: <rating>/5 (i.e. it's out of 1 not 5 so needs to be converted) For play counts: Convert rhymthmdb.xml entry <play-count>#</play-count> to ID3 frame ID: TXXX Description: FMPS_Playcount Text: <rating>/5 (i.e. it's out of 1 not 5 so needs to be converted) To note: there are per-user options allowed within the guidelines but let's walk before we can run. Or rather, talk about walking, for >6 years...!
Are you going to work on this?
Well I don't know how to code but honestly I'm open to having a go. I'm glad you're online as I'm currently trawling through the buglist from the various older versions, trying to deduce whether this bug - indeed any bugs registered against older versions - remain pertinent when the version increases? This issue here is really more a feature request than a bug; should this kinda thing be somewhere else or is there nowhere else? Like I say, I'm open to doing whatever I can in order to help with this. I've recently learnt to code in R (maths/stats) so I've at least got SOME background... but before I even think about starting I don't know how the RB devs group works in terms of discussing how to implement something like this? Cheers
Bugs don't tend to go away by themselves. Feature requests, which also live in the bug tracker, don't either. How things work is: someone writes some code. If no one's going to write the code, there isn't much to discuss. If you have questions about how to do specific tasks in rhythmbox plugin, I can answer them, but that's about the limit.
To-do list, since I'm thinking about it, in no particular order: - Display/convert existing FMPS ratings/playcounts: If RB supported TXXX/FMPS_Rating then one could independently tag mp3 files in (e.g.) Kid3, or bring them over already tagged from other programs, and have them displayed in RB & saved into rhythmdb. This would need some kind of display conversion based on thresholds for the greater range of ratings in FMPS: FMPS_Rating -> <rating> 0 -> 0 0.001 to 0.199 -> 1 0.2 to 0.399 -> 2 0.4 to 0.599 -> 3 0.6 to 0.799 -> 4 0.8 to 1 -> 5 (playcount would need no conversion, just to be displayed & imported into rhythmdb) This would benefit people moving over to RB from elsewhere - no bad thing. - Write ratings to the TXXX in the files' tags at the same time as being written to rhythmDB, with the 'divide by 5' rule per my previous post. - Write existing rhythmdb ratings & playcounts to files. This would conceivably be a one-time-only thing, if you exclusively use RB, since after all rhythmDB info has been written to files, all future playing & rating done in RB would go the the file's tags and rhythmdb on a per-case basis, hence it'd be synced. HOWEVER! One could conceivably write a script to read playcount & ratings from rhythmdb and write them to the tags in the files. One could use cron to have this happen regularly (daily, or if modified date of rhythmdb is newer than a date stored in a log file of when the script was last run, or upon open/closure of RB) Or if this was a plugin, it could be set to run after RB has checked the library and watch folders. If it read FMPS tags for new files then one could bring in an mp3 from the internet to one folder, play it a few times, rate it, then get around to fixing duff tags and moving it to the correct folder, the latter two actions making it disappear in the eyes of rhythmdb, then appear as a new file elsewhere. This would usually strip the playcounts & ratings, but now wouldn't.
Ok, cheers John. I guess I'll follow up on the idea of the plugin when I have time. They're written in python right? Order would be - RB checks library & imports new files - Plugin converts any FMPS info from newly imported files into rhythmdb format & saves it there. - Plugin thereafter saves ratings & playcounts to FMPS in files in a per-file case during normal operation. - Plugin has 'force action' options, allowing user to force sending rhythmdb info to tags, and tag info to rhythmdb. Hopefully one would only need to the the first one, and do it once.
Would be a nice feature. has there been any progress on this?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/578.