An idea: Delay standby when items queued for auto-processing

[MadMart]

When detectads rolled out chaserun mode I found recordings broke up, probably when two things were recording. I switched to traditional mode which works fine, even if two things record and something being watched, but the standard GUI is really slow.

More recently I've used the auto-processing "suspend during record" option to defer processing, so gui is responsive but I can get a backlog of processing. I haven't tried the cpu limit as yet, but would likely also end up with a backlog. As a result, I've been leaving the box on when I know there is stuff in the queue and also set the auto powerdown, so it turns off after 3 hours, which may be too long or not long enough depending on the queue.

I have searched the forum and not seen anything that will allow the box to keep running until it's completed the tasks in the queue - ie delaying standby. There was a brief mention in a thread on redring, but I don't think it does this, although it could be I'm missing something. The only other option seems to be to set a manual reminder event, but again the on-time required is variable, so could be too short or too long.

So my idea. Set one or more short manual reminder events (eg 5 mins, assuming auto-processing wakes up within 5 mins of boot) at times when the box isn't likely to be in use. Have the auto processing engine cancel the return to standby if there are jobs in the queue. Then issue a standby/powerdown once queue is emptied, the box only stays on for as long as needed that way. As an alternative, it could cancel the return to standby and rely on auto powerdown (3 hr), but that could still result in just under 3 hours more on time than perhaps needed, or may turn of before finished.

In terms of how, then to prevent the auto standby at end of reminder, or the auto powerdown (3hr idle) it appears that just an IR push is needed. A harmless key such as "sub" or "i" could be simulated IR package style, which will reset the idle timer and cancel the reminder standby and auto powerdown (if enabled).

A crude implementation could just press "sub" at the start of any lengthy task (decrypt, shrink, ads) and then rely on the 3 hour powerdown timer. Would be on for longer than needed, but would get through the queued tasks.

A smarter implementation would look to see if a remote key had been pushed (ie user present) since the last IR "sub" key nudge from auto-processing - ie check the idle timer and compare to elapsed time since last nudge - and set a flag for user present. Once queue processed (or end of permitted hours reached) and if no user present and box wakeup was due to reminder or record event, then the box can be returned to standby.

This would also allow an overrun on recording events to allow chase or traditional processing to complete before the box returns to standby.

If the auto-processing "permitted hours" are observed as they are now this will avoid prolonged operation when not desired (eg in the night if in bedroom), eg if waking up for OTA block with jobs in queue.

So is there an existing way, a better way, and if not does the above sound like it could work?

 

[MymsMan]

DetectAds (in the chaseget package) has code to bring the system out of standby when processing a recording in chaserun mode, that is the fairly simple part.
Chaseget uses the IR package to send a Power signal but Auto processing could potentially insert a Reminder into the schedule using real time scheduling.

The problem comes with safely putting the system back into standby after processing is complete,
There is no way the system can know if SWMBO or a child has sat down front of the TV and is happily watching what is currently playing without using the remote and who would be upset if the system suddenly turned off without warning (there is no known way to put a message onto the TV screen).
Many users have disabled auto power off and manually switch off when they have finished viewing and might unknowingly interrupt the queue processing.

 

[MadMart]

If the reminder wakes up on ch 200 then user present could be detected by channel <> 200 or the idle < time since IR nudge. And for a recording wake up without chaseget it would have no output. For DetectAds with chase, then the box would be forced to fully awake - so the same issue about when to turn off again? What happens right now at the end of recording and decoding? Does it stay on?

Could perhaps put volume to zero / mute, then any real user would use the remote, which could be detected by idle time. Not sure that helps if external audio used, not tried it, that output may be on regardless (which could be interesting if sound system left on when boxes force to awake for chase). Or maybe select the guide or media, again a user would reach for the remote to clear it.

Also, if the system enters the pre-standby phase (ie user pushes remote control power button) while tasks are queued and within permitted processing hours, then there's time to return to fully awake (either IR or real time sched) before the power is cut and so processing isn't interrupted.

The powerdown/standby is best left to the auto-processing engine so other actions are complete before going to sleep. For example, sweeper being used to move a movie after decode, ads and shrink complete.

 

[Black Hole]

The solution is simple: just leave it running 24/7 like I do.

 

[Trev]

But not everyone wants to use that 'solution' BH.
What happens if you switch off whilst say autodecrypt is running? I had a couple of crashes last night, but will start another tghraed on that when OI have got my head around what happened and when.

 

[Black Hole]

But not everyone wants to use that 'solution' BH.

