View Entry Info: OpenViX 5.1.027 will not return to Deep Standby affter recording

Category:
Possible Bug
What ViX Image build number are you using?
Please provide your ViX Team image build number. Menu > Information > About > Build number > ENTER THIS NUMBER e.g. 4.2.028
5.1.027
Have you tried a flash WITHOUT settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
No
Have you tried a flash WITH settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
Yes
Attachments
Page 4 of 4 FirstFirst ... 234
Results 46 to 60 of 60
  1. #46
    Forum Supporter
    Donated Member
    adm's Avatar

    Join Date
    Sep 2014
    Location
    Southend on Sea, UK
    Posts
    731
    Thanks
    21
    Thanked 258 Times in 204 Posts
    Quote Originally Posted by bsod View Post
    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.
    Last edited by adm; 21-05-18 at 08:00.
    Extrend ET10K, 2 x satellite tuners 28.2 (UK Freesat channels), 2 x hybrid (UK Freeview channels)

  2. #47
    Member

    Join Date
    Sep 2014
    Location
    Australia
    Posts
    43
    Thanks
    1
    Thanked 2 Times in 2 Posts
    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

  3. #48
    Member

    Join Date
    Nov 2017
    Posts
    70
    Thanks
    8
    Thanked 7 Times in 6 Posts
    Quote Originally Posted by birdman View Post
    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?
    Kind regards,

    Mick

  4. #49
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    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.

  5. #50
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    Didn't drop to standby today, no references to "wakeup to standby detected" in debug log, still on 5.1.026.

  6. #51
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    Didn't drop to standby again today.

    Last night's closedown had.....

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

  7. #52
    ViX Beta Tester birdman's Avatar

    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    4,637
    Thanks
    97
    Thanked 978 Times in 784 Posts
    Quote Originally Posted by ccs View Post
    Last night's closedown had.....

    Code:
    <  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.
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  8. #53
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    Quote Originally Posted by birdman View Post
    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.

  9. #54
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    .. debug log

    Code:
    <    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:

  10. #55
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    Navigation.py:

    Code:
    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.

  11. #56
    ViX Beta Tester birdman's Avatar

    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    4,637
    Thanks
    97
    Thanked 978 Times in 784 Posts
    Quote Originally Posted by ccs View Post
    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".
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  12. #57
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    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.

  13. #58
    ViX Beta Tester birdman's Avatar

    Join Date
    Sep 2014
    Location
    Hitchin, UK
    Posts
    4,637
    Thanks
    97
    Thanked 978 Times in 784 Posts
    Quote Originally Posted by ccs View Post
    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
    MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD

  14. #59
    Forum Supporter
    Donated Member


    Join Date
    Sep 2014
    Posts
    2,065
    Thanks
    186
    Thanked 440 Times in 388 Posts
    Quote Originally Posted by birdman View Post
    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".

  15. #60
    Member

    Join Date
    Nov 2017
    Posts
    70
    Thanks
    8
    Thanked 7 Times in 6 Posts
    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.
    Kind regards,

    Mick

Page 4 of 4 FirstFirst ... 234

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.