[ViX_Misc] Unable to go into deep standby after a recording.

[birdman]

BTW: have you looked at your timers.xml file in /etc/enigma2 to see whether there is anything odd in it?

 

[ccs]

But both of those logs shows keys being pressed just before shutdown. I presume that's just to force the shutdown (as the default for that prompt is False).

Yes, I always need to confirm shutdown.

I had deleted autotimers.xml to reduce the log file a bit.

Right, I've tried again with a reflash of 3.2.021.

Image flash, tuners configured, ABM, debug on, nothing else, and then tried the same recording procedure as in #39.

It worked fine twice (as I've seen before without a settings restore) but no debug logs were created . By then I'd set up wired ethernet and Samba.

So I tried again with these still configured, and the recording sequence worked fine again, and a debug log was created .

I've also attached a file which compares the "raw" no settings restore setup, and my current "non working" settings.

The only plugin I use is a usb wireless driver RTL8192CU (I've tried disconnecting (unplugging) this before, without success.)

 

[ccs]

The only plugin I use is a usb wireless driver RTL8192CU (I've tried disconnecting (unplugging) this before, without success.)

Deleting this plugin made no difference.

 

[birdman]

Image flash, tuners configured, ABM, debug on, nothing else, and then tried the same recording procedure as in #39.

It worked fine twice (as I've seen before without a settings restore) but no debug logs were created . By then I'd set up wired ethernet and Samba.

That "nothing else" may be a problem for the test. You only had one recording timer, and by the time the box shutdown that was completed - so there were no timers at all to conflict.

 

[ccs]

That "nothing else" may be a problem for the test. You only had one recording timer, and by the time the box shutdown that was completed - so there were no timers at all to conflict.

But that was the reason for the test, to confirm that it works with a no settings restore,
but the exact same test doesn't work with my normal setup.
When it goes wrong, there are no timers due for 6 hours or more, so something else is going wrong.
In the recent weeks I've recreated all timers and settings from scratch, but it still goes wrong.

 

[ccs]

BTW: have you looked at your timers.xml file in /etc/enigma2 to see whether there is anything odd in it?

I had tried this before, and have just checked again, if I delete all autotimers and all timers, the problem still persists with my normal settings.

 

[birdman]

I had tried this before, and have just checked again, if I delete all autotimers and all timers, the problem still persists with my normal settings.

Ah - that's new information.
So there's no point looking at what timers you actually have.
If you can wait ~a day I'll write some code to (hopefully) allow you to dump out to the debug log why it is popping up that message about "Recordings are in progress or coming up".

Mind you - whilst looking at how to print out info I do see one possibility.
getNextRecordingTime() (in RecordTimer.py) has this piece of code:

                if config.timeshift.isRecording.value:
                        if 0 < nextrectime < faketime:
                                return nextrectime 
                        else:
                                return faketime

so if config.timeshift.isRecording.value were true then this would return faketime - which is now+5mins.

But that doesn't get saved to the /etc/enigma2/settings file.

 

[birdman]

OK. I've added some code to Screens/Standby.py to print out some information if you force a shutdown when the "Recordings are in progress or coming up" message shows.

You can find it here (along with the 021 original, and the differences (patch) between them.

http://birdman.dynalias.org/OpenVix/debug/CCS/

To install it, login to the box and:

cd /usr/lib/enigma2/python/Screens
cp -p Standby.pyo Standby.pyo-021
cp <path-to-new>/Standby.py Standby.py

then restart the GUI. This should rebuild a new Standby.pyo.

Then run the test when you have timers in place such that you get the message, and do get it to shutdown.
You'll find the information tagged with CCS: in the debug log.

To go back to the standard Standby code once the test is complete, just:

cd /usr/lib/enigma2/python/Screens
mv Standby.pyo-021 Standby.pyo

 

[ccs]

Thanks for your help and support, it really is much appreciated.

I've produced a log, and it looks like the time of the next recording is about "now", , when the next scheduled recording is 18:25.

I've got timeshift switched off, at least I think I have.

"Automatically start timeshift after" is set to disabled, but doesn't show up in the settings I posted earlier.

The timeshift folder is /media/hdd/timeshift/ and is always empty, and the folder timestamp is months old.

 

[birdman]

Thanks for your help and support, it really is much appreciated.

I've always enjoyed debugging...I like to see things working properly.

I've produced a log, and it looks like the time of the next recording is about "now", , when the next scheduled recording is 18:25.

It's set to now + 300s...and that is because of this:

CCS: config.timeshift.isRecording.value True

see code snippet in #47.

So, the issue is now simplified, in that we know what to look for. Something is setting this, so we "just" need to work and what, why and how.

 

[Joe_90]

The log shows the next recording was due at 11.02. You interrupted a running recording of Neighbourhood Blues after three minutes, so perhaps it was trying to continue it?
The timeline is quite confusing - the schedules for BBC1 show Neighbourhood Blues starting at 11.30 this morning in the Yorkshire/Lincs region, yet your EPG shows 10.50 Can you clarify this?


ps - your refresh rate is set to 60Hz - should be 50Hz if you watch UK TV mostly. Only 60Hz or multi if you watch mostly US material shot at 30fps.

 

[ccs]

The log shows the next recording was due at 11.02. You interrupted a running recording of Neighbourhood Blues after three minutes, so perhaps it was trying to continue it?
The timeline is quite confusing - the schedules for BBC1 show Neighbourhood Blues starting at 11.30 this morning in the Yorkshire/Lincs region, yet your EPG shows 10.50 Can you clarify this?


ps - your refresh rate is set to 60Hz - should be 50Hz if you watch UK TV mostly. Only 60Hz or multi if you watch mostly US material shot at 30fps.

I just grab a programme from the epg which hasn't yet started, and change the start and stop times to suit.

In the log, the recording was set from 10:50 to 10:55, and wasn't interrupted.

Thanks for the refresh rate tip, I'm sure the tv manual refers only to 60hz, buy maybe that's not the point?

 

[Joe_90]

I just grab a programme from the epg which hasn't yet started, and change the start and stop times to suit.

In the log, the recording was set from 10:50 to 10:55, and wasn't interrupted.

Thanks for the refresh rate tip, I'm sure the tv manual refers only to 60hz, buy maybe that's not the point?

Ok - I see what you did, but this is not a normal use case, though. The recording process watches for the programme start/stop events in the EIT stream and puts the markers in the timeline you see when you play the recording back. I don't know if manually changing the settings as you did would affect the shutdown process (I would think not but you never know). I know your box is not the same as mine or birdman's (MB Twin) but it does share similar quirks as regards shutdown behaviour. I have found the the OpenATV image works very well on my MB Twin, but I have gone back to the latest 021 OpenViX release image for now to test the startup behaviour.

As regards the 60Hz setting - the TV will adapt automatically to any refresh rate supplied, so it should work with 50i or 50p or 60i or 60p and may also support 24p from Blu-ray players etc. The issue here is that the native frame rate of UK and European TV is 25 frames per second. This is transmitted as 50 interlaced fields and then sent to the TV as either interlaced or progressive depending on the capabilities of the box. You should ideally match the box frame rate to the source material. If you output at 60Hz using 50Hz material the box has to insert duplicate frames when constructing the output. This will lead to judder on fast-moving images such as panning shots.

 

[ccs]

.... the shutdown issue happens all the time with normal timers, so I doubt (hope) my 5 minute timers will mask the root cause of the problem.

It's bad enough waiting 15 minutes for a test to complete, 40 minutes plus would drive me mad (madder?).

 

[Joe_90]

I reverted back to the OpenViX 021 image on my MB Twin. Clean flash, no restores. Set up some autotimers for recording soaps etc. Left in deep standby. Booted up on timer at 13.10 to record Home & Away at 13.15 (I know ) and Neighbours but it has stayed in normal mode (not standby) and thus has not shut down afterwards. So, nothing changed in OpenViX image

Back to OpenATV image for me, I'm afraid.

 

[ccs]

I've tried switching on timeshift (Automatically start timeshift after: 1 minute) and it made no difference......

(As an aside, I wonder why I always get "[Dish] tuning failed" in the log when I've only got freeview terrestrial tuners?)

 

[birdman]

Ok - I see what you did, but this is not a normal use case, though.

As far as the test goes it is.
It's not the end of a programme, but it is the end of the requested recording: waiting for the programme and would just waste time.

I know your box is not the same as mine or birdman's (MB Twin) but it does share similar quirks as regards shutdown behaviour.

My MBTWIn only has start-up quirks, and I can't see how anything can work around them. However, since this just means it wakes up early and might stay in "awake" mode rather than standby when it does I can live with it. OpenATV has its own failings on that count for the MBTwin (looking at the code).

We do now know what the cause of the strange shutdown is (see #50) and can now work on why that variable is being set.

As regards the 60Hz setting - the TV will adapt automatically to any refresh rate supplied, so it should work with 50i or 50p or 60i or 60p and may also support 24p from Blu-ray players etc.

I did have an issue on my MBTwin using "multi" when playing back a downloaded recording and pausing - on restarting the screen lost the minor size and placement I need to use (having never found an option on my Sony TV to totally switch off overscan).

 

[birdman]

If you're still in the game for a fix...

I've found all of the places in the enigma2 code that set config.timeshift.isRecording = True. That's 4 files.
I've added a call to traceback.print_stack() at each spot (and the one which should be initializing it, which prints what it gets set to) so that we can find out which one is used, and the call sequence that took it there.

So, if you look at:

 http://birdman.dynalias.org/OpenVix/debug/CCS/config.timeshift.isRecording/

you'll find edited versions of the 4 files that have changed (in Components, Screens and Tools)

There are also two scripts - one to put them into place (and backup the current *.pyo file) and another to remove them (and re-instate the original *.pyo files). Also you'll find a tar.gz of all of these (in the directory itself).

So, if you download the tar.gz file onto you box, unpack it (tar xvf ...tar.gz), cd to the created config.timeshift.isRecording directory and run ./add_debug_files.sh the 4 debug files will be copied into place. Then restart the GUI and run the test. You should find some CCS: tagged tracebacks in the debug log.
To remove the trace code just cd back to the config.timeshift.isRecording directory and run ./remove_debug_files.sh.

 

[ccs]

If you're still in the game for a fix...

I certainly am, if I can't get time tonight it'll have to be later tomorrow.

Again, many thanks.

 

[twol]

If you're still in the game for a fix...

I've found all of the places in the enigma2 code that set config.timeshift.isRecording = True. That's 4 files.
I've added a call to traceback.print_stack() at each spot (and the one which should be initializing it, which prints what it gets set to) so that we can find out which one is used, and the call sequence that took it there.

So, if you look at:

 http://birdman.dynalias.org/OpenVix/debug/CCS/config.timeshift.isRecording/

you'll find edited versions of the 4 files that have changed (in Components, Screens and Tools)

There are also two scripts - one to put them into place (and backup the current *.pyo file) and another to remove them (and re-instate the original *.pyo files). Also you'll find a tar.gz of all of these (in the directory itself).

So, if you download the tar.gz file onto you box, unpack it (tar xvf ...tar.gz), cd to the created config.timeshift.isRecording directory and run ./add_debug_files.sh the 4 debug files will be copied into place. Then restart the GUI and run the test. You should find some CCS: tagged tracebacks in the debug log.
To remove the trace code just cd back to the config.timeshift.isRecording directory and run ./remove_debug_files.sh.

Well if OpenATV works then I guess if I was a betting man it's in Components/Timeshift.py because the others are basically the same for both ATV/ViX, and there are only (as far as I can see ) 1 point where there is a differences between the 2 in this module . ... In ViX there is a double conditional check at around line 575 and in ATV a single conditional check.