Opened 9 years ago

Closed 9 years ago

Last modified 9 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.

  1. 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.
  1. 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.
  1. 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.
  1. 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)

rstuning3.patch (6.7 KB) - added by gigem 9 years ago.

Download all attachments as: .zip

Change History (5)

Changed 9 years ago by gigem

Attachment: rstuning3.patch added

comment:1 Changed 9 years ago by gigem

Status: newassigned

comment:2 Changed 9 years ago by gigem

Milestone: 0.250.24

comment:3 Changed 9 years ago by gigem

Resolution: Fixed
Status: assignedclosed

(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.

comment:4 Changed 9 years ago by gigem

(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.

Note: See TracTickets for help on using tickets.