[mythtv-users] Comcast OnDemand on Multiple STBs

[Paul Onley]

>>> Have the channel change script write some status information to a file 
>> > and use it to determine which capture card is watching what?>  
>> Basically, the point is that the external channel change command knows>  
>> which capture card/input is being used, so, don't throw that information 
>> > away. Put it somewhere you can find it... Specific implementation>  
>> instructions would require knowledge of exactly what your plan is for>  
>> figure out (once you start going down the right path ;).> MikeI'm not  
>> following you. If the channel change script was to write to astatus  
>> file it would reside on the backend. How would the frontendgo about  
>> reading this file? Further more since all OnDemand programingis on  
>> Channel 1 if two frontends were to watch OnDemand at the sametime the  
>> status file would show 2 STBs watching channel 1.The exact plan is to  
>> be able to send left, right, up, down and selectto the correct STB.  
>> Since I am already controlling 4 STBs in exactlythe way you suggest I  
>> don't see where I am not on the right path.I have 1 master backend  
>> server which has 5 tuners and 4 STBs. In theconfiguration of each tuner  
>> that is connected to a STB there is aplace to enter a command to  
>> control an external tuner. I have addedcode to the DCT2000  
>> channel_change executable to accept a commandline argument for the port  
>> to send the information to and in eachtuner configuration I have  
>> entered "/usr/local/channel_change x"where x is the serial port that  
>> the STB is connected to. This isEXACTLY how this is supposed to be done  
>> as well as how you recom>mendI do it, so up to this point we should be  
>> in FULL agreement. Now,I have 5 remote frontends, one in the living  
>> room, one in the kidsplayroom, one in my bedroom, one in the boys  
>> bedroom and one in thegirls bedroom. If the kids are watching OnDemand  
>> in the playroomhow should I go about sending the left, right, up, down,  
>> and selectinteractive codes to the STB that they are watching?I can  
>> only see 2 scenarios that would work.1) Modify Myth so that you can  
>> send things other than channelnumbers out through the external tuner  
>> command.2) Somehow have the frontend that you are watching interogate 
>> the backend to see what STB it is connected to.As I undersand I can  
>> query the database to get thisinformation. I do not yet know how to do  
>> this butit appears I will have to learn.Somehow send the codes to the  
>> STB which is connected to thebackend.At this point the frontend knows  
>> which STB it needsto send the codes to but I am not sure how to goabout  
>> calling a program on the backend. I wouldimagine that a daemon would  
>> have to be createdto listen for requests from the frontends andforward  
>> the codes to the STBsIf you think I am on the wrong path then please  
>> tell me where I'mgoing wrong. 
>> _______________________________________________mythtv-users mailing list 
>> mythtv-users[at]mythtv.org 
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
> If you only have one frontend doing VOD, I can see how it might be 
> possible, by grepping index.html for "Live" or "VOD" which you get with 
> "wget backend:6544". ( I assume an encoder recording channel 1 would 
> display channel info as VOD)
> Once you figure out which encoder is doing live TV VOD , then you know  
> whichSTB is connected to your frontend. You can then use ssh to remote  
> execute acommand.
>
> I dont know how else you can figure out which frontend is connected to  
> whichSTB if you have more than one STB doing VOD.

> Alternatively, if you just need one VOD active at any time, then perhaps  
> youcan eliminate this channel from the three STB's so that when you  
> selectchannel 1 on any frontend, you are immediately connected to a  
> known STB.
> Another thing you might do is to have a slightly different lineup for  
> eachtuners. For example, tuner 1 only has channel 99, tuner 2 only has  
> channel100. That way you can select a specific tuner (hence a specific  
> STB) bychanging to the unique channel, then channel change to 1 after  
> that.
> I'm really just rambling these ideas. I dont know if they will work.
> Hope it helps

I had thought about only having channel 1 in 1 lineup but with 3 kids that
like the OnDemand programing that would lead to fights over who gets to
watch. The idea of using a dummy channel so that each frontend knew which
STB it was using is interesting, I hadn't thought of that. The only issue
there is that if that tuner is in use that frontend will not be able to
watch OnDemand. What I am really hoping is that this will generate some
interest and maybe the programers can create a hook to send these other
codes through the existing mechanisms. I have seen several threads on
sending interactive codes to OnDemand programing and with the proliferation
of ingteractive digital content I can only see the need for this feature
growing. What would  be really great is if there was a script that could
run on the frontend machine to send a code through the external tuner
command. Then all the user would have to do is call the script with the
code from the lircrc config file, this would allow the user to very
easily map any key on the remote to the STB with one simple line in a
config file.

I think what I'm going to end up doing for now is reading the database
and finding out which STB is being used and sending the code from outside
Myth. My brother is very good with MySQL and we can write a daemon that
will run on the backend and listen for requests from the frontends to send
codes to the STBs. The frontend will have to identify itself by host name
and specify the key it wants sent. I have found a table in mythconverge
that lists which frontend is connected to which tuner and the daemon can
take that information and send the code to the correct STB. This will work
for me but since everyone has different hostnames for their machines and
different names for their tuners it will be a very unique solution that
will require modification for each implementation.

Thanks for the input Chris, the dummy channel is a good idea, I may use
that until we can workout the details on the database/daemon path.
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/