deleted songs listed again when using library watch

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?

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

"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.

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

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.

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!!!!

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?

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.

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

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?

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?

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.

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?

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.

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...

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

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

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.

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.

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."

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.

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

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.

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".

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.