GNOME Bugzilla – Bug 614781
cannot track File Hierarchy changes and mislays song/playlist info
Last modified: 2010-04-05 22:11:33 UTC
As it stands, Rhythmbox is not able to directly track changes made to the file and folder hierarchy wherein a musical collection is housed. This appears to be true in all versions of Rhythmbox (from Ubuntu 8.04 through 9.10 and beyond). For instance if I see that I have misspelled the folder for Teh Who and correct that folder name, Rhythmbox lists those tracks as Missing. This makes sense. If those tracks happened to appear in any playlists, they would need to be manually re-added unless the missing file is returned to its former location (in the misspelled folder). This holds true for any file or folder name change anywhere in the folder hierarchy for the library (or any imported file or folder). Rhythmbox will, if set to scan the library for changes, add the "new" The Who files and folders; but there is no method by which these files can be associated with the old database information (playlist inclusions, ratings, &c). Right-clicking on a Missing track gives only two options: Remove and Properties. Once this relationship is broken there is no current method by which to repair it. Give Rhythmbox the ability to re-locate/re-associate Missing files/folders/collections, presumably through the right-click menu in Missing Files. Right-click on a Missing file (or a group of them) to tell Rhythmbox where that file is now located. This will then allow Rhythmbox to attach any database information previously attached to the missing file now with the file in its new location. In my example above, I would select all the Teh Who files and point to the The Who folder. Rhythmbox would then re-associate all library information formerly of Teh Who with The Who (including playlist inclusions, ratings, &c). (This functionality exists currently in iTunes for example.)
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 123345 ***
Thanks for point to the other bug report. I would like to assert that my proposed solution to the matter has certain advantages over the one proposed in that report. What is the preferred method for voicing this?
Implement your proposed solution and attach a patch.
Is this an attempt at humor? I am not a developer and I don't normally find that it is required that I be one to participate in these discussions. The problem in both bug reports may be essentially similar, but the two solutions have little or nothing in common. I really am just asking a question about etiquette or protocol around here.
You asked what the preferred method is and I told you. Adding a comment to a bug that no one is working on isn't really going to achieve anything, but go ahead if you like.
Ok, so adding a comment to a bug on which no one is working is not a solution you would recommend. I am not able, at this time, to write the patch in question. I tried putting my solution into a feature-request style bug report--which you have closed. Do you have any suggestions you might offer to one such as myself at this point?
I don't think there's anything you can do once you've excused yourself from actually doing any work yourself.
What? First, there are many ways to contribute to a project beyond writing code. Not to discount the writing of code, but we can surely agree that more goes into any application than the code itself. Second, this seems to imply that you feel that only qualified developers should participate in the Open Source community (in general) and Gnome bugs (in particular). Are you really taking up that position?
No, that's not what I'm saying at all. I'm not interested in having this discussion. Please drop it.
I didn't ask you to have this discussion. I hope that someone else will happen on my bug report and offer some useful advice on how I might be able to participate in the further development of Rhythmbox (an application which I care about and advocate). The remainder of this post is for anyone else. I posted this as an idea on the Ubuntu Brainstorm first: http://brainstorm.ubuntu.com/idea/23724/ There it was suggested that I file a bug report: https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/530270 That bug was received well enough, but it was there suggested that I file a bug report upstream. Which has brought me here. (I don't know how much more committed I could be to a software project or to a feature request.) The bug report of which this report is claimed to be a duplicate, though similar, takes the solution down a much more complicated path. Since a feature request is a proposed solution, if the solutions differ it would seem inaccurate to claim the feature requests were duplicates. I see no reason to give Rb the fuctionalities to navigate and change the folder/file hierarchy in order to solve the matter of missing files. I have a file browser for doing that already (Nautilus). Additionally, the need for md5 fingerprints may have value but is seemingly superfluous to this matter, and though the eventual inclusion of md5 information in Rb may faciliate file re-location (especially automated re-location) it is not necessary to make file re-location dependent upon md5 information (and may in some circumstances be detrimental). All Rb really needs to have is the ability to re-associate path/to/a.flac with path/is/now/b.flac in its xml files. I think the most appropriate place to include that additional functionality is within the Missing Files area (through a button, a right-click option, and/or a menu option). I am still happy to field any questions you may have.
This bug is closed, so it's pretty unlikely that anyone would ever read your comment. I've copied the useful portions of it to bug 123345. For what it's worth, I actually agree with you and if I was going to implement something like this, that's more or less how I'd do it.
I'd say it's worth a lot. Thanks.