<div dir="ltr">On Fri, May 24, 2013 at 1:21 PM, Erik Sejr <span dir="ltr"><<a href="mailto:esejr@wildroseinternet.ca" target="_blank">esejr@wildroseinternet.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 2013-05-17 21:20, Erik Sejr wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ever since I moved to Ottawa I've been fighting a battle with Rogers'<br>
crappy STB, specifically a Cisco (SA) Explorer 8642. This thing turns<br>
its self off after 7 or 8 hours of inactivity (I don't know the exact<br>
number) but even worse, Rogers does frequent late night firmware updates<br>
which always cause the device to reboot and come up powered off.<br>
<br>
The result, black recordings with no means of getting feedback about the<br>
state of the STB as firewire does not work and there is no discrete<br>
power ON IR command, only a toggle.<br>
<br>
For a while I tried a modified version of ingenious script on the wiki<br>
which dd's a few seconds from the recorder, splits it into frames with<br>
ffmpeg, converts those to "ascii" then checks to see if they are<br>
"black". Unfortunately, while I was able to modify this script to work<br>
with the HD-PVR it seems that the act of using dd to copy data right out<br>
of /dev/video0 somehow causes the hd-pvr and/or the driver to become<br>
unstable. The only fix I found was to rmmod the driver, reboot the<br>
hdpvr, and then reload reload the driver.<br>
<br>
I gave up on the above method and tried to use the event bindings in<br>
mythtv instead - turn the power on when the "recording pending" event<br>
fires, let myth run the channel change script then turn it off when the<br>
"recording finished" event fires. This has actually been working quite<br>
well and has the added bonus of not leaving the STB on all the time and<br>
potentially saving a few watts.<br>
<br>
The remaining problem then is with LiveTV. When MythTV starts a regular<br>
recording the events seem to occur in this order:<br>
<br>
1. Recording Pending (STB comes on)<br>
2. Change Channel<br>
3. Recording End (STB goes off)<br>
<br>
But with Live TV, if you change the channel from one to another the<br>
events occur in a different order:<br>
<br>
1. Recording End (STB goes off, was turned on when LiveTV first started)<br>
2. Change Channel<br>
3. Recording Pending (STB comes on)<br>
<br>
The result of this is that the backend tries to change the channel with<br>
the STB off. It would be nice if 2 and 3 were reversed for this purpose<br>
but I don't know if the devs would consider doing this. It would make it<br>
more consistent with the order of the events for recording:<br>
<br>
1. Recording Pending<br>
2. Change Channel<br>
3. Recording Started<br>
<br>
As a way around this I was thinking that I could make the channel change<br>
script a little smarter if only I knew if MythTV was currently in the<br>
LiveTV mode. Does anyone know if there is any way to get that<br>
information via Python or Perl bindings? Or anything else really?<br>
<br>
I was thinking that I could do a wget of<br>
<a href="http://127.0.0.1:6544/Status/GetStatusHTML" target="_blank">http://127.0.0.1:6544/Status/<u></u>GetStatusHTML</a> and parse the output, but i'm<br>
unsure if it will return something about "LiveTV" after the recorder has<br>
stopped while trying to change channels. I was really hoping someone<br>
here might have a "cleaner" solution.<br>
<br>
Thanks!<br>
</blockquote>
<br></div></div>
I was working on this problem a lot over the long weekend and I think I have a viable solution to this. Basically I connected the analog audio outputs from the STB to the line-in on the backend and wrote a script to check if a sample of the audio from the line in was "silent". I removed all my event driven stuff and changed my channel change script to check if the STB is on before it tries to tune a channel. As extra insurance I had the channel change script tune to the TV Guide channel (where there is always loud audio) first, then take the sample, then turn the STB on if needed. This whole process does not involve using the HD-PVR at all so it works around the issues I previously had with the driver seeming to become unresponsive.<br>
<br>
If anyone would have a similar use or need for the script I'd be happy to share it if requested!<div class=""><div class="h5"><br>
______________________________<u></u>_________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/<u></u>listinfo/mythtv-users</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">I'd be interested in trying it, although I've had fairly good luck with the other method, this one should be more reliable, and quicker.<br></div>
</div>