Opened 14 years ago
Closed 14 years ago
Last modified 14 years ago
#9089 closed defect (Fixed)
Scheduler needs to account for rsTuning state
| Reported by: | gigem | Owned by: | gigem |
|---|---|---|---|
| Priority: | critical | Milestone: | 0.24 |
| Component: | MythTV - Scheduling | Version: | Master Head |
| Severity: | high | Keywords: | |
| Cc: | jpoet | Ticket locked: | no |
Description
Recent changes to the signal monitor made it possible for a tuner to stay in the rsTuning state for some period of time. Consequently, the scheduler needs to be more aware of the rsTuning state in order to avoid scheduling duplicate recordings and to automatically reschedule upon a slave or master backend restart.
The attached rstuning3 patch should address the problem, but I am unable to test a master/salve configuration at the moment and John Poet probably can't do so until this weekend. If someone else wants to run the following tests before then and report back, that would be great.
- Create an artificially long tuning period for a single recording on a slave with all other tuners busy, then restart the slave backend. The master backend should restart the recording on the slave.
- Create an artificially long tuning period for a single recording on a slave with another tuner available, then restart the slave backend. The master backend should restart the recording on the master or on another slave.
- Create an artificially long tuning period for a channel or all recording on a slave with a later, repeat showing available, then restart the slave backend. The master backend should reschedule the recording for a later time.
- Repeat 1-3, but restart the master backend instead of the slave. The master should notice the slave is already tuning, or even recording by then, and not reschedule the recording.
Attachments (1)
Change History (5)
Changed 14 years ago by
| Attachment: | rstuning3.patch added |
|---|
comment:1 Changed 14 years ago by
| Status: | new → assigned |
|---|
comment:2 Changed 14 years ago by
| Milestone: | 0.25 → 0.24 |
|---|
comment:3 Changed 14 years ago by
| Resolution: | → Fixed |
|---|---|
| Status: | assigned → closed |
comment:4 Changed 14 years ago by
(In [26952]) Backports [26951] to 0.24-fixes.
Treat the rsTuning state similarly to rsRecording. This allows scheduling to continue while just started recordings might still be in rsTuning. Also fix some locking issues that crept into the scheduler over the last couple of releases. Partially reverts [26518] and fixes #9089.
(In [26951]) Treat the rsTuning state similarly to rsRecording. This allows scheduling to continue while just started recordings might still be in rsTuning. Also fix some locking issues that crept into the scheduler over the last couple of releases. Partially reverts [26518] and fixes #9089.