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: Thursday, March 10, 2005 10:56 AM
Subject: RE: [ukha_xpl] Some thoughts on xplmedianet and how to implement


>
>> 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).
>
> Will look into this when building the scanner
>
>> 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.
>
> Not sure I follow.
>
> Any client can play/display anything at anytime (e.g. an MVP can
actually
> play music AND display pictures at the same time)
>
> No client effects what another client can be doing, regardless of what
any
> other client is doing (the only exception is that an mvp playing a
movie
> can't be doing anything else)

I was thinking more of when they are running on an HTPC, than a stand alone
device like an Extreamer or MVP - you could have several clients (winamp,
videolan etc), but they share the same display and soundcard, but using one
does not necessarily prevent another from working - ie picture viewer and
winamp could play nicely together, but playing a movie requires both to
stop.  Do clients have priorities, or is it a case of just taking over and
stopping any other client that is already using the resource we need?

>
>> Can we also require that clients respond to xPL commands to
>> play a media > file, rather than just ones they request?
>
> All clients will support full xpl control
>
>> 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.
>
> Not sure this is necessary.
>
> Since the client will receive an xpl command, it then does it's
internal
> stuff (with the core) to get at the track (or whatever) as if it was
> requesting it itself (actually it _is_ requesting it itself)
>
> E.g. queue a track, play
>
> This is no different to the web interface that will control the
clients
> via
> xpl
>

OK, that makes sense to me now.





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