Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[VU+ Duo2] Possible bug in power timers

m1maj

Forum Supporter
Donated Member
Joined
Apr 5, 2013
Messages
47
Reaction score
0
Points
6
Location
Cambridge, UK
This is to report a long standing problem I've observed with the handling of power timers.

I have two power timers on my system:

1. At 02:00 every day, go to deep standby
2. At 08:00 on Fridays, wake to standby

(Of course the receiver switches on and off at other times, either manually or for recordings).

The observed symptom is that the first timer never works on Saturdays. I always find the receiver on in standby on Saturday mornings, and my network monitoring indicates that nothing happened at 02:00. It works every other day. I can only assume that the two timers are interfering with each other in some way.

This isn't a major problem, just a slight niggle. The problem has been around for a long time and is not specific to this software version.
 
I have two power timers on my system:

1. At 02:00 every day, go to deep standby
2. At 08:00 on Fridays, wake to standby
Do you have any "after event" set for timer 2?

Could you upload a copy of your pm_timers.xml file from /etc/enigma2?
 
(Might it be more useful if I did it on Friday?)
It might be more useful if you did it on Saturday - after the failed timer.



The observed symptom is that the first timer never works on Saturdays. I always find the receiver on in standby on Saturday mornings, and my network monitoring indicates that nothing happened at 02:00. It works every other day. I can only assume that the two timers are interfering with each other in some way.
Do you just leave the box running after the Friday 8am wake-up, or do you switch it off/on manually.
Just wondering whether you setting a timer to wake it up means that it won't run a timer to shut it down until you do it manually. Odd, but....
 
It might be more useful if you did it on Saturday - after the failed timer.

I could do both, I suppose.

Do you just leave the box running after the Friday 8am wake-up, or do you switch it off/on manually.
Just wondering whether you setting a timer to wake it up means that it won't run a timer to shut it down until you do it manually. Odd, but....

I normally just leave it running on Friday. The main purpose of turning it on to standby is to extract over the network some recordings made during the week. I might or might not switch it manually between "on" and "standby" in order to watch something, but I would not normally shut it down.
 
Interesting.
The failed Saturday deepstandby timer enters state 3. None of the others do.
 
I can see a possibility, but since I'm on holiday and away from any ability to test the theory it will have to remain as that for a week at least.

This is the theory.

You have two timers. When the Wakeup one runs at 08:00 on Friday the time gets set and both are checked. The DeepStandby one gets checked first and it sees the /tmp/was_powertimer_wakeup marker file (dropped in place by Navigation.py) and so it gets tagged with the wasPowerTimerWakeup setting. Since the box isn't shutdown manually it retains this tag until that timer next runs - at which point it does nothing (and, indeed, seems to end completely).

In the meantime a workaround would be to add an "after event" to your wakeup timer to shut down again after, say, 2 hours (or however long it takes the box to go through the things for which you are waking it up). Basically it need to be shut down once before the 02:00 auto shutdown runs, so that the aforementioned tag goes away.

The PowerTimer.py code probably needs to be changed to check that the current timer is wake-up type before checking for the dropped file.
 
This is the theory.
Having had more time to re-read the code and see what it does in various circumstances, I reckon that this is intentional. If you have woken the box up with a PowerTimer then another one won't shut it down.

In the meantime a workaround would be to add an "after event" to your wakeup timer to shut down again after, say, 2 hours (or however long it takes the box to go through the things for which you are waking it up). Basically it need to be shut down once before the 02:00 auto shutdown runs, so that the aforementioned tag goes away.
So that's not actually a workaround, but a requirement. Undocumented, but still a requirement.
 
Having had more time to re-read the code and see what it does in various circumstances, I reckon that this is intentional. If you have woken the box up with a PowerTimer then another one won't shut it down.

So that's not actually a workaround, but a requirement. Undocumented, but still a requirement.

Interesting thought, but in my case, it does shut down on Sunday. So after a power timer wakeup, it only ignores the next timed shutdown, not all future ones. I suppose that if that's the spec, so be it, but it seems very strange to me!

It must take a fair bit of effort to implement this behaviour. I wonder what real life scenario it is intended to deal with. It doesn't seem to make a lot of sense in my application.

In practice, having the receiver remain on on Saturdays isn't a major problem, and sometimes useful. I'll probably just live with it.
 
In practice, having the receiver remain on on Saturdays isn't a major problem, and sometimes useful. I'll probably just live with it.
Why not just add an "after action" to shut it down later?
 
Why not just add an "after action" to shut it down later?

Yes, I could do that, though that then means that my shutdown time is now stored in two places.

But as I said at the very beginning, in practice this is only a minor niggle for me. I reported it because I assumed it was a bug and thought it would be public spirited to do so.

If you say the code is working as designed then fine. It does cause me to wonder why it is designed as it is, who decided what the specification should be, and how I as a user can find out what the specification actually is. I don't find it at all obvious that two independent timers should interact in this way. I've also noticed that if I happen to do a software update on Friday, then it does shut down on Saturday. I can understand that from the point of view of what the code does, but I can't really see why anybody would actually want it to behave like that.

Thanks again for your insights - I'll work around the problem if I decide I need to.
 
It does cause me to wonder why it is designed as it is
I think that the logic is that since the box was woken up by a PowerTimer then you want it to be on, so a separate timer won't shut it down since, if you do want it to shut down, you can always make the wake-up timer do that.

who decided what the specification should be
No one in particular - just whomsoever wrote the original code.

and how I as a user can find out what the specification actually is.
There's nothing written down. At least not anything that I've ever found or heard of; apart from the source code.
 

OpenViX Feeds Status

Back
Top