It's a lot simpler than trying to get around it other ways. Pragmatism rules the day - it may not be ideal, but it is the "least worst". The downsides are occasional crashes, and energy consumption.

What happens if you switch off whilst say autodecrypt is running?

It tries again next time. It does not really matter if the system turns off while something is processing, the processes are robust and will simply have another go (although, regrettably, from the start rather than where left off, so a long MP3 extraction needs to be accommodated in one long session).

 

[Black Hole]

If we knew how to induce the delinquent half-awake state at will, processes that do not involve decryption could continue to completion in half-awake.

 

[af123]

This is an interesting idea and I think it's worth pursuing. It will be hard to get right though!

There is already an undocumented feature in the ir package which ignores power commands from the real remote control (and records when they happen). One problem I've experienced with using that is when a recording is being watched and child A, upon being called to the table for tea, presses power-off. The TV goes off but the Humax keeps playing the recording, making it harder to resume later.

In terms of how, then to prevent the auto standby at end of reminder, or the auto powerdown (3hr idle) it appears that just an IR push is needed.

Have you tested that at all? I know that any remote control press will reset the idle time reported in the web interface, but it seems to take more than that to reset the real internal timer. I did experiment with sending null control commands at one point but they didn't keep the box alive.

there is no known way to put a message onto the TV screen).

I wonder if a way could be found to update the internal standby timer. For those of us using auto powerdown, if we could set that to 5 minutes remaining then a message would be displayed..

 

[Black Hole]

One problem I've experienced with using that is when a recording is being watched and child A, upon being called to the table for tea, presses power-off. The TV goes off but the Humax keeps playing the recording, making it harder to resume later.

But if you can detect a recording is being played, you could inject a stop command instead.

 

[MymsMan]

If the reminder wakes up on ch 200 then user present could be detected by channel <> 200 or the idle < time since IR nudge. And for a recording wake up without chaseget it would have no output. For DetectAds with chase, then the box would be forced to fully awake - so the same issue about when to turn off again? What happens right now at the end of recording and decoding? Does it stay on?


Could perhaps put volume to zero / mute, then any real user would use the remote, which could be detected by idle time. Not sure that helps if external audio used, not tried it, that output may be on regardless (which could be interesting if sound system left on when boxes force to awake for chase). Or maybe select the guide or media, again a user would reach for the remote to clear it.

Also, if the system enters the pre-standby phase (ie user pushes remote control power button) while tasks are queued and within permitted processing hours, then there's time to return to fully awake (either IR or real time sched) before the power is cut and so processing isn't interrupted.

The powerdown/standby is best left to the auto-processing engine so other actions are complete before going to sleep. For example, sweeper being used to move a movie after decode, ads and shrink complete.

The rules that chaseget uses for switching the system back to standby are (from the wiki):

The DLNA server is not active in half-awake recording state so ChaseGet uses the IR package to force the system fully awake if needed. After the recording ChaseGet will now (chaseget version 0.1.1_1) attempt to turn power off when it it safe to do so but it is not easy to determine if the user has started to watch the TV in the mean time without pressing any buttons on the remote.

To reduce the risk of upsetting important family members when the box shuts down without warning (The Customised Firmware has no ability to put a 2 minute standby warning on screen like the Humax does) you can specify a time range in the ChaseGet Settings during which automatic return to standby won't operate.

You can also choose in the settings whether to Mute the sound when ChaseGet does wake the system from standby outside the peak time-range. This would prevent a sudden blast of sound if the system wakes up in the middle of the night for a scheduled recording and the TV has been left on or auto-switches on HDMI activity. A user un-muting the sound also indicates that someone is watching the TV and so ChaseGet would not then return the system to standby.

ChaseGet will return the system to StandBy if during scheduled checks which run every 20 minute all of the following are true.

• The system was awakened from Standby by ChaseGet
• The time is not within the exclusion time range
• The system isn't currently in standby
• No significant programs are running (including auto, detectads etc)- full list is in /mod/etc/chaseget.conf and can be extended if needed
• There are no active PuTTY / Telnet psuedo-terminals
• The system hasn't been been rebooted since wakeup
• No recording is being played (on set or via remote access)
• There is no active Reminder event
• No remote control buttons have been pressed since wakeup

If we knew how to induce the delinquent half-awake state at will, processes that do not involve decryption could continue to completion in half-awake.

Even more useful if we could work out how to activate the DLNA server in half-awake state to allow for decryption without fully waking up the system

 

[MadMart]

This is an interesting idea and I think it's worth pursuing. It will be hard to get right though!
...
Have you tested that at all? I know that any remote control press will reset the idle time reported in the web interface, but it seems to take more than that to reset the real internal timer. I did experiment with sending null control commands at one point but they didn't keep the box alive.

