[mythtv-users] Methods for waking a STB from standby w/IR only

[Tom Lichti]

On Fri, May 24, 2013 at 1:21 PM, Erik Sejr <esejr at wildroseinternet.ca>wrote:

> On 2013-05-17 21:20, Erik Sejr wrote:
>
>> Ever since I moved to Ottawa I've been fighting a battle with Rogers'
>> crappy STB, specifically a Cisco (SA) Explorer 8642. This thing turns
>> its self off after 7 or 8 hours of inactivity (I don't know the exact
>> number) but even worse, Rogers does frequent late night firmware updates
>> which always cause the device to reboot and come up powered off.
>>
>> The result, black recordings with no means of getting feedback about the
>> state of the STB as firewire does not work and there is no discrete
>> power ON IR command, only a toggle.
>>
>> For a while I tried a modified version of ingenious script on the wiki
>> which dd's a few seconds from the recorder, splits it into frames with
>> ffmpeg, converts those to "ascii" then checks to see if they are
>> "black". Unfortunately, while I was able to modify this script to work
>> with the HD-PVR it seems that the act of using dd to copy data right out
>> of /dev/video0 somehow causes the hd-pvr and/or the driver to become
>> unstable. The only fix I found was to rmmod the driver, reboot the
>> hdpvr, and then reload reload the driver.
>>
>> I gave up on the above method and tried to use the event bindings in
>> mythtv instead - turn the power on when the "recording pending" event
>> fires, let myth run the channel change script then turn it off when the
>> "recording finished" event fires. This has actually been working quite
>> well and has the added bonus of not leaving the STB on all the time and
>> potentially saving a few watts.
>>
>> The remaining problem then is with LiveTV. When MythTV starts a regular
>> recording the events seem to occur in this order:
>>
>> 1. Recording Pending (STB comes on)
>> 2. Change Channel
>> 3. Recording End (STB goes off)
>>
>> But with Live TV, if you change the channel from one to another the
>> events occur in a different order:
>>
>> 1. Recording End (STB goes off, was turned on when LiveTV first started)
>> 2. Change Channel
>> 3. Recording Pending (STB comes on)
>>
>> The result of this is that the backend tries to change the channel with
>> the STB off. It would be nice if 2 and 3 were reversed for this purpose
>> but I don't know if the devs would consider doing this. It would make it
>> more consistent with the order of the events for recording:
>>
>> 1. Recording Pending
>> 2. Change Channel
>> 3. Recording Started
>>
>> As a way around this I was thinking that I could make the channel change
>> script a little smarter if only I knew if MythTV was currently in the
>> LiveTV mode. Does anyone know if there is any way to get that
>> information via Python or Perl bindings? Or anything else really?
>>
>> I was thinking that I could do a wget of
>> http://127.0.0.1:6544/Status/**GetStatusHTML<http://127.0.0.1:6544/Status/GetStatusHTML>and parse the output, but i'm
>> unsure if it will return something about "LiveTV" after the recorder has
>> stopped while trying to change channels. I was really hoping someone
>> here might have a "cleaner" solution.
>>
>> Thanks!
>>
>
> 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.
>
> If anyone would have a similar use or need for the script I'd be happy to
> share it if requested!
>
> ______________________________**_________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130524/b684f910/attachment.html>