birdman
Moderator
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.
[* 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.
(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.