[mythtv-users] Comcast OnDemand on Multiple STBs

[Worldnet]

> 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 infob) 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 thanto mythfrontend (uses LIRC modes--though if you  
> had another approach inmind, it should work just as well to kick off  
> this process of"retrieving" the info)--since you need interactive  
> control, auser-initiated event to "pull" the info to the frontend  
> shouldn't be anissuec) the script runs and looks for a local file to  
> give it the info aboutwhich STB is in use, but doesn't find itd) the  
> script reads the shared file created by the channel change scriptand  
> writes info to the local file--which is not at the same location asthe  
> shared file--then deletes the channel-change-script-created, sharedfile  
> (or just moves the channel-change-script-created file) then usesthis  
> info to send the event to the appropriate STB (see man lircd andsearch  
> 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, anduses its info to send the event to the appropriate  
> STB (step d repeatedas required)e) when done controlling the STB (i.e.  
> once VOD begins), the user hits abutton on the remote to exit  
> interactive mode (so that the remote nowcontrols mythfrontend, again)  
> and the same button is configured (ininteractive mode) to delete the  
> frontend-created local file with the STBinfo 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 
> VOD-portion of the channel change script until the shared file isremoved  
> (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 usefor  
> VOD, I would use this approach, but, hey, it's your box--feel freeto 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 forthe  
> channel. So, if you record a 1 1/2-hour on-demand movie from7: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 torecord  
> the show is using a manual recording rule. And, IIRC, thetvchain table  
> is used /only/ for LiveTV...
> Mike

Thanks Mike,

There are some very good ideas here. I have some work to do to
decide exactly which route to take.


The reason the OnDemand is so important is that there is some very
good kids content available for free so it would only ever be
live viewing.