Re: [offlist] xPL Readme.txt (more Questions!)

[Mal Lansell <mal@xxxxxxxxxxx>]

Tony,

Thanks for the speedy reply.  I've put my comments inline (note - I've
cc'd this to the list case anyone else wants to chip in - I hope that's OK)

Tony Tofts wrote:

>>Do xPLMediaNet clients all implement their own playlists, or
>>is that handled by the server with the clients merely having
>>to play individual files and report status?  MediaPortal's
>>playlists don't quite have the right functionality to match
>>xPLMediaNet (the random feature is different, and you can't
>>mix media types), so if it has to be done by the client, I'll
>>have to write my own.
>>
>>
>
>The server _is_ the clients, i.e. they send IR to the server, they
receive
>screen updates and packets of music/movies or screen displays to
display.
>All the client logic for current devices is in xplmedianet (so
basically
>theyre like dumb terminals)
>
>But regardless of how future devices work, it is the intent that if
they are
>a supported device in xplmedianet then xplmedianet will handle as much
as
>possible, so it knows as much as possbile and can perform the various
>functions (like xpl) that the devices won't know anything about
>
>That said I also intend to add support for controlling dvd/cd changers
etc
>
>
>
Perhaps I'm getting ahead of the game, but I was under the impression
that the idea of new clients created by other authors was to be
supported, in which case we would need some form of plug-in approach,
rather than inclusion in the main build.  This may be not such a huge
issue for Media Portal, since my intention is to create a plugin that
operates purely via xPL messages.  Integration with xPLMediaNet would
probably take the form of a second plugin or application that could
translate whatever xPLMediaPortal spits out to a pure xPL (unless of
course a generic xPL client is part of your plans, in which case I could
respond to that instead)

>>What should I return in a status message if I'm playing a
>>file from a browse source?  I might not have
>>artist/album/track (especially if not tagged).  Should that
>>be inferred from the file path, or is an alternative status
>>message containing the file details as sent in the original
>>command more appropriate?
>>
>>
>
>With xplmedianet all physical files are expected to have either tags,
or be
>identified via path/filename (broken up to provide as much info as
possible
>e.g. artist, album, track, genre). At the simplest level this would be
just
>the filename (with no extension) assumed to be the track name.
>
>If were talking the playing/now next status messages, these are purely
>informational anyway, so including path or anything probably isn't a
good
>idea?
>
>
>
Yes, playing/next is what I was talking about. Those schemas relate to
either a stream (which I assume means shoutcast etc) or an
genre/artist/album setup.  I think the issues arise because you're
concentrating on music, whereas my main interest is video.  If I have a
command to play a video file, I don't have artist/album etc to report.
I think we need a schema that either reports the filename, or the entire
path+filename, but I'm not sure which would be most appropriate for
xPLMediaNet.  I know I could invent my own schemas, but for the sake of
compatibility I'd like to use the xPLMediaNet ones as much as possible -
that way we make life as easy as possible for the end user.

>>At the moment, next/prev jump to next/prev playlist item, or
>>next/prev chapter if playing a DVD.  I wonder whether we
>>should define a different next/prev for chapters, since it is
>>technically possible to have a playlist of DVDs.  As an
>>example, I rip individual episodes as if they were small
>>DVDs, so potentially I could rip music videos this way.
>>
>>
>
>Currently xplmedianet only supports 'playlists' for music, not videos
or
>pictures (and I don't have any current plans to implement these -
though
>that might change)
>
>Also, so far I've not implemented xpl control for videos/pictures -
though
>this will be added. So the stuff in the xpl readme mainly relates to
music.
>Feel free to draw up any necessary schema stuff for videos, and
hopefully
>I'll be able to implement them the same way?
>
>
>
Playlists to me just mean a list of files.  If they happen to be music
or video is neither here nor there - if a client can't play it then it
should just skip.  With a client such as Media Portal that is capable of
playing both, then I think a single playlist should be able to handle
them.  Unfortunately, MediaPortal appears to implement separate
playlists for video, music and radio files, which means I would have to
create my own queue (not a big deal, given that I already send status
messages when a file has finished playing).  I don't need any schema
modifications  - the media type can be derived from the file extension.

>>I'm only supporting the source=browse version at the moment.
>>If I receive one of the others, how do I go about getting to
>>the file?  Does the path come from an xPLMediaNet database?
>>If so, how would I access it?
>>
>>
>
>It's down to the individual source. i.e. my video scanner source knows
to
>use it's database, my browser knows it has to go off in real-time and
read
>the tags/filepath or whatever. For this reason in the xpl queue message
if
>you want to queue via path/filename you have to specify a source that
>understands path/filename (currently just browse). Hope that makes
sense?
>
>The source name _isn't_ fixed though! You can change the title of the
source
>to anything you like, and also load multiple sources if you want. So
the
>source= is a dynamic value identifying the source...
>
>Basically the components of xplmedianet (particularly in relation to
devices
>and media sources) know nothing about each others existance, they just
use
>common methods of providing info between each other. That way I can add
a
>new source and all devices that can use that media type instantly have
the
>source available without any other changes, and vice versa)
>
>
I must be missing a step here.  As an example, suppose someone wanted to
use the xPLMediaNet web interface to trigger the playing of an MP3 file
on Media Portal.  Somewhere along the line, that command is going to
come from xPLMediaNet as an xPL Message.  Do I need to write an
xPLMediaNet client that will take the web command and convert it to an
xPL message containing a "play file" command to then be sent to
MediaPortal, or would MediaPortal receive an artist/album/track style
message that I then have to go back to xPLMediaNet for a translation to
an actual path?  In other words, does my plugin need to deal with those
different messages in the schema text file, or does it only need to
respond to play file commands with a second piece of code acting as an
xPLMediaNet client, retreiving paths from the xPLMediaNet database and
then sending them on to MediaPortal? (I hope that makes sense, but I've
had a few glasses of wine this evening trying to forget some nonsensical
XML schema diagrams I was sent this afternoon!)

Regards

Mal



[Non-text portions of this message have been removed]