Re: [Rhythmbox-devel] Handling non persistent tracks was:Keywords (aka categories or tags) in Rhythmbox

[James Livingston <doclivingston gmail com>]

On Fri, 2007-03-02 at 10:43 +0100, Christophe Dehais wrote:
> This questions me about the link between the database and the songs
> that are "recreated each time".
> 
> Is it correct to say that the "database" structure built at runtime by
> RB contains tracks that are not saved back in the playlists.xml and
> rhythmdb.xml files ?

Yes, it's up to each "entry type" to specify whether it should be saved
into the on-disk database.

Things like tracks on removable media and DAAP shares aren't saved
because we should reflect what is actually there each time we start up
(or the device/share is found), rather than what was there last time we
saw it.


> And then: is the problem of handling all fonctionnalities (adding to
> playlist, tags) for any tracks (including daap-served and portable
> player ones) boiling down to finding a way to store those tracks in
> those files ?

One thing I've been thinking about is that for "generic" portable
players which don't have a database on them, we should save our database
info as a cache (e.g. ~/.gnome2/rhythmbox/devices/$HAL_ID.xml). That way
we would do the same thing we do with Library tracks, and not have to
scan all the tags again when you plugin the device in - only see whether
tracks have been removed, added or modified.

However the big question for things like this is whether to store things
like tags and playcounts on the device itself (so it works if you plug
it into a different machine) or not.


DAAP is a bit different, because identifying shares and tracks is much
harder. As far as I know all we can use to identify DAAP shares would be
the name or ip address. DAAP servers can give us a "permanent track id"
which is persistent across changes/restarts, but many severs (including
Rhythmbox) don't send this.


> Having all my songs on a daap share and an ipod is a quite strong
> incentive for me to actually try and fix this issue if possible.

For things like that, storing play counts, rating and tags locally would
be nice.


Cheers,

James "Doc" Livingston
-- 
Imagine if every Thursday your shoes exploded if you tied them the usual
way. This happens to us all the time with computers, and nobody thinks
of complaining. -- Jeff Raskin