[mythtv] Caller ID

[Jason Schloer]

Figure I'll jump in here. It seems that a "mythOSD" is in order, but not
necessarily as a separate module, more like an integral part of the Myth
module system. I posted a question recently about having an OSD menu for
a Home Automation system so that I wouldn't have to go out to the main
menu to do the things I want to do. In mentioning this I said making it
part of the plugin interface wouldn't be a bad idea. Isaac indicated
that's sort of what he had in mind. My thought is that we should take
care to do this well the first time and design a nice extensible
framework before diving into development. 

My thought was to have a method on the plugin interface to provide
access to the OSD. This would probably just accept an XML definition of
the OSD. Then existing modules like mythtranscode, or mythmusic could
give status through this, allowing things like encoding CDs or checking
the weather while watching TV. In fact this would actually warrant
having two methods exposed one for pushed OSD events(from the module to
the TV), and one for pulls(ie. get the mythweather menu). 

Then from this a MythNotify module could be made which could accept any
type of connection we'd like. Have it monitor a UDP port, setup a device
in dev, whatever. This module would translate the incoming message into
whatever OSD format we'd like. This could be a single generic message
box, or specific for certain types of messages like caller ID. 

On that same note, something like the LCD support could be handled in
the exact same way. (I know there was a rewrite of that recently, though
I haven't had a chance to see how it works now.) 

Also, how do we handle messages to be displayed while another menu is
up, including the main menu. Do we want to overlay the information on
the main menu? Or should pushed messages be defined within a region of
the current theme? My personal thought is that this should pertain to
only the TV screen, but I'd love to see discussion as to the pros and
cons of other screens having information display regions accessible by
other modules. For instance caller ID is just as applicable when
mythmusic is running as it is while watching TV. Perhaps someone who has
a better knowledge of Myths display framework could chime in.

Let me know what holes there are in this. My biggest concern is not
knowing how menus are processed for the OSD, so I don't know what
methods would be needed to pass a message on to its respective module. I
imagine I've probably missed other things as well. I've looked through
some of the source, but haven't had a chance to really dive in just yet.
I look forward to everyone's comments. Also, we may want to spawn this
off as a different thread in order to attract people interested in more
than just caller ID. Sorry this is so long.


Jason Schloer


-----Original Message-----
From: mythtv-dev-bounces at mythtv.org
[mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of Ken Bass
Sent: Wednesday, September 17, 2003 3:29 PM
To: mythtv-dev at mythtv.org
Cc: e_cloud at yahoo.com
Subject: Re: [mythtv] Caller ID

On Wed, 17 Sep 2003 10:16:20 -0700 (PDT), Shawn Rutledge
<e_cloud at yahoo.com>
wrote:
>
>Like I said before, to get the greatest flexibility, the receiver
>shouldn't be built-in to Myth anyway; there should be a command-line
>method to put up arbitrary OSD's on Myth, and the receiver should be a
>separate process (or shared-library "plugin" or something like that)
>which listens to UDP packets and then calls Myth with the data to
>display.  Then you could have OSD's about events which come from other
>sources besides UDP ("CPU temperature out of range" is a good example).

 Several good comments. This raises several questions, hopefully someone
with myth programming knowledge can help with some of them:

1) Say there is a 'mythosd' program. How would the invocation of this
program communicate with the running myth. Would it use some shared
memory
scheme, use a local UDP (non-broadcast), or what?

  In my current implementation, I've added a UDPNotify object which
receives
the XML/UDP, parses it, and then invokes myth's built in OSD
theme/container
capability to display them. The container/text area 'widgets' have to be
specified in the osd.xml (theme definition) file. I don't see a way to
just
overlay data on the display independent of it being defined in the theme
and
I'm not sure that would be a good thing either. The fact that the
current
OSD software handles the positioning/sizing/rendering of these
displayable
objects requires that I somehow map what needs to be displayed in a
deterministic manner to what the theme specifies using the names
recognizable by the theme.

2) A few people have mentioned displaying images. Static images are easy
because you can just specify the 'background' PNG in the theme to
contain
whatever image you want -- this will be displayed as the notification
background and it independent of what I've done. However, I don't know
of a
way to handle dynamic images. Images can be too large send via UDP and
I'm
not sure of the performance hit. Within the OSD there is an OSDTypeImage
but
those normally are created when mythtv starts up, not at runtime. 

