Opened 17 years ago
Closed 13 years ago
#3597 closed enhancement (fixed)
EIT scanner breaks idle shutdown
Reported by: | anonymous | Owned by: | stuartm |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - EIT | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | yes |
Description
Hi,
I tried to set up my computer so that it goes to sleep when mythbackend is idle.
I set the idle timeout value to 10 minutes, but this didn't work as expected. The EIT scanner causes a reschedule that disturbs the idle countdown and resets it frequently, so that the backend may never go to sleep.
I solved this with a patch (see the attachment) that prevents the scheduler from resetting the idle countdown.
Now the idle timer works as expected. You can see how the patch works by looking into the log file:
2007-06-11 11:58:25.811 scheduler: Scheduled items: Scheduled 7 items in 0.2 = 2007-06-11 11:58:25.811 Resetting of idleSince aborted!
Attachments (4)
Change History (22)
Changed 17 years ago by
Attachment: | scheduler_idle_countdown_reset_fix.diff added |
---|
comment:1 Changed 17 years ago by
Hi,
any comments to the patch? Is it crap? Does it have side effects? Can this issue solved in a different way?
To make the problem and the solution in the patch more clear, I attach a log snipset from my backend. As you can see, the scheduler disturbs the idle countdown multiple times. Thanks to the patch, the countdown won't be reset and the backend does a shutdown after 600 seconds.
Regards, Tino
comment:2 Changed 17 years ago by
Component: | mythtv → eit |
---|---|
Owner: | changed from Isaac Richards to Stuart Auchterlonie |
Type: | defect → enhancement |
Version: | unknown → head |
comment:3 Changed 17 years ago by
I don't have a functioning mythtv system at the moment (long story), but this was a show stopper for me running the system exactly as I wanted, i.e. firing up the backend to record programmes I am always interested in, and actually using a tuner on my Mac FE to watch TV "ad-hoc", with recorded programmes going on to a network drive.
comment:4 Changed 17 years ago by
Milestone: | unknown → 0.21 |
---|---|
Status: | new → assigned |
comment:5 Changed 17 years ago by
There are a few threads on this subject as to why the proposed change may not be enough (http://www.gossamer-threads.com/lists/mythtv/dev/196893). Also I would expect there may be an issue if the scheduler does need to reschedule events, and the idle time is close to zero. In the reschedule event is to starting recording within some seconds, the backend may not have enough time to start the recording before the shutdown starts. It may be safer to reset the idle timer to 30 seconds if there is less than 30 seconds remaining to shutdown. Or if items have been rescheduled, reset the timer, if nothing is rescheduled, do not reset the idle timer.
comment:6 Changed 16 years ago by
Milestone: | 0.21 → 0.22 |
---|
comment:7 Changed 15 years ago by
Milestone: | 0.22 → unknown |
---|
comment:8 Changed 14 years ago by
Component: | eit → MythTV - EIT |
---|
comment:9 Changed 14 years ago by
This bug should not be against "MythTV - EIT" since any reschedule will cause the idle shutdown to be restarted, not just one from EIT.
I can confirm the problem still exists with 0.22-fixes.
comment:10 Changed 14 years ago by
Owner: | changed from Stuart Auchterlonie to danielk |
---|---|
Status: | accepted → assigned |
comment:12 Changed 13 years ago by
This issue also affects me and it would save me a lot of electricity if the mythtv box could just shutdown reliable.
comment:13 Changed 13 years ago by
Ticket locked: | set |
---|
comment:14 Changed 13 years ago by
Ticket locked: | unset |
---|
Changed 13 years ago by
Attachment: | scheduler.cpp.2.diff added |
---|
Updated patch for scheduler for 0.24-fixes
comment:15 Changed 13 years ago by
For those of us using EIT this is a tough choice between power savings and keeping our schedules up to date. I look forward to the implementation on 0.24, I am currently running mythbuntu 0.23-fixes. I am not familiar with the code but reading some of the previous suggestions and thinking about the problem I would be willing to work with a user setting that prevents the idle timeout from resetting even when new EIT modifications are received so that the computer will still shut down even if it recently received an EIT update. If I turn the computer off manually I'm going to miss all the updates anyway until I turn it back on. I would also help then to ask the user if a previously scheduled recording that is now deactivated because it cannot be matched to a guide entry (since the EIT might not be up to date when the computer starts after an extended shutdown) should remain active and record whatever timeslot it was scheduled to record. There will be little chance the user would end up recording something other than what was scheduled anyhow.
In any case, thanks for the great work!
comment:16 Changed 13 years ago by
Ticket locked: | set |
---|
comment:17 Changed 13 years ago by
Milestone: | unknown → 0.25 |
---|---|
Owner: | changed from Stuart Auchterlonie to stuartm |
Status: | assigned → accepted |
If there are no immediate objections, I'll apply this tonight. There are consequences to ignoring reschedules when deciding to shutdown the backend but it seems to me that those people who prefer the power savings are already gambling that last minute schedule changes won't occur.
comment:18 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Do not allow EIT to prevent backend shutdown through last minute reschedules. Closes #3597
Signed-off-by: Stuart Morgan <smorgan@…>
Branch: master Changeset: de0d29c8b6e3a1f9a0b07d82a07d9a2dd85a3973
fix to prevent the scheduler from resetting the idle countdown