[Mut@nt] HD51 OpenViX 5.1.027 will not return to Deep Standby affter recording

[Mickkie]

I had a problem with going to deep standby ages ago, it was a timeshift setting, although I don't use timeshift.

Maybe this will help.....?

https://www.world-of-satellite.com/...er-a-recording&p=382915&viewfull=1#post382915

Thanks ccs,

I use Timeshift, but my "Stop timeshift while recording?" has always been set to no.

 

[birdman]

I've updated to 5.1.027, run a test with recordings on the same and on different channel/MUX. The box will not return to Deep Standby or Standby no matter what. It's just left running and because I have Timeshift on, the disk keeps spinning no end. So, this can't be right.

Not all boxes set the flags to say why they woke up. Those that don't don't know that they woke up for a recording.
For the spinning disk, you could always set a Powertimer to shut the box down after <n> mins of inactivity (no key press...). Although if you use the box to watch live TV (I only have terrestrial TV, so just use the TV for that) that could also be annoying.

 

[birdman]

If the box notices that it has been auto-awoken for a recording. It writes this to the debug log:

[Navigation] RECTIMER: wakeup to standby detected.

so conversely if that is not there it won't go to Standby while recoding and won't shutdown at the end.

 

[birdman]

Not all boxes set the flags to say why they woke up. Those that don't don't know that they woke up for a recording.

Actually this might have changed (or I might have always been looking at the wrong thing).
The test seems to be, is the next recording one with "at end" == Auto, and does it start in the next 6 mins.

So if the box wakes up early (which is what usually happens on my MBtwin) it won't go to Standby.

 

[bsod]

Hi all,

this may be completely off track, but I have been experiencing similar issues for awhile now on my DUO2. The DUO2 has 2 dual tuner DVB-T2 tuners, no satellite. I cant say for sure when it started happening unfortunately, but it does mirror what others have posted here. In pursuing another issue I was having with the WIFI on the DUO2 with a friend who is more Enigma2 knowledgeable than myself, we discovers that my current installed image was missing certain menus, the ones most obvious being under Setup/Network. My image only had Devices and Utilities submenus, and the Utilities sub menu was empty. Given this, and now not knowing how "damaged" the current image had become we decided to do a settings/plugins backup and then do a fresh USB 5.1.027 install. After the fresh install all the menu options were there, however once I restored my settings, they disappeared again, so I re-flashed and have manually set all of my settings and plugins. Since doing this the DUO2 has so far behaved with regards to deep shutdowns after recordings have finished, but manual recordings and via auto-timers. The After Event setting is set to default, no implied shutdowns. Prior to the USB flash update of 5.1.027 I had been doing online updates. I wonder if any of the others having issues have tried a fresh USB flash or if they are missing menu options.

I am still experiencing odd WIFI connection issues, but I will start a seperate thread for that.

Regards,

Craig

 

[adm]

Hi all,

discovers that my current installed image was missing certain menus, the ones most obvious being under Setup/Network. My image only had Devices and Utilities submenus, and the Utilities sub menu was empty.

One gotcha, which catches a few people out. You have to select "Expert" mode in Menu -> Setup -> System Customise -> Setup mode = Expert
Any other setting and you lose some of the menu settings - and not only in the Network section. From memory, some of AV settings go missing and probably a few more elsewhere.

Possibly having a setting backup with the Setup mode = simple or intermedite results in a the menus items being hidden after a image download followed by a restore of settings. You first need a setting backup with the mode set to Expert.

 

[bsod]

Hi adm,

Give the man a cigar. Just checked the settings file from a backup and you were right, it was set to simple. It's odd because one of the first things I do is set it to expert, so I am not sure how it reverted. I suppose the obvious explanation is that I did not on this occasion. Must be old age.

Sorry to all for the now irrelevant post. Admins, feel free to remove it.

Regards,

Craig

 

[Mickkie]

If the box notices that it has been auto-awoken for a recording. It writes this to the debug log:

so conversely if that is not there it won't go to Standby while recoding and won't shutdown at the end.

Thanks birdman,

I captured some logs with OpenViX 5.1.026 and 5.1.027. The former shows this in the log:

< 31.572> [TimerSanityCheck] conflict not found!
< 31.572> [Timer] Record RecordTimerEntry(name=Weather for the Week Ahead, begin=Tue May 2
9 00:29:00 2018, serviceref=1:0:19:4484:4084:233A:EEEE0000:0:0:0:, justplay=0, isAutoTimer=1)
< 31.575> [Timer] Record RecordTimerEntry(name=Daily Politics, begin=Mon May 21 11:59:00 2
018, serviceref=1:0:19:4440:4084:233A:EEEE0000:0:0:0:, justplay=0, isAutoTimer=1)
< 31.577> [Navigation] RECTIMER: wakeup to standby detected.
< 31.578> [ABM-main][AutoBouquetsMakerautostart] AutoStart Enabled
< 31.579> [ABM-main][AutoAutoBouquetsMakerTimer] Schedule Disabled at Mon 21 May 2018 15:12:10 BST
< 31.579> [CrossEPG_Auto] AutoStart Enabled
< 31.581> [CrossEPG_Auto] Schedule Disabled at Mon 21 May 2018 15:12:10 BST
< 31.582> [EPGImport] autostart (0) occured at 1526911930.79
< 31.582> [EPGImport] WakeUpTime now set to -1 (now=1526911930)
[snip ...]

