Grumpy_Geoff wrote: ↑Sat Mar 16, 2019 15:39You have USB Tuner D set as priority allocation - whereas I have auto
Code: Select all
[
"config.usage.recording_frontend_priority",
"0"
],
Code: Select all
try:
config.usage.frontend_priority = ConfigSelection(default="0", choices=nims)
except:
config.usage.frontend_priority = ConfigSelection(default="-1", choices=nims)
Grumpy_Geoff wrote: ↑Sat Mar 16, 2019 15:39
A couple of your settings that are different to mine that may impact this (but I'm just guessing) -
You don't have timeshift enabled - whereas I have it as the default 10 seconds
You appear to have HDMI as the startup service
You have USB Tuner D set as priority allocation - whereas I have auto
Thanks Grumpy GeoffGrumpy_Geoff wrote: ↑Sat Mar 16, 2019 15:39
A couple of your settings that are different to mine that may impact this (but I'm just guessing) -
You don't have timeshift enabled - whereas I have it as the default 10 seconds
You appear to have HDMI as the startup service
You have USB Tuner D set as priority allocation - whereas I have auto
No, it is possible to set a fixed startup service regardless of the one that was active when you shut down.
I see. thank you. I had read posts elsewhere about problems with timers related to the default service being HDMI
Even if this isn't the trigger, these are the sorts of things we need to know when we ask you what is unique about the way you use the T4. Anything that you do that might deviate from the norm might be a trigger.
(unless you are Grumpy_Geoff who seems to maintain a profile on everyone *g*)Definitely getting somewhere.geoffree wrote: ↑Fri Mar 15, 2019 19:55Thanks MrQuade.
I was aware of time shifting being a possible reason for all of this so I had gone into the settings and stopped anything that looked like it might be 'encouraging' the machine to do time shifting in the background as the error message that pops on attempted shutdown suggests.
I know very little about time shifting, never use it, so don't understand the settings much.
The stop timeshifting during recordings looked like the right thing to do, I guess... Should I turn it on again?
The issue appeared straight after the update attempts. First time: restoring settings from backup as advised by postings on this forum - the issue appeared then. I then did a 2nd attempt - a clean install, hoping that might clear the problem - I did not restore settings backup, I made no adjustments to default settings but the issue persisted. I have tinkered with the settings since then,, as you can see, but to no avail.
I remember trying all of this during T3 testing a long time ago - once again to no avail;.
Time shifting settings don't appear to affect the behaviour of this issue
gb
geoffree wrote: ↑Sat Mar 16, 2019 17:31But 'stop timeshifting while recording' was ON in my original settings (default is off)
Just tested this back and forward on / off / on / off etc a number of times rebooting as I went
Result: when it is set to ON, it triggers the error message I mentioned . OFF and all is well , U4 shuts down as it should
Interested to know whether it would that for your machines,
I think he may know where I liveMrQuade wrote: ↑Sat Mar 16, 2019 17:04Even if this isn't the trigger, these are the sorts of things we need to know when we ask you what is unique about the way you use the T4. Anything that you do that might deviate from the norm might be a trigger.
You may have mentored it in a thread at one point in the past, but most of us find it hard to track every users particular settings
Glad I spotted that one thengeoffree wrote: ↑Sat Mar 16, 2019 17:31But 'stop timeshifting while recording' was ON in my original settings (default is off)
Just tested this back and forward on / off / on / off etc a number of times rebooting as I went
Result: when it is set to ON, it triggers the error message I mentioned . OFF and all is well , U4 shuts down as it should
Interested to know whether it would that for your machines,
. I didn't think it was related, more of a curiosity, but it shows that you never know within the labyrinth of code constitutes power states and timeshift.MrQuade wrote: ↑Sat Mar 16, 2019 17:44Glad I spotted that one thengeoffree wrote: ↑Sat Mar 16, 2019 17:31But 'stop timeshifting while recording' was ON in my original settings (default is off)
Just tested this back and forward on / off / on / off etc a number of times rebooting as I went
Result: when it is set to ON, it triggers the error message I mentioned . OFF and all is well , U4 shuts down as it should
Interested to know whether it would that for your machines,
Thanks Peter!prl wrote: ↑Sat Mar 16, 2019 18:32I've been able to replicate geoffree's bug!
On my test T4, after a factory reset:
Enabled MENU>Setup>TV>Timeshift>Stop timeshift while recording
Rebooted
Set a 1-minute timer a minute ahead (After action: auto)
Waited until recording started, used the remote on the T4.
Waited until recording finished, Used the remote (not sure whether using the remote is necessary to replicate the bug)
long-POWER>Shutdown
Popup with: "Recording(s) are in progress or coming up soon, or you are saving timeshift! / Really shutdown now?".
. Several do not!Thank you MrQuade! It did take many hours this afternoon.MrQuade wrote: ↑Sat Mar 16, 2019 21:15Oh we had no doubt it was happening! We were just frustrated by which of your unique settings was causing it!
The problem of such a flexible device with so many separate developers and independent plugins, is that it is next to impossible to catch every single combination of settings that may cause problems.
What it takes is patience from the end users to help us trace the source of their particular issues
So well done to you for hanging in there
Peter, I would be interested to know if, with 'Stop timeshift" etc set to ON.geoffree wrote: ↑Sat Mar 16, 2019 21:10Thanks Peter!prl wrote: ↑Sat Mar 16, 2019 18:32I've been able to replicate geoffree's bug!
On my test T4, after a factory reset:
Enabled MENU>Setup>TV>Timeshift>Stop timeshift while recording
Rebooted
Set a 1-minute timer a minute ahead (After action: auto)
Waited until recording started, used the remote on the T4.
Waited until recording finished, Used the remote (not sure whether using the remote is necessary to replicate the bug)
long-POWER>Shutdown
Popup with: "Recording(s) are in progress or coming up soon, or you are saving timeshift! / Really shutdown now?".
So glad "it's not just me"
I have often thought "these guys must think I'm crazy" as I tried to detail what was going on
Great relief to be vindicated.
I think this is the first time anybody has been able to recreate the issue.
Thanks to everybody who assisted
Of course, I'm going to continue to very carefully personalize my settings, testing as I go,
because there may be something else that triggers it too!
gb
It shuts down (for a timer with After event: auto).geoffree wrote: ↑Sat Mar 16, 2019 22:18Peter, I would be interested to know if, with 'Stop timeshift" etc set to ON.
you attempt an unattended recording as I described, it will shut down ok.
As it does for me ie. set a timer, shut down the U4, let it boot itself up at recording time and record
- don't touch the remote or in any way interact with the U4,, and see if it shuts down ok.
prl wrote: ↑Sat Mar 16, 2019 18:32I've been able to replicate geoffree's bug!
On my test T4, after a factory reset:
Enabled MENU>Setup>TV>Timeshift>Stop timeshift while recording
Rebooted
Set a 1-minute timer a minute ahead (After action: auto)
Waited until recording started, used the remote on the T4.
Waited until recording finished, Used the remote (not sure whether using the remote is necessary to replicate the bug)
long-POWER>Shutdown
Popup with: "Recording(s) are in progress or coming up soon, or you are saving timeshift! / Really shutdown now?".
ah hah! Just like my experience then?prl wrote: ↑Sun Mar 17, 2019 07:00It shuts down (for a timer with After event: auto).geoffree wrote: ↑Sat Mar 16, 2019 22:18Peter, I would be interested to know if, with 'Stop timeshift" etc set to ON.
you attempt an unattended recording as I described, it will shut down ok.
As it does for me ie. set a timer, shut down the U4, let it boot itself up at recording time and record
- don't touch the remote or in any way interact with the U4,, and see if it shuts down ok.
Try a completely unattended recording, meaning set a timer , turn the U4 off. let it boot itself up, do the recording and it should shut itself down as long as you don't interact with it at any time. This has been my absolutely consistent experience.prl wrote: ↑Sun Mar 17, 2019 07:01prl wrote: ↑Sat Mar 16, 2019 18:32I've been able to replicate geoffree's bug!
On my test T4, after a factory reset:
Enabled MENU>Setup>TV>Timeshift>Stop timeshift while recording
Rebooted
Set a 1-minute timer a minute ahead (After action: auto)
Waited until recording started, used the remote on the T4.
Waited until recording finished, Used the remote (not sure whether using the remote is necessary to replicate the bug)
long-POWER>Shutdown
Popup with: "Recording(s) are in progress or coming up soon, or you are saving timeshift! / Really shutdown now?".
As I suspected, the problem happens whether the remote is used or not (apart from using it to actually shut down) at the end.
if the PVR is already running and you have interacted with it, before the programmed recording starts,
Thanks.Grumpy_Geoff wrote: ↑Sun Mar 17, 2019 11:06
...not forgetting that for a T2 it normally won't boot to standby for a timer recording so this bug should be evident with an enabled Stop timeshift while recording setting.
Brilliant! well done!!!prl wrote: ↑Sun Mar 17, 2019 10:41OK, I think I've found the cause. There seem to be two issues that combine to cause the problem:
- In Components.Timeshift.InfoBarTimeshift.ptsTimerEntryStateChange() the test on config.timeshift.stopwhilerecording.value is inverted from what it should be.
- In the same method, the test len(JobManager.getPendingJobs()) >= 1 is not specific enough to only test whether timeshift saving jobs are running. Specifically, in this case there is a job running just after the recording finishes, the one that cleans out the trash folders, and that means that the job count is greater than 0 when this code runs.
- The combination of the above two result in config.timeshift.isRecording being set to True when it should be False.
- config.timeshift.isRecording being incorrectly set to True causes the shutdown code to incorrectly think that there are current timeshift save jobs being run, so it displays the "Recording(s) are in progress or coming up soon, or you are saving timeshift!" popup. It doesn't display the "N jobs are running in the background!" message for two reasons: by the time POWER is pressed on the remote, the trash cleanup job has finished, and even if it hasn't, the "Recording(s)" message takes priority over the "jobs" message.
- The bug doesn't affect recordings made in standby from shutdown, because the relevant part of ptsTimerEntryStateChange() is not executed if the box is in standby.
While this code may be the simplest to implement and provide a minimal diff, it's not exactly heading in the right direction as far as a clean and legible API is concerned. In light of the comments I made in other places about timeshift implementations, I wonder if it would be a good idea to enhance the timeshift code with a simple and clean API that tracks the state of timeshifting on a global (possibly C++) basis. I guess prior to going down that path the existing code should be audited to see if perhaps there is already a way and the higher level APIs are simply not using it properly, instead resorting to strange indirect idioms, like the above.prl wrote: ↑Sun Mar 17, 2019 12:14I think the fix for the job counting will be to replace:
(len(JobManager.getPendingJobs()) >= 1
with something like
len((j for j in JobManager.getPendingJobs() if j.__module__ == "Tools.TimeShift")) >= 1
All of the Jobs/Tasks used to do timeshift saves are defined in Tools.TimeShift. Using the job names would be a bit cumbersome.
There are a few places in the timeshift code where the change needs to be made (and so it should probably be encapsulated in a method).
peteru wrote: ↑Sun Mar 17, 2019 13:01While this code may be the simplest to implement and provide a minimal diff, it's not exactly heading in the right direction as far as a clean and legible API is concerned. In light of the comments I made in other places about timeshift implementations, I wonder if it would be a good idea to enhance the timeshift code with a simple and clean API that tracks the state of timeshifting on a global (possibly C++) basis. I guess prior to going down that path the existing code should be audited to see if perhaps there is already a way and the higher level APIs are simply not using it properly, instead resorting to strange indirect idioms, like the above.prl wrote: ↑Sun Mar 17, 2019 12:14I think the fix for the job counting will be to replace:
(len(JobManager.getPendingJobs()) >= 1
with something like
len((j for j in JobManager.getPendingJobs() if j.__module__ == "Tools.TimeShift")) >= 1
All of the Jobs/Tasks used to do timeshift saves are defined in Tools.TimeShift. Using the job names would be a bit cumbersome.
There are a few places in the timeshift code where the change needs to be made (and so it should probably be encapsulated in a method).
Oh and while I am here... Thanks to everyone for persisting with troubleshooting this and getting to the bottom of it.
Code: Select all
@staticmethod
def getPendingSaveTimeshiftJobs():
# Assumes that all timeshift save-related jobs
# are in Tools.TimeShift
return [j for j in JobManager.getPendingJobs() if j.__module__ == "Tools.TimeShift"]
@staticmethod
def hasPendingSaveTimeshiftJobs():
return len(InfoBarTimeshift.getPendingSaveTimeshiftJobs()) > 0
...
def someOtherMethod(self):
...
if ... hasPendingSaveTimeshiftJobs() ...:
bugger it. they should
Well done
