Re: Some thoughts on xplmedianet and how to implement

["Malcolm Lansell" <mlansell@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Tony Tofts" <tony@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Wednesday, March 09, 2005 5:36 PM
Subject: [ukha_xpl] Some thoughts on xplmedianet and how to implement


>
> Hi all,
>
> If anyone has any comments/suggestions regarding the following, please
let
> me know.
>
> There has to be some way for sources and clients to be tied together
(as
> new
> sources/devices can be added by anyone)
>
> My thoughts are:
>
> A) There will be 3 media types M(usic), V(ideos) and P(ictures). A
source
> can only supply one of these media types (so there will be 3 scanners
for
> disk basd media - seems odd, but they can share a database and it
makes
> sources consistent)
>

Makes sense.

> B) A source will declare which media type it supplies, a friendly name
for
> the source (e.g. music, shoutcast), and then what options it supports
(for
> music this might be artist, album, track, genre, browse, query - and
for
> shoutcast maybe shoutcasts). Each of these sources will then be able
to be
> requested for a list of music (in this case)
>
> C) A client will simply ask the core for all media it can use (e.g.
rio
> will
> ask for M) and then the lists returned above are usd to construct the
menu
> layers (thinking here of the 2nd/3rd menu levels on the current
xplrionet)
>

My problem with using the database approach in xPLRioNet has always been
that selecting music by genre (for example) returns a list of tracks, where
it would be more useful (to me, at least), to get a list of albums (or
artists, even).  Could the requests include a "level of detail"
to be
returned (ie track, album, artist, genre), to enable heirarchical menus to
be built?  For example, if I request music of the "R&B"
genre, with a level
of detail of "artist", the core would return the data containing
a list of
R&B artists as the top menu layer, with their albums and then tracks as
submenus.  Perhaps the data could be returned to the client as an xml file,
which can easily describe the menu hierarchy.

> D) if a client selects a media it can't play (e.g. rio asks for a wav
file
> but doesn't support wav natively) it can then request that the core
> initiate
> an appropriate transcoder module to interpret the track into mp3 for
> instance.
>

Sounds good.

Will there be any management of clients' access to hardware resource?  I'm
thinking along the lines of a PC running several clients where it's
perfectly possible to be viewing pictures and listening to music at the
same
time (two clients running simultaneously), but if a movie is played, it
occupies both the audio and video systems.

> E) a source will either return a filename (if media is disked based
and
> can
> be accessed directly by the client) or it will be given a link to a
module
> that can supply the data (this is also how a transcoder will function)
>

Can we also require that clients respond to xPL commands to play a media
file, rather than just ones they request?
For example, if I want an Exstreamer to play a pre-recorded announcement,
or
perhaps some music as an alarm clock, which would be driven by xPLHal
scripts, rather than the Extreamer module's user interface.

The database request by the client to the core to obtain a list of
available
files obviously has to be handled outside the normal xPL message framework,
but if everything else was done using xPL messages, this external control
would automatically be supported.

I.e. the client requests a list of files from the core, and when a
selection
is made, sends an xPL message to the core requesting the file.  The core
responds with an xPL message commanding the client to play the file, and
where to get it (with any redirection to other sources/transcoders applied)

> Given the above if someone writes a new source, it can be added and
will
> automatically be available to all available clients.
>
> Also, sources may or may not be loaded at boot up. E.g. the scanner
> sources
> will load at startup, but shoutcast will only load when needed (as
> multiple
> instances are required if multiple units are playing shoutcasts).
> Transcoders will never load at startup, as they are only needed when
> called.
>
> Thoughts/comments please?
>
> Many thanks
> Tony


Mal



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