This should be an option that you can uncheck (preferably as a context menu checkbox for certain sources (e.g. Music, Video, ... libraries)

I'm saying this because I have my music files on an external hard drive I sometimes take with me. When I come back and forgot about the fact my files are not there I would not like to see my database cleared of all entries.

my 2 cents!

I would like to see this feature too.

One way that could solve all problems is tell banshee when we want to remove non-existent media from the library. This way people could do this only when they got access to all files so no "good" files are deleted, ie. you only ask banshee to remove the missing files from the library when you are connected to the external harddrive, this way the problem would be solved.

As Mathijs says, I'm also worried about too much automation that may screw up the user's database.

That said, we could maybe come up with a solution that pleases all point of views more or less. Some ideas that come to my mind:

- Not remove tracks from the DB but mark them as deleted in the DB, to be able to recover them just in case (another discussion is how would be the UI or the usecase to recover them).

- Mark non-existent files with a different font colour (for example, grey, as like grayed). Then somehow have a way to show/hide/show-only/sort tracks that are unavailable (let's call them this way, to cover also the fact that they may be in an disconnected external drive), so the user can select all of them and remove them all in one go.

Is there a way to figure out which path leads to a removable device programmatically?

If it is, Banshee could just treat the files on the hard drive differently:
- For the files on the fixed drives, it could remove them automatically from the database
- and for the files on the removable devices, it could just:
  - mark the files as unavailable when the device isn't connected
  - and delete them from the database when the device is actually connected
    and they don't exist there any more.

Furthermore, if an automatic distinction between fixed and removable drives wasn't possible, the user could also be able to define which paths he considers to lead to the removable ones (e. g., D:, E: and H: on Windows and /media/cdrom, "/media/USB DISK" or /mnt/nfsshare on Linux).

(In reply to comment #4)
> Is there a way to figure out which path leads to a removable device
> programmatically?
> 
> If it is, Banshee could just treat the files on the hard drive differently:
> - For the files on the fixed drives, it could remove them automatically from
> the database
> - and for the files on the removable devices, it could just:
>   - mark the files as unavailable when the device isn't connected
>   - and delete them from the database when the device is actually connected
>     and they don't exist there any more.
> 
> Furthermore, if an automatic distinction between fixed and removable drives
> wasn't possible, the user could also be able to define which paths he considers
> to lead to the removable ones (e. g., D:, E: and H: on Windows and
> /media/cdrom, "/media/USB DISK" or /mnt/nfsshare on Linux).

I really like this particular suggestion. Furthermore, this feature is a very important one to me in a media player since I've always got my music scattered on several external drives.

I have searched in vain for a music player that does this on Linux, and have settled on Banshee for all of its other awesome features. With that feature added, I'll be very happy indeed.

(In reply to comment #5)
> (In reply to comment #4)
> > Is there a way to figure out which path leads to a removable device
> > programmatically?
> > 
> > If it is, Banshee could just treat the files on the hard drive differently:
> > - For the files on the fixed drives, it could remove them automatically from
> > the database
> > - and for the files on the removable devices, it could just:
> >   - mark the files as unavailable when the device isn't connected
> >   - and delete them from the database when the device is actually connected
> >     and they don't exist there any more.
> > 
> > Furthermore, if an automatic distinction between fixed and removable drives
> > wasn't possible, the user could also be able to define which paths he considers
> > to lead to the removable ones (e. g., D:, E: and H: on Windows and
> > /media/cdrom, "/media/USB DISK" or /mnt/nfsshare on Linux).
> 
> I really like this particular suggestion. Furthermore, this feature is a very
> important one to me in a media player since I've always got my music scattered
> on several external drives.
> 
> I have searched in vain for a music player that does this on Linux, and have
> settled on Banshee for all of its other awesome features. With that feature
> added, I'll be very happy indeed.

+1

(In reply to comment #4)
> Is there a way to figure out which path leads to a removable device
> programmatically?

There should be a way to know this programmatically, yes, but I haven't looked into it.

If you find it though, it would be nice to test how that method behaves with the following use-case:

- Have some music in /mnt/SomeRemovableDrive/MyMusic
- Have a symlink dir called "MusicInUSB" to the path above in /home/user/Music

Would that method mark MusicInUSB folder as removable or not? If not, it's still to risky. If yes, I think you found the right thing to use to develop this feature.

s/to risky/too risky/

IMHO, trying to determine whether a file location is "removable" would be very complex. Symbolic links, bind mounts and e.g. swappable hard drive bays make the distinction nearly impossible to get right in all cases, which may also depend on a user's preferences.

Letting the user choose the policy for different locations (a.k.a. "drives" as Pavel called them) would also implicate the concept of a "drive" or "volume" the user can recognize, which under a UNIX file system is not easy.

I personally liked the "Missing Files" list in Rhythmbox. It's like a smart playlist that shows the file location by default and gets updated whenever RB rescans the library. Sorting by the location (which shows a complete URI) makes it easy to then manually remove all songs in blocks when recognizing a directory I deleted or moved. To take this concept to a higher level, the user interface could even show the missing files in a folder hierarchy like in a file manager, so one can remove whole folders of missing / unavailable files.

If this happened automatically, I would always be in fear of losing some entries in my playlists just because some directory is currently not present. Even after re-adding them to the library, the playlists would not recover automatically. Audacious for example has an option "Remove unavailable items" in the playlist window. This seems much safer to me and could still be supplemented by automatic _marking_ of unavailable files.

The "missing" mark could also be propagated to all playlists where at least one entry is unavailable. Either way, I would appreciate a warning dialog before removing unavailable library items that are still part of some playlist. They might just have moved to a different directory.

(In reply to comment #9)
> IMHO, trying to determine whether a file location is "removable" would be very
> complex. Symbolic links, bind mounts and e.g. swappable hard drive bays make
> the distinction nearly impossible to get right in all cases, which may also
> depend on a user's preferences.
> 
> Letting the user choose the policy for different locations (a.k.a. "drives" as
> Pavel called them) would also implicate the concept of a "drive" or "volume"
> the user can recognize, which under a UNIX file system is not easy.

I totally agree that detecting removable drives could become quite unruly. Would it not work well, however, to just have a "removable" policy for all sources? By a source, I mean a root directory of a music folder like ~/Music. You could easily monitor the presence of each source and hide the files that belong to it when it is not present. I would not propose to hide the entries in playlists, only the entries in the main library. Then when you plug in a drive that contains a missing source, the entries would be immediately available.

> I personally liked the "Missing Files" list in Rhythmbox. It's like a smart
> playlist that shows the file location by default and gets updated whenever RB
> rescans the library. Sorting by the location (which shows a complete URI) makes
> it easy to then manually remove all songs in blocks when recognizing a
> directory I deleted or moved. To take this concept to a higher level, the user
> interface could even show the missing files in a folder hierarchy like in a
> file manager, so one can remove whole folders of missing / unavailable files.
> 
> If this happened automatically, I would always be in fear of losing some
> entries in my playlists just because some directory is currently not present.
> Even after re-adding them to the library, the playlists would not recover
> automatically. Audacious for example has an option "Remove unavailable items"
> in the playlist window. This seems much safer to me and could still be
> supplemented by automatic _marking_ of unavailable files.
> 
> The "missing" mark could also be propagated to all playlists where at least one
> entry is unavailable. Either way, I would appreciate a warning dialog before
> removing unavailable library items that are still part of some playlist. They
> might just have moved to a different directory.

Yes, this missing files list you describe would be a great way to handle the removal of files that are no longer relevant. That would go well with my removable sources suggestion as well, because you would want to have some way to ditch the sources that no longer exist. That could also be done from the dialog where you select the sources to begin with.

One other thought that arrises as I contemplate this is that you may want to have the option to change the location of a source while persisting the associated metadata. That's a slightly different topic, and I don't know if it currently happens or not. But it would be easy enough to allow the change of location for a source from the sources dialog, and to persist the metadata when that is done.

(In reply to comment #10)
> (In reply to comment #9)
> > IMHO, trying to determine whether a file location is "removable" would be very
> > complex. Symbolic links, bind mounts and e.g. swappable hard drive bays make
> > the distinction nearly impossible to get right in all cases, which may also
> > depend on a user's preferences.
> > 
> > Letting the user choose the policy for different locations (a.k.a. "drives" as
> > Pavel called them) would also implicate the concept of a "drive" or "volume"
> > the user can recognize, which under a UNIX file system is not easy.
> 
> I totally agree that detecting removable drives could become quite unruly.

I don't think it could be so difficult.

Let's say you have an API that can tell you if certain filesystem entry is a symbolic link or not: SafeUri GetSymbolicLinkRoot(SafeUri uri) . (If it's not, it would return null.)

Let's say you have an API that can tell you if certain mount point is a removable drive: bool IsPathAMountPointForARemovableDrive(SafeUri mountPoint).

Now, when importing this file:

file:///some/custom/location/file.mp3

We would have just to do something like this:

bool BelongsToRemovableDrive(string path){
  var root = GetSymbolicLinkRoot (path); //first iteration: path=file:///some/custom/location/file.mp3
  if (root != null) {
    return BelongsToRemovableDrive(root);
  } else {
    string path_to_check = path;
    if (!IsDirectory(path)) {
      path_to_check = GetFolderPathOfFile(path_to_file);
      //first iteration: path_to_check=file:///some/custom/location/
    }

    string next_path = StripOneFolderLevel(path_to_check);
    //first iteration: next_path=file:///some/custom/

    if (next_path == "/") {
      return IsPathAMountPointForARemovableDrive(path_to_check);
    } else {
      return IsPathAMountPointForARemovableDrive(path_to_check) || 
             BelongsToRemovableDrive(next_path);
    }
  }
}

Then the only thing to figure out is the FileSystem API to call inside IsPathAMountPointForARemovableDrive() and GetSymbolicLinkRoot().

> One other thought that arrises as I contemplate this is that you may want to
> have the option to change the location of a source while persisting the
> associated metadata. That's a slightly different topic, and I don't know if it
> currently happens or not. But it would be easy enough to allow the change of
> location for a source from the sources dialog, and to persist the metadata when
> that is done.

Since banshee version >= 2.1.0, you can move all your tracks to a different place, re-import them (rescan library) and the metadata will remain (no new tracks will be imported, the tracks in the DB will just change their path records), thanks to bug 638889 being fixed.

If you're looking for a more general solution to prevent you to scan metadata, you can wait for the fix (or help fixing) for bug 594751.

(In reply to comment #11)
> If you're looking for a more general solution to prevent you to scan metadata,
> you can wait for the fix (or help fixing) for bug 594751.

I meant "to prevent you to *re*scan your music library", not to "scan metadata".

I would like to have this feature too.

However, I think doing this automagically while importing files is far too complicated a solution for the functionality it provides.

I would propose a simple 'remove missing media from library' menu entry under the 'tools' menu, which already has other entries such as 'fix music metadata' and 'rescan music library'. Upon clicking banshee should check every track and remove it from the library if it does not exist. Another possibility would be to show the user a list of missing files and let him/her decide which files to delete from the library himself.

OK, I think we’ve discussed this topic enough to make a final decision.

I’d suggest to start with that what Quentin writes about.

1. Tools -> Remove missing media from library
2. Show list of missing media to let the user choose

Plus, as an additional feature, take a list of mountable drives or, more precisely, file systems, and let the user choose which source locations he considers good for missing files removal:

3. Path tree view with checkboxes, drive combobox or something like this to filter the missing files by path.

Go into it and implement it :-)

Pavel

Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.