I believe it worked, there is a small chance another process or reminder kept it alive. I've just cleared all events (bar OTA block) and nothing to process, so will let you know in three hours... running 1.4 btw.

 

[MadMart]

Confirmed. With auto powerdown on,when the time indicated as idle in the webif reaches 3 hours, the box turns off. Using the webif remote to simulate a "sub" remote control key press resets idle to zero, extending the time until auto powerdown.

Turned box on at 21:21, sent "sub" via webif at 21.53, unit powered off at 00:53.

 

[marsha11]

ChaseGet will return the system to StandBy if during scheduled checks which run every 20 minute all of the following are true.

• The system was awakened from Standby by ChaseGet
• The time is not within the exclusion time range
• The system isn't currently in standby
• No significant programs are running (including auto, detectads etc)- full list is in /mod/etc/chaseget.conf and can be extended if needed
• There are no active PuTTY / Telnet psuedo-terminals
• The system hasn't been been rebooted since wakeup
• No recording is being played (on set or via remote access)
• There is no active Reminder event
• No remote control buttons have been pressed since wakeup

How does ChaseGet wake the system from Standby? I've got the exclusion time range set to between 19:00 and 00:30 but the system doesn't wake up.

 

[MymsMan]

Chaseget uses the IR package to send Power signals to the Humax

The Chaseget exclusion range is a period during which it does not put the system into standby, it doesn't cause the system to wake up

You can use a Reminder if you want the system to wake up for a specific period

 

[marsha11]

You can use a Reminder if you want the system to wake up for a specific period

To stream my recordings when I'm away from home I set up Timer On/Off times. If I forget, then setting a reminder can work if there is no clash with overlapping recordings. If there is a clash then I could end up with a failed recording if the two recordings and the reminder channel are on different muxes. I don't want to be changing the reminder channel each day to avoid clashes so I've been looking for an alternative method and thought Chaseget may be suitable.

I've tried using Chaseget in conjunction with a short reminder and short recording plus longer reminder to try and get Chaseget to start and prevent the box going back into Standby. Both tests failed to keep the box awake.

As I can edit the root cron jobs remotely using Webif when a rs scheduled reminder starts, can I schedule a Chaseget start from here and will it return the box to Standby at the end of the exclusion time period?

 

[MymsMan]

Chaseget will only bring the system out of standby if DetectAds is processing a recording in Chaserun mode and the system is in standby. There is no Start that can be scheduled.

You could possibly schedule a short recording to be ad detected to wake the the system up but this is probably overly complex.

The system does support Power on and off timers - these have caused problems for some users but you could give them a try.

 

[marsha11]

The system does support Power on and off timers - these have caused problems for some users but you could give them a try.

I do use these timers. My post was to find an alternative if I forget to set the timers before I leave home. I've realised that whichever method I use to keep the box awake I may still have a problem with overlapping recordings. I'll just have to keep a check on the scheduled recordings and use ir to change channel if required.

Thanks for your suggestion regarding using Chaserun mode.

 

[marsha11]

Using recordings in Chaserun mode instead of Reminders

Following MymsMan's advice in post #16 I'm now using a Chaserun mode recording instead of a reminder to keep my box awake while backing up my recordings with rsync. I used to set up a 5 hour overnight reminder to coincide with the rsync cron job but now I just set up a 5 minute recording which is later deleted by Sweeper. Adding 'rsync' to /mod/etc/chaseget.conf allows ChaseGet to keep the box awake as long as the backup is taking place.

I used to use DetectAds in traditional mode but now I use Chaserun mode for the above purpose. As I didn't want Chaserun mode for all recordings, I've added all the channels that I record from to the Exclude Channels list in DetectAds settings and choose another channel for the 'dummy' recording. If I require traditional DetectAds to run on normal recordings I set the Enable Auto DetectAds flag on the folder/recording.

I also use this method to enable queue processing for decryption and shrink prior to rsync backup. 'wget' is already in chaseget.conf but 'stripts' requires adding for the shrink process. I schedule a 15 minute recording for this to give enough time for queue processing to start. The box returns to standby within 20 minutes of decrypting and shrinking the recordings.

 

[Trev]

Wow, that sound hellish complex just to record TV.

 

[marsha11]

Wow, that sound hellish complex just to record TV.

It's not to record TV, it's to keep the box awake long enough to perform queue processing and rsync backups to my NAS. It's all automated and requires no maintenance. The dummy recordings are named as such and Sweeper deletes all recordings with 'dummy recording' in the filename.