In 0.9 tracks won't be deleted from the library if the mount (drive, network
share, etc) they are on isn't present - they are just hidden, and should
reappear if you plug the drive back in.

I've been doing some work on supporting removable media, as part of my Audio CD
support (bug 110928), and adding support for things like mp3 (or ogg, etc.)
CDs/DVDs should be fairly easy once I've finished that. One issue is that I'm
not aware of any to tell the difference between an "mp3 CD" and any other data
CD - which means that Rhythmbox will have to do a complete scan of any inserted
CDs and will show them up in the source list.

There are now two ways you can do this in Rhythmbox from cvs:

1) As mentioned above, import tracks from the media into your library. When removed, the tracks will be hidden. As long as it is mounted on the same mountpoint, Rhythmbox will automatically unhide the tracks when it is mounted again. The tracks will show up in your main library

2) Use the "generic audio player" support, which can be used with anything that is accessable via gnome-vfs. If your media isn't an audio player (as determined by HAL), you can get Rhythmbox to treat it as one by putting a file called ".is_audio_player" in the top level of the media. The tracks will be added to a per-media source.

The downside is that tracks will need to be scanned every time it is mounted. I've filed bug 328526 about a possible solution.


Do these two possibilities satisfy what you want?

I've made some tests in Rhythmbox 0.9.2, with a DVD with mp3 files. Regarding the first way I see two issues:

- During a Rhythmbox session, detection of the media seems to be based on the mount point only: after importing a folder in RB, I eject the media, and the songs are automatically removed from the RB list (nice !). Now if I insert another CD in the drive, the songs reappear although it's not the right media, so trying to play them display the "forbideen" icon. Ejecting the CD (songs disappear) and inserting the DVD, I can now play the songs.

- Doing the following leads to the songs being removed permanently from RB's list:
1) import a folder from the DVD
2) close RB
3) eject the DVD, insert some CD
4) start RB: songs from the DVD are not displayed
5) close RB
6) eject CD, insert DVD
7) start RB: DVD songs don't appear in the list

Wouldn't it be possible to get from HAL a unique identifier for each CD/DVD and use it to detect the presence of the media?


Regarding the second way: I cannot test it but it seems a bit inconvenient that one needs to add a file to the media (beside ease-of-use considerations, this cannot be changed once a CD is burned). Nonetheless it seems to be a very nice solution. Would it be possible to have an option where the user can tell RB "consider this disc as an audio player"? BTW there's an entry "Scan Removable Media" in the File menu, but it seems it doesn't scan anything here...


Those problems aside, I think it's an about perfect way to handle the user case I described: as I understand it, the user could use 1) if he wants the songs to appear in the main list, and 2) if she wants separate sources. Very nice!

(In reply to comment #3)
> I've made some tests in Rhythmbox 0.9.2, with a DVD with mp3 files. Regarding
> the first way I see two issues:

Some of these issues have been fixed/made better with Rhythmbox from cvs, but some haven't.


> - During a Rhythmbox session, detection of the media seems to be based on the
> mount point only: after importing a folder in RB, I eject the media, and the
> songs are automatically removed from the RB list (nice !). Now if I insert
> another CD in the drive, the songs reappear although it's not the right media,
> so trying to play them display the "forbideen" icon. Ejecting the CD (songs
> disappear) and inserting the DVD, I can now play the songs.

Yes, it is based on mount-point, not any kind of identifier. CVS is a bit better in this respect, because it won't display the songs unless they are actually there (so they won't be visible if you insert a different CD).


> - Doing the following leads to the songs being removed permanently from RB's
> list:
> 1) import a folder from the DVD
> 2) close RB
> 3) eject the DVD, insert some CD
> 4) start RB: songs from the DVD are not displayed
> 5) close RB
> 6) eject CD, insert DVD
> 7) start RB: DVD songs don't appear in the list

