deleted songs listed again when using library watch

Bug #75654 reported by wiertel
84
This bug affects 17 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
In Progress
Low
RaduStoica
Rhythmbox
Expired
Medium
rhythmbox (Ubuntu)
Triaged
Low
Unassigned
Declined for Intrepid by Pedro Villavicencio
Declined for Jaunty by Pedro Villavicencio

Bug Description

Rhythmbox does not remember that I have removed (Edit -> Remove) a track from the Library.
After selecting "Move to Trash" track is listed in "Missing Files" but the file is not removed and is back in the Library (and even on the playlist it was before) where I run Rhythmbox again.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug. What version of Ubuntu and rhythmbox are you using. Is that specific to playlists? Could you run rhythmbox -d and note what is written when you remove the track. If you move the file to trash it's listed as available by the playlist? That's weird. What does happen if you try to read it then?

Changed in rhythmbox:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
wiertel (wiertel) wrote :

I'm using Feisty now and Rhythmbox 0.9.6, but it was the same before I get Feisty installed.
Scenario 1 - removing track from Library:
0. Directory added to the Library
1. Select track
2. "Remove" track - track is removed from the Library
3. Restart rhythmbox
The track is back in the Library (not instantly). Maybe it is meant to show every file in the directory, but I would like it remembers that I don't want to see this track.

Scenario 2 - "Move to Trash"
1. Select track
2. Select "Move to Trash" - track is deleted, rhythmbox show the track in "Missing Files" as when I manually delete a file that was in the Library; in rhythmdb.xml this file's entry has attribute <hidden>1</hidden>; the file is still on disk
3. Restart rhythmbox - track is back

Revision history for this message
wiertel (wiertel) wrote :

"Move to Trash" doesn't remove file because gnome_vfs_find_directory() in rhythmdb_entry_move_to_trash() returns GNOME_VFS_ERROR_NOT_SUPPORTED. Rhythmbox hides the file then. But I still don't know why the file is visible again after restart.
The reason for my problems with Trash is that I have my homedir and my "Library Location" directory on different partitions.

Revision history for this message
Sebastien Bacher (seb128) wrote :

The problem with deleting files on different partitions is gnome-vfs bug #33212, I've forwarded the problem with songs added again when using the delete option if the song is the the library watched directory: http://bugzilla.gnome.org/show_bug.cgi?id=388568

Changed in rhythmbox:
importance: Undecided → Low
status: Needs Info → Confirmed
Changed in rhythmbox:
status: Unknown → Unconfirmed
Revision history for this message
Tobias Strauß (tocomo) wrote :

i use rhythmbox 0.97 on feisty. I can mark "move the files to trash". But i am used to see an new tree-entry under Library, for final delete action.
I did set the option "watch library" too.

Revision history for this message
Scipione (sndsergiu) wrote :

I have the same problem to, when I want to delete a song, rhythmbox or amarok can't send to trash that sound. The message I found is "Unable to find or create trash directory" . That's annoying!!!!

Changed in rhythmbox:
status: Confirmed → Triaged
Revision history for this message
Liam (liam-dennehy) wrote :

I have my library on a CIFS share, and when I want something deleted, I would like it deleted, but Move to Trash fails (for reasons above) silently. Surely this should be detected and presented to the user, so that he can take the choice either to leave the file as-is, or delete it outright in-place?

Revision history for this message
Rodrigo Reis (rreis) wrote :

I'm using rhytmbox 0.11.6 on Ubuntu Intrepid, and just lost my whole mp3 library.
I did set the option "watch library", and my mp3 files were stored in a NTFS partition.

The partition is corrupted now, I can see that the disk space still being used, but i can't see the files and scandisk can't repair the partition.

Revision history for this message
Yuriy Voziy (yuretsz) wrote :

The most stupid bug I've ever seen. I hate it.

Changed in rhythmbox:
importance: Unknown → Medium
Revision history for this message
Alexandre Provencio (alexandreprovencio) wrote :

In addiction, Rhythmbox can't detect songs removed from outside (ex: file browser) even though living inside the monitored directory. I have smart playlists based on file location, if I move a file from one location to another even though still inside the monitored tree, changes won't be detected. Should I open a new bug report on this?

Changed in hundredpapercuts:
milestone: none → precise-4-music-video
importance: Undecided → Medium
assignee: nobody → Papercuts Ninja (papercuts-ninja)
status: New → Triaged
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

I've just attempted to reproduce this bug on 11.10 using Rhythmbox 2.90.1 and am unable to do so. When I remove a file from my music library using Edit->Remove then reboot Rhythmbox, the file entry is nowhere to be seen, suggesting that it has been successfully removed from rhythmdb.xml. Can anyone else confirm this?

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

It turns out I was mistaken. This bug does still affect Rhythmbox and I just wasn't doing it right. The 'Remove' feature works as advertised if the file is not in the folder designated as the music library in the Rhythmbox preferences (~/Music by default). If the file is in there and the user attempts to remove it from the database, it is reloaded the next time the library is scanned.

