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

[Erik Sejr]

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 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!