Re: [Rhythmbox-devel] Playlist management/syncing

[Petko Ditchev <pditchev gmail com>]

On 11/18/2013 01:10 PM, Jonathan Matthew wrote:
> On Sun, Nov 17, 2013 at 3:49 AM, Petko Ditchev <pditchev gmail com> wrote:
> >   Rhythmbox as well as most other music players/libraries has its own made-up
> > playlist storage format . That means No portability , and no simple
> > synchronization solutions .That's why I'm trying to use JuK right now - it's
> > the only linux music player that keeps the playlists on the disk (but it's
> > kind of unmaintained, so prospects there are limited).
> >   So I have a proposal and I'm willing to start coding for it , but I have to
> > know the idea is accepted first . So far my impression is that GNOME devs
> > have no interest in 'people', at least on the mailing lists .
> Hi, nice to meet you too.
I'm sorry for the rough intro . I've posted on the GNOME lists with 
variable success in invoking any kind of discussion , so I was kind of 
prejudice (+there have been other FOSS projects that I wanted to improve 
on , but hit a barrier . It's kind of frustrating to try to help ,and 
not be given a chance) .
> >   So a side question is - where do development discussions actually happen ?
> Here, on irc, or in bugzilla.
>
> > With that
> > thought in mind please take a position on the topic . Here's the idea :
> >
> > Playlists would get picked up automatically from the music library (indexed
> > as entries in the db) . On startup they get loaded in the playlists pane ,
> > and on modifications they get instantly saved . Automated playlists are not
> > affected by that arrangement (they can remain in the xml they are in now).
> >
> > Pros to the current situation:
> > + easy synchronization between computers using any sync solution
> > + persistence of playlists on full wipe/reinstall of rhythmbox
> You can achieve both of these pretty easily as things stand,
I guess it's possible , but not too easy/convenient . One major problem 
with synchronization is time-stamping - I think I tested it out , but 
I'm not entirely sure , that the playlists.xml doesn't change only when 
a playlist is changed , but on startup or close or something like that , 
too.
 +If there are changes on both machines on different files they can be 
easily merged . It's not a common case but still.
>   but this
> is still an interesting idea. Instead of adding them to the database,
> I'd rather have the playlists.xml file refer to the external playlist
> files.
When suggesting the database I was going mostly by the logic that there 
is probably code there that can be reused :
>For watching the file for changes on runtime (I know at least that 
deleting a song removes it instantly)
>For rescanning on startup (or whenever the rescan is done, it works 
well , so I haven't thought about it)
>To avoid changing the playlist.xml format
> Are you proposing that this would be how all non-automatic playlists
> would be stored? How would you decide where a given playlist file
> goes?
The ones found in the library stay where they are . The tricky part - 
the new ones - we either ask the user where to store them on the making 
, or use the same folder as for the playlists.xml , or use 
/home/user/Music/playlists . I prefer the first , the second is more 
seamless (sorry if I'm butchering the English language right now) , I 
like the third , but it might be too invasive (+it would require adding 
a setting to change the place , in my opinion , which is an additional 
complication) .

Petko