Re: [Rhythmbox-devel] Support for flash based mp3 players

On Tue, 2005-04-26 at 18:32 +1000, Nicholas Gill (mythagel) wrote:
> What i am considering is in particular the devices that are not like an
> ipod. That is, flash based mp3 players without a db. This class of
> players dump files in a folder which the device reads on startup. I had
> originally thought of assigning an existing playlist to the device (the
> user would select it when the device is attached) however i think it
> would be clearer to have that association between the device plugged
> into the computer and the playlist with its name.
> Actually, now i realise something else i wanted to discuss, how should i
> handle files that are new on the device? I had considered creating a
> folder like ~/Music and dumping the files there and then adding to the
> playlist.

I've just had an idea, one that would go a fair way to solving these
design problems: multiple RhythmDBs. First off let me start by saying
that I'm not sure whether RB's design has had there being only one DB as
an assumption or not, so this might be A Lot of Work(tm).

You would have the library/standard playlists working as normal, dealing
with music that is on your computer (using the normal tree/gda DB).

When you plug an mp3 player in it would show the expected new source,
but instead of possibly adding the songs to the normal library (or not)
it would use its own RhythmDB (a mp3player backend). If it was a player
that supported playlists (e.g. an iPod) it could show the playlists
backed by the player's RhythmDB.

If you dragged songs between sources that use the same RhythmDB (e.g.
the iPod playlists above) it would work like normal. If you dragged
songs to a source that was using a different RhythmDB it would copy the
song. For most things this would make sense (i.e. copy to the mp3
player), if you dragged one to the "on my computer" library it would
have to ask you where to save it (or something).

This design would be nice, in that it would then be easier to deal with
things like audio CDs, music shares (e.g. DAAP) and the like as they
could have their own db backend (presumably read-only).

I'm not sure whether this would be a good idea, or if it is feasible,
but to me it seems like an "elegant" solution to the problem.


James "Doc" Livingston 
I love ASR, you have total freedom of speech as long as it's punctuated
correctly. -- Chris Hacking in a.s.r

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]