<br><br><div class="gmail_quote">On Nov 13, 2007 12:28 AM, Worldnet <<a href="mailto:onley@worldnet.att.net">onley@worldnet.att.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>> I still think:<br><br>> a) the channel change script (which receives channel number and STB ID)<br>> should write a file (this time I'll explicitly say, "to a /shared/<br></div>
> filesystem") with this infob) the user hits a button on the remote to go<br><div class="Ih2E3d">> into "interactive" mode(i.e. so that Left/Right/Up/Down/Select are sent<br></div>> to a script rather thanto mythfrontend (uses LIRC modes--though if you
<br>> had another approach inmind, it should work just as well to kick off<br><div class="Ih2E3d">> this process of"retrieving" the info)--since you need interactive<br></div>> control, auser-initiated event to "pull" the info to the frontend
<br>> shouldn't be anissuec) the script runs and looks for a local file to<br>> give it the info aboutwhich STB is in use, but doesn't find itd) the<br><div class="Ih2E3d">> script reads the shared file created by the channel change scriptand
<br>> writes info to the local file--which is not at the same location asthe<br>> shared file--then deletes the channel-change-script-created, sharedfile<br>> (or just moves the channel-change-script-created file) then usesthis
<br>> info to send the event to the appropriate STB (see man lircd andsearch<br>> for --connect; there's no need for "remote execution" or a"daemon"<br>> process or anything)d) next button press, the script runs again, sees
<br></div>> the local file, anduses its info to send the event to the appropriate<br>> STB (step d repeatedas required)e) when done controlling the STB (i.e.<br>> once VOD begins), the user hits abutton on the remote to exit
<br>> interactive mode (so that the remote nowcontrols mythfrontend, again)<br>> and the same button is configured (ininteractive mode) to delete the<br>> frontend-created local file with the STBinfo to "reset" the
<br><div class="Ih2E3d">> configuration for next time<br>> Of course, this does mean that if someone starts VOD on one STB and<br>> doesn't start the process by sending an event to the interactive-mode<br>> script, another person starting VOD on another STB would cause a race
<br></div><div class="Ih2E3d">> VOD-portion of the channel change script until the shared file isremoved<br>> (only the VOD-portion should be locked, though--that way, normal<br>> recordings wouldn't be affected if you start a VOD right before a
<br>> regularly-scheduled recording begins). You may also want to lock the<br>> interactive mode script to queue commands in a first-in-first-out order<br>> to prevent out-of-order execution due to the intricacies of kernel
<br>> process scheduling (so you/your kids don't accidentally purchase a video<br>> you don't want because commands went out of order).<br>> The new script shouldn't be hard to create and the channel change script
<br>> modifications should be easier than the new script. If I had any usefor<br></div>> VOD, I would use this approach, but, hey, it's your box--feel freeto do<br><div class="Ih2E3d">> it a different way.<br>
> You do realize, though, that LiveTV will be broken up such that Myth<br>> changes files on the half hour since you'll be lacking guide data forthe<br></div>> channel. So, if you record a 1 1/2-hour on-demand movie from7:53-9:23
<br><div class="Ih2E3d">> PM, you'll have part 1 (7:53-8:00), part 2 (8:00-8:30), part 3<br>> (8:30-9:00), and part 4 (9:00-9:23). Therefore, the "right" way torecord<br></div>> the show is using a manual recording rule. And, IIRC, thetvchain table
<br><div class="Ih2E3d">> is used /only/ for LiveTV...<br>> Mike<br><br></div>Thanks Mike,<br><br>There are some very good ideas here. I have some work to do to<br>decide exactly which route to take.<br><br><br>The reason the OnDemand is so important is that there is some very
<br>good kids content available for free so it would only ever be<br>live viewing.<br><div><div></div><div class="Wj3C7c"><br>_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org">
mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a></div></div></blockquote><div><br><br>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.
<br><br>I even checked the status port xml and I dont see anything unique there to identify which encoder is attached to which frontend. <br><br>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.
<br><br><br> mysql -umythtv -pmythtv mythconverg -e 'SELECT * FROM tvchain WHERE chainid LIKE "%mybedroom%"' -h mymythtv<br><br>Remote command execution of the channel change script would work like this (assuming you have passwordless ssh setup):
<br><br>ssh user@backendhostname "changechannel encoder UP"<br><br></div></div>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.
<br><br><br>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.
<br><br>So, basically your script (taking one argument which is either UP, DOWN, etc) on the mythfrontends would do this :<br>1. Determine the hostname where the script is running <br><br>2. Determine the current time<br>
<br>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.<br><br>4. check for the chanid value to determine the encoder
<br><br>5. remotely call the channelchange script on the backend with first argument as encoder and second argument as UP,Down,etc.<br><br>6. Quit <br><br><br>Let us know how things work out.<br><br>Chris<br><br><br>