From: Daniel Stenberg <daniel_at_haxx.se>
Date: Sun, 16 Mar 2003 13:15:34 +0100 (CET)

On Sun, 16 Mar 2003, Matthew P. OReilly wrote:

> Perhaps I missed this before, non-coder that I am <grin>, but is there a
> technical reason why it would be difficult/impossible to have recursive
> playlists? AFAICT, we have (or are working on) all the necessary
> functionality to do this sort of thing - .cfg files loaded with playlists
> (to switch between shuffle and non-shuffle mode), playlists loading other
> playlists (am I correct in that assumption?), etc. All I can see we need
> is the ability to store the information about the parent playlist somehow,
> which could be something of a logistical nightmare (unless you set the
> maximum nesting to 3 levels or something) but not terribly difficult.
>
> Am I missing something here? What portions of this are not possible
> currently?

This is all terribly technical, but allow me to attempt to explain why this
is tricky:

Today, when a playlist is loaded into memory, it is just scanned through and
we store the index of the file name in the actual file on disk. Thus, a 1000
song playlist becomes 1000 indexes in memory. When a song is to be played
from the list, we know the original playlist file and we seek our way (to the
index we know) to figure out the name of the song to play.

In come recursive playlists. They don't fit this scheme at all. Let's assume
that one of the songs in the playlist is a playlist (a sublist), then we must
scan that playlist instead and make indexes for that and somehow store and
remember internally that these index entries are for a different playlist.

One way we could approach this:

Assuming that a file path name is 256 bytes maximum, we can safely assume
that no playlist (thus seek index) is ever bigger than 2560000 for a
10000-entry playlist. And to play it safe for 8MB-modders, let's assume we
want to support 40000 entries, no seek index is ever bigger than 10240000. To
hold such a number 24 bits is enough.

This gives us 8 free bits on every array entry that will never be used for
seek-info, but can instead be used for playlist info. Given that these won't
be needed for anything else, we could use these as a 'playlist identifier'
and for each new 'recursive' playlist, we store the name of that playlist in
an array (which then would require a whopping 64K if 256 entries could each
have their own unique 256-bytes file path).

Let's say we can spare 4K for the recursive playlist path info, then we'd
support at least 16 playlists. And that would only use 4 bits in the array.

Of course, loading of a playlist like this will be slower, and the sub-lists
will be loaded and examined at the time of the master list load.

A few benefits of this approach:

* The resume algorithm would still work perfectly
* BACK and FORWARD would still work as today

A few drawbacks:

* Having a directory name in the playlist and use that as a sub-list will
  not be easily done.
* The limit of 16 sub-lists will be odd and hard for people to understand
  and deal with.
* Makes the playlistg code more complicated, when this "inline" stuff perhaps
  just as well could be made by an external program that generates one single
  playlist instead...

I've probably forgot lots of tiny details.

-- 
 Daniel Stenberg -- http://rockbox.haxx.se/ -- http://daniel.haxx.se/

Received on 2003-03-16