>The external listener could do the transformation from data-oriented
>XML to some kind of display-oriented form.  It could just generate a
>command line like this:
>
>mythosd --title="Incoming phone call" --name="Joe Blow"
>--number="1-888-555-1212" 
>
>and mythosd would extract the title and treat it specially, and for
>every other parameter it would display the key and the value as labeled
>text fields.  

  Displaying the key/value fields of the above command line arguments
would
seem to take away a lot of flexibility and result in a crude looking
interface. I'm not sure how it would tie in with the OSD theme either.

>Or, if you prefer, you could generate display-oriented
>XML and hand that across to Myth:
>
><osd title="Incoming phone call">
>  <field name="Name">Joe Blow</field>
>  <field name="Number">1-888-555-1212</field>
></osd>
>
>It's every bit as generic, for describing the content of an on-screen
>display, and it's Myth-specific, which might be appropriate for Myth,
>but this form of data does not belong in a UDP packet.

 This looks more doable. However, what performs the 'magic' of
converting
the command line to something that maps to the OSD names. One persons
theme
might specify the Caller Name to be displayed in a container in the top
left
corner and the Caller Number to be displayed in a container in the top
right
corner. A different persons theme might specify a container to contain
both
Caller Name and Number. 

  How would this mapping work? Using command line arguments seems
limiting
and unable to capture the variety of container combinations. That is
partly
the reason I used an input 'XML' file that has keywords replaced.
Perhaps
this mythosd would still use an 'XML' input file and the search/replace
would be the way to map the command line args to whatever structure the
user
wants. For example,

mythosd --template="cid.xml" --title="Incoming phone call" --name="Joe
Blow"
--number="1-888-555-1212" 

where cid.xml could be

<mythnotify version="1">
   <container name="notify_cid_info_title">
     <textarea name="notify_title">
       <value>%title%</value>
     </textarea>
   </container>
   <container name="notify_cid_info_upper_left">
     <textarea name="notify_name">
       <value>NAME: %name%</value>
     </textarea>
   </container>
   <container name="notify_cid_info_upper_right">
     <textarea name="notify_num">
       <value>NUM : %number%</value>
     </textarea>
   </container>
 </mythnotify>

  A few people have mentioned XSLT to do the mapping. How would this
work?
How would I map the command line arguments

>And then there could be a temperature-monitoring daemon which uses the
>same interface to put up OSD's when the CPU gets dangerously hot, and
>another daemon which does notifications about something else, and so
>on.

  Those would be useful notifications for some people.

>I have not written any Myth code before.  If you have figured out how
>to put up on-screen displays, then I think you should write the code to
>do that, and I will write the listener to convert my caller ID packets
>to whatever form the OSD code wants, and we can collaborate on a sender
>which is independent of mgetty.  Then we will have interoperability,
>and we won't have Myth listening on a port itself.

  I'm not sure how far off our concepts are. If I modified my cidbcast
to
become mythtvosd it could still send UDP/XML over a local/non-broadcast
UDP
port by mapping command line args into an XML template. Thus UDP is
required
because there still needs to be some way to get the data from the
mythtvosd
program into mythtv. I'm not sure this changes anything in the
backend/myth
part from what I have already done.
  Next, a 'mythudpnotify' receiver would be needed which receives
broadcast
UDP/XML events (such as a callerid event) and maps them to command line
arguments of 'mythosd'. Any ideas on how this would occur?
  Lastly, my current cidbcast would generate a callerid event instead of
something myth specific. We could look at merging some of Shawns/mine.

  Would the fact that the 'mythudpnotify' receiver would be invoking
'mythosd' as an external program cause performance problems?