Re: [Rhythmbox-devel] [RFC] Multiple library locations

[Christian Becke <christianbecke web de>]

Jonathan Matthew schrieb:
> On Wed, Mar 25, 2009 at 07:01:36PM +0100, Christian Becke wrote:
>> * If you have configured multiple library locations, and you choose to
>> remove one of them, what should happen to the songs from the removed
>> location? Should they be removed from the library or should they be
>> kept? If they are removed, what about the metadata (play counts,
>> ratings, etc.)?
> 
> If you remove the songs from the library, play counts and ratings and
> everything else are also removed.  There's no way to separate them.
> 
> I think there are use cases either way.  Imagine you permanently lose
> access to a network share you were playing music from - there's no point
> keeping the database entries, as you'll never see the files again.  On
> the other side, maybe you just don't want a particular location to show
> up as a source any more, but you still want to keep the files in your
> library.
> 
> So, I guess the solution is to ask the user when removing a library
> location.  I'd want confirmation for an action like that anyway, since
> it could result in loss of a lot of user data with no means of recovery.

The patch I attached to bugzilla asks the user if songs and metadata
should be kept.

>> Currently, if you remove a song from the library (by right-clicking a
>> song and selecting "Remove"), the removal time is recorded in RhythmDB
>> and metadata is kept for a certain time (configurable via the gconf key
>> "/apps/rhythmbox/grace_period"). So if you add the song again to your
>> library during grace_time, metadata will still be there. Should this
>> apply to songs from a removed library location as well?
> 
> That's not how it works.  If you remove a song from the library that
> way, the metadata is deleted too.  The grace period only applies if the
> file goes missing.  The track is moved to the 'missing files' source,
> where it remains for the length of the grace period.  If, on startup, it
> hasn't been seen for that long, the entry is removed and all metadata is
> deleted.

Of course you are right. I remembered it wrongly, should have checked
the code. :)

>> * If you rip a CD using rb, where should the files be saved? Currently,
>> they are put in the first library location. Should there be some ui to
>> choose where to put them?
> 
> There should be a way to select which location is used, yes.  I think
> library monitoring should be a per-location setting too.  This would
> require some more substantial changes, including changes to the way the
> information is stored in gconf, but I think it's worthwhile.

The new patch allows both selecting a "default location" and library
monitoring per location.

In addition to the "library_locations" uri list, I added a
"monitor_library_locations" uri list and a "default_library_location"
string to gconf.
RBLibrarySource tracks changes to those keys and makes sure that
"monitor_library_locations" and "default_library_location" are subsets
of the "library_locations", and that there is always a
"default_library_location" as long as "library_locations" is not empty.
Rhythmdb monitors all locations from the "monitor_library_locations" list.
Does that make sense?

>> * Should there be drag and drop support, allowing to move files between
>> different library sources within rb?
> 
> I'm not sure about this one.  Drag and drop between sources usually
> copies (device to library, library to playlist, library to device),
> rather than moving.  Maybe a 'move to other location' menu, similar to
> the 'add to playlist' menu would be a better way to do this.

Yes, sounds like a better approach for this. I'll look into it.

>> Please try the patch from [1] and the attached python demo of the new
>> preferences dialog I have in mind, and tell me your thoughts.
> 
> Looks OK, except 'put new files here' is a bit awkward.  I'm not sure
> how to say it, though.  

When I did the demo, nothing better came to my mind. I used "default
location", now. That doesn't necessarily make it any clearer, though...