Changed in hundredpapercuts:
assignee: Papercuts Ninja (papercuts-ninja) → Chris Wilson (notgary)
Changed in rhythmbox (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Chris Wilson (notgary)
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

I'm having a go at fixing this just and and a question has just occurred to me: how useful is this feature? Is there really a use case for people not wanting to display all the tracks on their hard drive within Rhythmbox while keeping the files intact? It wouldn't seem to me that such a feature would be widely used.

The average user would want all their music contained within their music library, in much the same way they would want all their CDs on the same shelf (or set of shelves). Having it all in the one place just makes it easier to manage and the 'Remove from library' features just seems rather niche.

Is it really necessary to keep a little used feature that doesn't even work properly?

Revision history for this message
Alex Mauer (hawke) wrote :

One situation I can think of: A shared music library (for example, shared between myself and my wife) on a network drive. I want to load the whole thing, but then there are a few albums that I hate but my wife likes (and vice versa). Since they’re not mine and one of us does want them, I don’t want to delete the files…but I just want to remove them from my library.

Revision history for this message
Waldir Pimenta (waldyrious) wrote :

There's also the case when people have non-music files in their music folders. For instance, I have a few text files with some music-related notes, which keep getting re-added and treated as import errors. But perhaps this is a different bug...

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

@Waldir: Yeah, picking up image file sounds like a different issue.

Ok, so it is useful. I was just wondering.

Revision history for this message
wiertel (wiertel) wrote :

Originally I thought it is wrong that RB allows me to remove track but the track is back again after restart. It simply did not seem to be right behavior.

On the other hand what about deleted tracks? Would you allow to undo the removing? Just wondering after reading this discussion.

Changed in hundredpapercuts:
assignee: Chris Wilson (notgary) → nobody
Changed in rhythmbox (Ubuntu):
assignee: Chris Wilson (notgary) → nobody
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

I think a simple solution would be to add a boolean attribute called ExcludeFromLibrary to each track in the xml file. If the parser comes across such an attribute with a true value, then it simply ignores it.

When adding new files to the library, it would be a good idea to run through the list of excluded files to ensure that it has not already been excluded. If it is found in that list, then the attribute is flipped to false. This will stop the library file getting clogged up with duplicate excluded tracks.

Changed in hundredpapercuts:
milestone: precise-4-music-video → quantal-1-audio-video
importance: Medium → Low
Changed in hundredpapercuts:
milestone: quantal-1-audio-video → raring-round-1
Changed in hundredpapercuts:
status: Triaged → Confirmed
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Comment from the developer:

"It would be fairly easy to convert deleted songs into 'ignore'
database entries that will never show up anywhere, rather than
deleting them. Then you need to provide a way to convert them back,
such as explicitly adding them to the library again, and make sure
it's easy enough to figure out how to do it, and make sure it doesn't
happen accidentally."

Revision history for this message
RaduStoica (radumstoica) wrote :

I'll give this a try. For converting back the files, I guess the suggestion a couple of replies above should work - when adding new files go through the database and change back the 'ignore' type.

Changed in hundredpapercuts:
assignee: Papercuts Ninja (papercuts-ninja) → RaduStoica (radumstoica)
Revision history for this message
Colan Schwartz (colan) wrote :

What about using inotify (https://secure.wikimedia.org/wikipedia/en/wiki/Inotify) to get notified when file changes happen?

RaduStoica (radumstoica)
Changed in hundredpapercuts:
status: Confirmed → In Progress
Revision history for this message
RaduStoica (radumstoica) wrote :

I've attached a patch proposal for this to the Rhythmbox bugzilla entry. I've also asked on the mailing list for a review - hopefully someone will look at it.

Revision history for this message
Karim (karim-acamedia) wrote :

I think the problem is (unless that is another problem) that Rhymthbox never ever "forgets" what files were once in the directory! I removed my music from the music folder and started RB: all the music was listed. When I pressed play it cycled through the whole list, eventually marking all as missing - but when I restarted RB, there they all were again! I did a complete removal of RB and reinstalled, with the music STILL removed from the source folder. And yet there it all was again. What intrigues me is what exactly does "completely remove including configuration files" mean??? I searched for "rhythmbox" after re-removing and there were over 50 files. I'm a newbie so I have no idea what they do, but I'm assuming some of them remember what once was in the source directory - for ever - and some remember what the source directory was set as. Perhaps I don't understand what a configuration file is, but I would have assumed that this information would be deleted by selecting "completely remove including configuration files".

Revision history for this message
RaduStoica (radumstoica) wrote :

Karim,

  This is indeed another problem. Regarding avoiding missing entries, you can delete them from inside Rhythmbox (right click->Move To Trash).

  Rhythmbox settings are in ~/.local/share/rhythmbox . So I guess this directory should be deleted when you completely remove the package. If this does not happen, I'm not sure where the problem is - I assume it is a packaging problem.

Changed in hundredpapercuts:
milestone: raring-rhythmbox → papercuts-s-rhythmbox
Changed in rhythmbox:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.