extragear/multimedia/amarok/src

[Jeff Mitchell]

On Monday 11 August 2008, Ian Monroe wrote:
> On Sun, Aug 10, 2008 at 6:24 PM, Jeff Mitchell 
<kde-dev at emailgoeshere.com>wrote:
> > SVN commit 844926 by mitchell:
> >
> > Put uniqueid field in to playlist_tracks for future AFT integration
>
> Do we really need this? I was thinking, using the XSPF 'identifier' field
> means that we can play playlists even if the files move around, without the
> hassle of storing them in a database. Like we pretty much already have the
> functionality we were looking for in playlist files currently.
>
> Ian

Well, that depends.

The way I understood we were going to do playlists in A2 was to store them in 
the database, and write them out to M3U/PLS/XSPF on user request.  This is 
very beneficial because it's not only faster than keeping playlists in 
databases, but it also makes tracking files much easier.

We *could* do playlists by storing them on disc in XSPF files, but this means 
that every time a file updates, we have to read in every single XSPF file, 
check to see if the UID matches any of the tracks, and write it back out.  
This could happen hundreds/thousands of times in a single scan.  Granted we 
could speed it up by keeping lists of changed UIDs in a storage object and 
comparing to that, but it's still much heavier.  That versus a single SQL 
UPDATE statement.

Also: storing playlists in a database is not really a hassle.  There's not 
much to it.  Storing on-disk as XSPF files seems like more of a hassle to me.

So I guess the answer is, is there any benefit to be gained from storing 
playlists as on-disk XSPF files all the time and having to continually read 
them in, update them, and write them out?  It seems to me at this point that 
storing in the database is the clear winner...

--Jeff