That should also be fixed with CVS, since Rhythmbox won't remove tracks from the database unless they have been "missing" for over 45 days.


> Wouldn't it be possible to get from HAL a unique identifier for each CD/DVD and
> use it to detect the presence of the media?

This is still one things that doesn't work so well - Rhythmbox won't recognise the same media on a different mount-point (e.g. if it's put in a different drive).


> Regarding the second way: I cannot test it but it seems a bit inconvenient that
> one needs to add a file to the media (beside ease-of-use considerations, this
> cannot be changed once a CD is burned). Nonetheless it seems to be a very nice
> solution. Would it be possible to have an option where the user can tell RB
> "consider this disc as an audio player"?

It wasn't really meant for cds/dvds, but as a workaround for when HAL doesn't detect the player (or you don't have HAL).

If RB is compiled with HAL support, then a "treat as removable media" option shouldn't be too hard - mostly storing a list of UDIs somewhere (probably gconf). I guess the UI would be a dialog that displayed a list of mounted volumes with checkboxes or something.


> BTW there's an entry "Scan Removable
> Media" in the File menu, but it seems it doesn't scan anything here...

That could probably be worded better. What it does is re-run the full scan for removable media that RB doesn on startup - it's useful for non-HAL systems that don't automagically detect removable media at runtime.

(In reply to comment #2)
> 2) Use the "generic audio player" support, which can be used with anything that
> is accessable via gnome-vfs. If your media isn't an audio player (as determined
> by HAL), you can get Rhythmbox to treat it as one by putting a file called
> ".is_audio_player" in the top level of the media. The tracks will be added to a
> per-media source.

Hi all,
I'd like RB to treat my incoming folder (~/downloads) as a "generic audio player". I tried the ".is_audio_player" thing with my usb-stick, it creates a new source with all the tracks in it so I don't have to add anything to the library, that's exactly what I want - But I don't know how to get this work with a simple folder. Is there a way to do this?

The ".is_audio_player" workaround only works for the top-level of a volume - so it would only work if ~/downloads is a partition.

Rhythmbox currently support watching multiple library locations, if you use gconf-editor to set the key /apps/rhythmbox/library_locations. There isn't any UI for this yet, but it's under discussion. Making the multiple library locations show up as multiple sources is bug 100552.

I have a slight variation on this thought that'd make it more appealing to me as an end user, and would be a good compromise to dealing with bug 100552, at least in part.

I apologize ahead of time if this overly written up "use case" description is too wordy for a comment on an existing bug, but I wrote it up before checking Bugzilla, and I'd hate to see it go to waste.

Rhythmbox Removable Volume

Current use case:
Tommy has a laptop computer with limited storage. Tommy uses Rhythmbox to browse the collection he has present on his USB hard drive. However, he also uses Rhythmbox to listen to music from iTunes (DAAP) shares, Jamendo, Magnatune, and other network streams while his USB hard disk is disconnected. When Tommy starts Rhythmbox without his USB hard disk attached, Rhythmbox proceeds to check that all his files are present, and adds many many import errors to his list, using excessive amounts of CPU time, and generally making Tommy feel like he has "lost something."

Preferred case:

Tommy starts Rhythmbox without his USB hard disk attached. Instead of removing files from his collection window, they are greyed out or otherwise indicated as "not present." If Tommy selects one of the songs that resides on his USB hard disk, he is prompted to connect the drive.

Implementation details:

At import time, check to see what mountpoint a file resides on and store that as part of the database; On startup when attempting to check the file, first check that the mountpoint it should be on is mounted. If it is not, mark the file as "unavailable," but don't register it as an import error.

Rationale:

Import errors should be reserved for corrupted files, files for which codecs are missing, and files which have been deleted from the volume on which they reside.

That's pretty much exactly what we currently do.  Perhaps you're confusing the 'missing files' source with the 'import errors' source?  They're completely separate and different things.

You're right, my apologies. Though honestly, making that distinction doesn't really address my concern.

I feel that bumping files that are most likely temporarily missing into the "missing files" source is alarming to the user, and that in the use case presented makes the user feel as though it needs immediate attention. It's far too active feeling a behavior for something that is initiated at application start. (I understand that logically it is identical to my presented solution, but interface-wise I think the difference is rather large.)

I think it's a bad idea to have unavailable tracks visible in the main library in any fashion.  You can't do anything with them (except remove them), so all they can do is get in your way.

Perhaps it would be useful to distinguish between genuinely-missing (the filesystem is mounted and the file just isn't there) and unavailable (filesystem not mounted).  This would require actual effort.  The current implementation of the 'missing files' source is more or less an unintended consequence of the way missing files are handled.

I think the current approach is fine for genuinely-missing files, but not so good for unavailable files.  Perhaps a child source under the missing files source for each unmounted file system, labelled with the volume name?

Perhaps a "Hide unavailable tracks from library" option?
This is mostly a matter of personal opinion... I don't particularly like noisy UI, and I guess with either approach you get UI "noise." It just is a matter of where you prefer it. I personally think that adding one child source for each volume would contribute even further to UI noise. 

I could also think of (admittedly, rather contrived) use cases wherein having access to your whole library would be useful; for instance, if your collection were scattered over a series of removable disks, and you'd like it to tell you which volume you should attach to gain access to song X. But, such a case is so fringe I wouldn't compromise the usability to the average user for it.

Your use case in comment 12 is something that would be good to at least consider in any approach at implementing this.

By 'child source' I mean that these would be nested under the main 'missing files' source, so they probably wouldn't be visible by default, and would easily be hidden.

I really don't want to add a UI preference for this.  Unless there are two different important use cases, each of which is only supported by one of the alternatives (missing files visible in library vs. separate missing files source), we should pick one and implement it.

Hopefully, I'm not missing something here, but does Rhythmbox currently have the ability to add music to the library without actually transferring the music to the local hard drive?

The initial comments in this thread seem to indicate that that it does (or at least did) :S  Is that correct?

As I see it, it doesn't currently have this ability .  I would really like to be able to add music with different sources to the library.  For example, from iPod, USB drive, shares, local hard drive, different partitions, etc...

Hi,
  The case where the whole library is missing is for me starting to be slightly annoying.  I've moved my whole library onto a USB stick and it tends not to get mounted in the login sequence before rhythmbox is started; hence rhythmbox then goes through and removes everything (this takes a while).

  I mount the drive and then restart rhythmbox and it spends a few minutes readding them.

  Sometimes it would be just better for rhythmbox to realise it's whole library is missing and it would be best to tell you that rather than automatically removing them all.

Dave

It used to be working a long time ago... Support for that was introduced in commit 3bcdefe0ac5d1322614722f06249d7da55489524 if someone wants to try to understand why it's no longer working.

A bug about this issue has been opened on the Ubuntu bug tracker:
https://bugs.launchpad.net/rhythmbox/+bug/398734

The view there generally echos Dave Gilberts comments in Comment 15.

It is initially quite alarming to find your library disappearing into Missing Files, the first time you open Rhythmbox without having the library source mounted.  On subsequent occasions it is annoying.

Pretty old bug in which I incurred when I bought a new big USB HD.

Maybe the library source could be enriched with a "removable" (boolean) property (to store in dconf along with the source path). Then:

- if the source path is available go ahead

- if the source path is unavailable and the source has removable==false then mark (and show) the tracks in it as "Missing files"

- if the source path is unavailable and the source has removable==true then do *not* mark (and show) the tracks in it as "Missing files", but only hide them

- while scanning the rythmdb, if a track path differs from one of configured library paths, then remove it from the db (this to deal with "removable" source which really does not exist anymore). Maybe the automatic removal mechanism (with the grace time) can be considered enough, but this way, though, the files would not be listed in "Missing files" for 'gracetime' days.

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