Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! 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 £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[VU+ Ultimo4K] Recordings in progress...

An update.

(I think) I've worked out what config.timeshift.isRecording represents. It's whether the current timeshift buffer should be converted into a recording when the programme ends (an option you can set using the record button when timeshift is active). This is needed so that activities which would affect a recording (shutdown, changing tuner configs, etc.*) can warn if you try to use them when this is active - since it does not show as an actual recording timer.

So, I set off a "timeshift recording" whilst having a recording timer set to start and stop before the current programme ended and looked at what was happening (leaving the remote control alone...). This was done with stopwhilerecording set to True.


  • The timeshift recording buffer started to fill. config.timeshift.isRecording was set to True (by setting of the "timeshift recording": code in Screens/InfoBarGenerics.py at line 3190).
  • Then the recording started - at this point the timeshift buffer went away (and was not converted to any actual recording - I'm going to ignore that here too).
  • The recording stopped (and was OK). Timeshift started up again. config.timeshift.isRecording was set to True (by a recording ending: code in Components/Timeshift.py at line 1272, which is the setting causing this issue).
  • At the end of the programme timeshift stops! config.timeshift.isRecording is set to True again (because we're about to merge recordings - read on...: code in Components/Timeshift.py at line 632
  • The timeshift buffer is copied(moved) to a recording file.
  • A 5-min timer recording (a real one - it shows up in the timer list) of the channel that I was "timeshift recording" now appears!
  • After 5-mins, this stops abd timeshift starts running again.
  • There are now a few occurrences of config.timeshift.isRecording being set to True in quick succession.
  • At the end the 5-min recording has been merged with (appended to) the "timeshift recording".
  • config.timeshift.isRecording is then set to False (cleanup after merging: code in Components/Timeshift.py at line 1043

[* but not, interestingly, changing the channel, which does restart the timeshift buffer and hence remove the recording you think you are making. But I'm going to ignore that here...]


From what I can see config.timeshift.isRecording is never unset when timeshift is paused for a recording.
Consequently it doesn't need to be set when a recording ends.
So I reckon the solution to this problem is to remove line 1272 in Components/Timeshift.py.
 
@birdman - I think you have identified an issue that I have experienced occasionally. Sometimes, I go to bed with a timeshift recording in progress and I put the box in standby, assuming that my auto deep standby timer (30 mins) will put the box to deep sleep after the timeshift recording is finished. Quite often I find the box still running in the morning and the shutdown timer being blocked by "recording in progress" when there is actually none! I think it happens when I have an actual timer recording which may have finished shortly before I put the box in standby which is simultaneous with the timeshift.
 
I think it happens when I have an actual timer recording which may have finished shortly before I put the box in standby which is simultaneous with the timeshift.
So presumably you don't have the option to stop timeshift when recording set?
This issue should only affect those who do.
 
Can't check the setting right at the moment, but will respond later.


EDIT - I have the option to "stop timeshift when recording" set to NO
 
Last edited:

OpenViX Feeds Status

Back
Top