GNOME Bugzilla – Bug 404180
Move to Trash doesn't remove entry from Library File rhythmdb.xml
Last modified: 2018-05-24 12:19:18 UTC
Please describe the problem: When you right click a song, and select "Remove", it removes the song from the Library listing, as well as the rhythmdb.xml Library file. However, when you right click a song and select "Move to Trash", while it does move the song to the trash, it leaves an entry in the rhythmdb.xml Library file. This is incredibly minor, and a little picky... so I apologize if it's being too picky, or unreasonable. In fact, I notice that it also adds a line to "hide" the file moved to the trash. So there may be some reason for not removing the entry that I'm simply not aware of. Steps to reproduce: 1. Right click a song, click Remove. The entry in the Library file will be removed. 2. Right click a song, click Move to Trash. The entry in the Library file remains. Actual results: Items Moved to Trash clutted up the Library file. Expected results: Items Moved to Trash should also be removed from the Library file, just as items "Removed" from the Library are. Does this happen every time? Yes. Other information: Again, I apologize if this is being too picky. Rhythmbox is one of the only players I've used that actually keeps a clean Library database file (removing song entries most of the time, as well as lengthy Podcast entries), and I was actually very excited about it! I am really really impressed with it. It's something I've wanted from every Library-based player I've used, but no developers seem to take the time to make it happen. In fact, many Library based players I've used tend to inflate the Library file when items are removed or deleted. The only reason I post this or wonder is because I enjoy how clean the Library keeps itself most of the time, and if someone were to do a huge amount of file managing and deleting through Rhythmbox, it may create a large Library file that may also lengthen load times in the long run. Anyway, I'm really enjoying the player as a somewhat new user, and am really impressed by the whole thing! Maybe I'm weird by being impressed by a player that keeps a clean Library file... but oh well. I even enjoy and appreciate that! Thanks for everyones work on this very much, and for any help with this bug/misunderstanding. Thanks again! - Darin
Created attachment 88879 [details] [review] I've been using rhythmbox-0.10.0 source
Hi, I've recognized this problem too and found your bug report. Because nobody did reply I tried to fix it myself and it worked! This is my first patch ever, so if I did something wrong, please tell me. With the patch rhythmbox deletes the song before moving it to trash.
Jan's patch looks like it removes the track from the database and then moves the associated file to the wastebasket/trash. If the option to monitor the library is enabled, is it possible that in between these two actions, the library monitor could notice this track is present on the disk but missing in the database, and re-import it? i.e. Maybe the patch should move the file to trash and then remove it from the database. P.S. See also bug 424072 which is probably a duplicate of this.
>i.e. Maybe the patch should move the file to trash and then remove it from the >database. I tried that too, but it didn't work, don't know why. >If the option to monitor the library is enabled, is it possible that in between >these two actions, the library monitor could notice this track is present on >the disk but missing in the database, and re-import it? I'm using the patch for 2 months now it works fine. IMHO it's not possible that the library monitor re-import the file because "impl_delete" is the same like clicking on "remove" on a file's context menu. (hm... english correct?)
I recognized this still in 0.11. After my patch it's working though, could it be committed?
You know, it's very confusing when nobody is answering. Can someone review my path?
*** Bug 424072 has been marked as a duplicate of this bug. ***
I don't think this is the right way to do it. Apart from anything else, RhythmDBEntry objects can't really be used after they've been deleted. Trashing something should be completely reversible. Currently it is, although it's a bit difficult. You have to find the file in the trash, figure out its original location, and move it back manually. With this patch, you lose your play count, rating, etc. with no way of getting them back. A better approach (and one I started working on a while ago, but never found the motivation to finish) would be to add a new entry type for trashed entries, which would store the original location. These entries would be displayed in a new 'trash' source, which would still allow them to be played, along with providing an action for restoring them to the library. Rather than becoming hidden when the file is not present, these entries would be deleted immediately.
I think that applying Jan's patch (or something like it) right now would still be a noticeable improvement on the current behaviour, and that Jonathan's ideas in comment 8 would be a nice future enhancement (after all, its a non-trivial bit of work with UI changes too). i.e. If it were up to me, I would postpone the idea in comment 8 as a separate enhancement bug, and implement the short term fix.
Maybe it's good to implement a message box which says something like "All library information like play count, rating, etc. will be deleted, do you really want to remove this file from your library?" for the "remove" command. What do you think?
The data loss with the patch is worse. If you want to do something quick, you could make it only remove the DB entry when library monitoring is turned off. If library monitoring is turned on, the file should still be in the database until it's physically deleted.
I think it would at least be good to prevent these moved-to-trash files from showing up in the library (as Missing Files) as they currently do. Would it be feasible to have RB monitor the trash and remove from the db when the trash is emptied (when the file is no longer in the trash)?
(In reply to comment #12) > I think it would at least be good to prevent these moved-to-trash files from > showing up in the library (as Missing Files) as they currently do. > > Would it be feasible to have RB monitor the trash and remove from the db when > the trash is emptied (when the file is no longer in the trash)? That's what the monitoring should do.
Hmm, is that feasible though? The trash is not part of the library (for most users), and trash folders can be on any mounted drive, and even on removable media which has been removed, but will reappear when the media is reinserted.
*** Bug 575404 has been marked as a duplicate of this bug. ***
*** Bug 595013 has been marked as a duplicate of this bug. ***
-- 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/314.