[mythtv-users] Comcast OnDemand on Multiple STBs

Michael T. Dean mtdean at thirdcontact.com
Tue Nov 13 01:06:46 UTC 2007


On 11/11/2007 09:46 PM, Worldnet wrote:
> I would rather use a documented hook
> to get the info as using this method will leave me in the dark if
> the database changes with a future upgrade. This is all the info
> I need in conjunction with a remote exection command (which I have
> yet to figure out) to get the job done and cover all forseeable
> situations.

I still think:

a) the channel change script (which receives channel number and STB ID)
should write a file (this time I'll explicitly say, "to a /shared/
filesystem") with this info
b) the user hits a button on the remote to go into "interactive" mode
(i.e. so that Left/Right/Up/Down/Select are sent to a script rather than
to mythfrontend (uses LIRC modes--though if you had another approach in
mind, it should work just as well to kick off this process of
"retrieving" the info)--since you need interactive control, a
user-initiated event to "pull" the info to the frontend shouldn't be an
issue
c) the script runs and looks for a local file to give it the info about
which STB is in use, but doesn't find it
d) the script reads the shared file created by the channel change script
and writes info to the local file--which is not at the same location as
the shared file--then deletes the channel-change-script-created, shared
file (or just moves the channel-change-script-created file) then uses
this info to send the event to the appropriate STB (see man lircd and
search for --connect; there's no need for "remote execution" or a
"daemon" process or anything)
d) next button press, the script runs again, sees the local file, and
uses its info to send the event to the appropriate STB (step d repeated
as required)
e) when done controlling the STB (i.e. once VOD begins), the user hits a
button on the remote to exit interactive mode (so that the remote now
controls mythfrontend, again) and the same button is configured (in
interactive mode) to delete the frontend-created local file with the STB
info to "reset" the configuration for next time

Of course, this does mean that if someone starts VOD on one STB and
doesn't start the process by sending an event to the interactive-mode
script, another person starting VOD on another STB would cause a race
condition which would break things.  You could fix this by locking the
VOD-portion of the channel change script until the shared file is
removed (only the VOD-portion should be locked, though--that way, normal
recordings wouldn't be affected if you start a VOD right before a
regularly-scheduled recording begins).  You may also want to lock the
interactive mode script to queue commands in a first-in-first-out order
to prevent out-of-order execution due to the intricacies of kernel
process scheduling (so you/your kids don't accidentally purchase a video
you don't want because commands went out of order).

The new script shouldn't be hard to create and the channel change script
modifications should be easier than the new script.  If I had any use
for VOD, I would use this approach, but, hey, it's your box--feel free
to do it a different way.

You do realize, though, that LiveTV will be broken up such that Myth
changes files on the half hour since you'll be lacking guide data for
the channel.  So, if you record a 1 1/2-hour on-demand movie from
7:53-9:23 PM, you'll have part 1 (7:53-8:00), part 2 (8:00-8:30), part 3
(8:30-9:00), and part 4 (9:00-9:23).  Therefore, the "right" way to
record the show is using a manual recording rule.  And, IIRC, the
tvchain table is used /only/ for LiveTV...

Mike


More information about the mythtv-users mailing list