Re: How should xplmedianet hold it's music queue

["Malcolm Lansell" <mlansell@xxxxxxxxxxxxxx>]

Is this really something to worry about?

Even an extreme case of 30,000 tracks at 256 characters per filename is
only
7.5Mb - well within the capabilities a PC.  How many people are really
going
to queue up anything like that amount of files (or use filenames that long)

I'd go for A, and not worry about the memory usage (which will be much less
anyway because of the database items using IDs)

Mal


----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Friday, March 11, 2005 11:32 AM
Subject: [ukha_xpl] How should xplmedianet hold it's music queue


>
> Hi all,
>
> The current xplrionet holds queued tracks by their database track id
(so
> each track is an integer number, in an array of numbers making up the
> queue)
>
> This will no longer work with xplmedianet as we need to be able to
queue
> tracks via xpl and browse (i.e. full path/filename)
>
> This means having to use a string array which will use a _lot_ (and I
mean
> a
> __lot__) more resources than integers
>
> This especially is an issue for users like Andy who like to queue
30000+
> tracks at a time ;-)
>
> I see a few options (and still save some memory space)
>
> A) have a string array containing the full path/filename, but for
items
> from
> the database hold just the id (e.g. "DB:12345"). The
advantage of this is
> that only the xpl/browse items have to be held as a full string,
saving
> space and meaning that artist/album etc details can be obtained from
the
> database still for other items (rather than reading tags/format on the
fly
> when a track is to be queued next or playing)
>
> B) Leave the main queue as a number array, but use negative numbers to
> point
> to a separate string array of just those tracks queued from
browse/xpl.
> E.g.
> -1 = 1st track in string array
>
> C) Have the clients use a database table to hold the track queue
>
> 'A' is more efficient than holding all tracks as strings, but is still
> very
> memory inefficient compared to xplrionet
>
> 'B' is very efficient, and means queue can still be manipulated
quickly in
> memory
>
> 'C' is the slowest, but is totally memory efficient as it won't use
any.
> There's also the option of preloading the table with all the
information
> like artist/album/track/genre etc
>
> Any thoughts/comments please?
>
> Thanks
> Tony
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
> http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>
>



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx