RE: Possible New Schema: status.basic

["Ian Lowe" <ianlowe@xxxxxxxxxxxxxxxxx>]

I guess I wasn't seeing the commonality - now you mention it, yeah, I guess
there's enough in common to produce a more general avtuner.basic schema.

I'll see how I get on ;)

Ian.



-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On Behalf
Of Gerry Duprey
Sent: 12 November 2005 15:42
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] Possible New Schema: status.basic

Howdy,

Ian Lowe wrote:
> I'm looking at an app to decode the Sky Digibox data packets, and
getting
> some good results - the problem now comes of getting this information
out
> onto the xPL network.

> I'd like some feedback on this one please?

Well, remember -- you DID ask for feedback :-)

I think the status.basic certainly could work.  But consider this:

Even with an XML based schema and parser to understand it, no generic xPL
client would be able to do much with such packets because the packets could
be basically anything. That is, other than knowing that the schema info is
valid/defined/known, nothing about the content could be assumed.  Another
way of thinking about this would be using a schema class of
"misc" or
"general".

While I agree that every cable box is going to be different, I do think
there are enough commonalities that you could create a simple avtuner.basic
(avtuner to be distinct from a simpler radio tuner that could easily be
created) that could then be extended for more specific tuners (i.e.
extended
with any sky specific stuff as avtuner.sky, for example).  Then a more
generic app would still be able to read some info from the tuner even if it
didn't know specifically about sky.

For example, consider a status message like

xpl-stat/xpl-trig

avtuner.basic
{
state=[onoff]
[tuner=[123...]]
channum=250
[channame=BBC 77]
[chanid=1233321]
[programname=Name of show on this channel] [episodename=Title of episode on
this channel] [showsummary=Summary description of show]
[starttime=yyyymmddHHMM] [duration=mmm]

** Some Details:
tuner= is used for devices with multiple tuners.  If a device has a single
tuner, this should be tuner=1 or can be omitted (since 80% of tuner like
devices out there have a single tuner).  My Motorola HDTV box, for example,
has two tuners in it.  A MythTV setup can have 2, 3, 4 or 5 tuners in it.

chanid= is a unique identifier assigned to a channel by some listings
providers.  Here in the US, it's called a tmsid and every channel has a
uniquely assigned one that does not vary by which channel # the channel
appears on for a particular cable company.  I suspect there is something
similar in other countries (which is why I didn't suggest the tag name
being
tmsid= and left it a bit more generic).

The programname=/episodename=/showsummary=/starttime=/duration= are all
optional and useful if the tuner has access to show listings and can
provide
info on the currently tuned channels show.  Simpler tuners that either do
not have listings or do not expose those listings externally would just not
publish these (and even tuners with exposed listings may not publish all of
them).

I think the rest are pretty self explanatory.

And commands might look like:

xpl-cmnd

avtuner.basic
{
[tuner=[123...]]
command=[onoffchan_upchan_downgoto_chan]
[channel=chan# to goto]
}

One of the other projects I develop for is called DVArchive
(http://www.dvarchive.org) and it's
a software interface to the ReplayTV
(similar to a TiVO, but more open).  I've also done some early work on
MythTV (that is to say, my work is in early stages, not work on the core of
MyhTV itself) and have dabbled with my Motorola HDTV cable box.

I feel confident I could implement the above schema for any of these
devices
and based on your description of the sky protocol, I think the above would
fit in as well.  I did a little research on some satellite boxes and while
most don't have a lot to say, those that can would fit into the above
schema
well.

An extension of the schema could then be made for specialty devices (i.e.
if
the sky box provided substantially more or different data) as well as more
advanced "tuners" (I can easily see a avtuner.recorder extension
that would
allow for commanding DVR/PVR like units to schedule recordings -- something
I can do with ReplayTV (via DVArchive) or MythTV today).

But the point is, even a complex, unique and truly odd-ball device could
extend avtuner.basic and yet a generic app could still handle the 'basic'
part of messages from it.

Just some thoughts,

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org



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