[mythtv] Caller ID

[Ken Bass]

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?