[mythtv-users] Comcast OnDemand on Multiple STBs
cmisipster at gmail.com
Wed Nov 14 00:31:09 UTC 2007
On Nov 13, 2007 12:28 AM, Worldnet <onley at worldnet.att.net> wrote:
> > 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.
> mythtv-users mailing list
> mythtv-users at mythtv.org
I dont think you can figure out the encoder being used from tvchain's chanid
info. I checked the chanid's on my system and one set start with 1 (i.e.
1007) and the second set start with 2(i.e. 2007) which means it is tied to
the listings source( of which I have 2 ) and not encoders ( of which I have
4) . Still there's got to be a mysql way of determining the current
encoder running in livetv mode for a specific mythfrontend. Perhaps you
need to repost the question again on the list more specifically.
I even checked the status port xml and I dont see anything unique there to
identify which encoder is attached to which frontend.
I see this as the biggest obstacle you have. Everything else seems very
workable. For example, remote execution with mysql would work like this
which would generate sql info that could be parsed with sed, tr, awk, grep.
mysql -umythtv -pmythtv mythconverg -e 'SELECT * FROM tvchain WHERE chainid
LIKE "%mybedroom%"' -h mymythtv
Remote command execution of the channel change script would work like this
(assuming you have passwordless ssh setup):
ssh user at backendhostname "changechannel encoder UP"
And that could be called directly on the local mythfrontend by lirc via an
irexec command. Switching modes in lirc is possible such that you can enter
"VOD mode" by pressing a particular button (mode switch button?) , and all
your buttons are immediately redefined. Pressing the mode switch button
again allows you to leave "VOD mode" and go back to "Default Mode". This is
by using the mode and flags option in lirc.
There might be another way to get around to the "which frontend is using
which encoder" problem. If you setup a channel source for each encoder such
that encoder 1 channels will start with 1 (i.e. 1007); encoder 2 will start
with 2(i.e. 2007), encoder 3 would start with 3(i.e. 3007) if that is indeed
how the channel naming scheme works in mythtv. If that is the case,
determining which encoder is active from the tvchain sql query amounts to
checking for the value of chanid.
So, basically your script (taking one argument which is either UP, DOWN,
etc) on the mythfrontends would do this :
1. Determine the hostname where the script is running
2. Determine the current time
3. query the remote mysql database as the above example, and parse the
output selecting the results that match the current frontend hostname and
the current time.
4. check for the chanid value to determine the encoder
5. remotely call the channelchange script on the backend with first
argument as encoder and second argument as UP,Down,etc.
Let us know how things work out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users