Re: [Rhythmbox-devel] Playlist management/syncing

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
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
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) .


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