[mythtv-users] Stop / Start Athcool just Befor / After a Recording

[Raphael Pooser]

f-myth-users at media.mit.edu wrote:

>    Date: Wed, 23 Nov 2005 12:33:22 -0500
>    From: Erik Karlin <e_karlin at yahoo.com>
>
>    you could just hijack the channel change "script" functionality and
>    create a user job when the recording completes. The problem of
>    back-to-back recordings is still possible. maybe some clever file
>    locking scheme between a channel change (start) and user job (end) could
>    do the trick.
>
>[There's nothing out there that looks at CPU utilization and leaves
>low-power mode if the CPU suddenly looks busy?  Or is the problem
>latency?  Laptops do this kind of CPU cycling all the time...  Or
>is it that the CPU never looks busy, but recordings are messed up
>even so, if done in powersave mode?]
>
>Here's a totally gross idea, but it might work, and could be done with
>a tiny shell script.  Assume we start from the powersave state.  The
>script loops, once per second, checking the mod-date of the recordings
>directory itself.  If it changes, immediately go to non-powersave state.
>
>Once in that state, check every so often (once a minute?) to see if
>any file in the recordings dir has been modified.  (You can't just
>check the mod-date of the dir itself, as in the previous paragraph,
>because once the file has been created, the mod-date of the dir itself
>won't change.)  If nothing's been modified in the last minute, assume
>we're done for the moment and go back into powersaving.  This check is
>probably cheap (since the dir info is presumably cached in RAM), but
>it still may not be as cheap as checking just the dir-mod date itself,
>which is why I mention using the dir-mod check in the fast loop (1 Hz)
>and the slightly-slower check in the slow loop (1/60 Hz).
>
>You could script this pretty trivially just using things like "find"
>and asking it to find files newer than a reference file (which you
>touch upon entering each of the two states and which had better not
>be in the recordings dir itself... :)
>
>This also assumes you can afford to be in powersave mode for the first
>second of any given recording.  [If you can't, you could always just
>enter fast mode for hh:mm:59..hh:mm+1:01 (two seconds) every minute---
>since recordings presumably always start on a minute boundary---and
>then run the fall-back-to-powersave check during that.  Might cause
>your fan to whoosh in one-minute cycles, though...]  This scheme does,
>at least, provide some hysteresis, so you won't leave the fast-CPU
>state until you're really sure you're done recording.  And if anything
>else is modifying stuff there (like transcoding maybe?), you'll stay
>in fast-mode until it's done.
>
>It would definitely be better if there were hooks for MythTV actions,
>though, since using an event-driven style to control this would be
>much more reliable and less of a kluge than the polling method above.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>mythtv-users mailing list
>mythtv-users at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>  
>
The way I see it, it would make sense to monitor the output of 
mythbackend.  Mythbackend outputs to stdout and you can redirect that to 
your script.  Whenever myth sends a line like "switching from none to 
watching prerecorded", you set the condition in an IF and execute 
"athcool off" or sudo athcool off or whatever.  Just set up a while loop 
in the script that checks the output of myth.  once your leave the 
recording it's going to say something like "switching from watching 
prerecorded to none".  you can test for that and set athcool on.
Raphael