< 37.585> [eDVBServicePlay] timeshift
< 37.585> [eDVBServicePlay] timeshift
< 37.586> [eDVBServicePlay] timeshift
< 41.128> [Task] job Components.Task.Job name=SoftcamCheck #tasks=1 completed with [] in None
< 42.552> [eEPGCache] nownext finished(1526912003)
< 46.577> [Navigation] TIMER: now entering standby
< 46.589> [Standby] enter standby
< 46.600> [eFilePushThreadRecorder] stopping thread.
< 46.601> [eDVBRecordFileThread] waiting for aio to complete
< 46.601> [eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
< 46.601> [eDVBRecordFileThread] 1: 23
< 46.604> [eFilePushThreadRecorder] THREAD STOP

However, the 5.1.027 log does not show any "TIMER:" entries and consequently does not enter into Deep Standby after the recording. It also does not enter into plain Standby during the recording. So it seems to me something was changed between the two OpenViX images to cause this. Is there anything more I should post to help decipher what may be causing this problem?

 

[ccs]

Well, my ET10k hasn't dropped back to standby for the 1st recording of the day for 4 days now.
It used to nearly always work as expected.

I'm still on 5.1.026, I've switched on debug logs and I'll see what happens next time.

 

[ccs]

Didn't drop to standby today, no references to "wakeup to standby detected" in debug log, still on 5.1.026.

 

[ccs]

Didn't drop to standby again today.

Last night's closedown had.....

<  9956.868> set wakeup time to 2018/05/24 18:20
<  9956.868> recordTimerWakeupAuto True

 

[birdman]

Last night's closedown had.....

<  9956.868> set wakeup time to 2018/05/24 18:20
<  9956.868> recordTimerWakeupAuto True

That's usual. It's setting a wake-up timer (on the front panel) to wakeup the box a few minutes before the next timer is due to start.
The problem seems to be around when tat timer gets activated.

 

[ccs]

The problem seems to be around when the timer gets activated.

I tried switching on the et10k 20 minutes before a scheduled timer, and then switched it back to deep standby again.

It woke at 17:36:08 (pc time) and went to standby soon after, and the recording started at 17:40:00.

 

[ccs]

….. debug log

<    51.680> [Navigation] RECTIMER: wakeup to standby detected.
<    53.106> [Navigation] playing 1:0:19:4484:4089:233A:EEEE0000:0:0:0:
<    66.681> [Navigation] TIMER: now entering standby
<   209.109> [Navigation] recording service: 1:0:1:104F:104F:233A:EEEE0000:0:0:0:

 

[ccs]

Navigation.py:

59 	if self.__nextRecordTimerAfterEventActionAuto and abs(self.RecordTimer.getNextRecordingTime() - now) <= 360: 
60 	print '[Navigation] RECTIMER: wakeup to standby detected.'

I'll take some timings next time it doesn't work.

 

[birdman]

I tried switching on the et10k 20 minutes before a scheduled timer, and then switched it back to deep standby again.

It woke at 17:36:08 (pc time) and went to standby soon after, and the recording started at 17:40:00.

With <20 mins to go to start a recording it will wake up at ~ the correct time even teh fp clock is out by a bit.

My MBtwin rarely recorded in Standby, as it's FP clock ran fast (much better than running slow...) so it often woke up ~30 mins before a recording. At that point the box reckoned it wasn't waking up for a recording.

It would be interesting to know what time (i.e. how far in advance) your box is waking up for recordings which don't get run in Standby, but "should".

 

[ccs]

After 20 hours in deep standby, today's timer woke up 11 seconds sooner than yesterdays, and didn't go back to standby.

Woke at 17:53:57 (pc time when boot started), and the timer began at 17:58:00.

 

[birdman]

Woke at 17:53:57 (pc time when boot started), and the timer began at 17:58:00.

The code has a 6-minute leeway, so that should have been OK.
The only others things that would disable this (that I can see) are:

• the next record timer was not set to "after event" == auto.
• the system clock was not yet set when enigma2 started

 

[ccs]

The code has a 6-minute leeway, so that should have been OK.
The only others things that would disable this (that I can see) are:

• the next record timer was not set to "after event" == auto.
• the system clock was not yet set when enigma2 started

The timer today happened to have "after event" set to "auto", (not sure why, as I always default autotimers to "deep standby").

Yesterdays (it runs as first timer of the day, every day, Monday-Saturday), the one that "used to work most of the time", is always set to "do nothing".

 

[Mickkie]

I re-updated to 5.1.027, but instead of flashing a complete image and restoring settings, I used the Software Update in situ. Following this the Mut@nt appears to behave correctly, i.e. it wakes up from Deep Standby and once the recording is completed, it goes back into Deep Standby. So, something may have changed in the overall 027 image that causes this?

If from what you write the system clock is important, should I have this set up via NTP, rather than via the transponder signal? Perhaps it will pick up a time from NTP before the transponder tunes in and this may make a difference.