RE: Re: xPLMediaNet and Playlists

["Tony Tofts" <tony@xxxxxxxxxx>]

> My feeling is that playlists should be treated as a media
> type, just like an mpg or an mp3.  After all, you can browse
> and play playlists in the same way as individual files.  The
> fact that they actually point to other media files is
> irrelevant to the way the user interacts with them - handling
> a playlist (from a user perspective) is really no different
> to dealing with the chapters in a DVD movie.

That's an interesting concept, hadn't thought of it that way.

Trouble is they don't have a specific artist/album/genre etc associated
with
them so can't be integrated into the tracks table

I think I'll opt for the playlist module to scan for the files into a
database table, but not store the tracks. The playlist module will be
responsible for extracting the tracks on the fly when they are selected to
be queued

> As such, any module that requires the database - which to my
> mind should just be the media selection modules (browse, web
> interface etc), should use the same method to select a
> playlist as any other file.
> The only other part of the system that needs access to the
> database (if I understand correctly) would be the core, which
> would need to access it to obtain file locations - either to
> send in xPL commands, or for the serving of files to devices
> that require that.

Only "source" modules (and any special function modules like
pronto csf,
voice recognition) need access to the database.

All other access to the data is _thru_ the "source" modules, even
the web
interface etc will go thru the "source"'s to get the data

The only part the core plays is providing a default database connect string
to the modules (this default can be overridden at both the global and/or
module level)

Regards
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