id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 9089 Scheduler needs to account for rsTuning state gigem gigem "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. 2. 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. 3. 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. 4. 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. " defect closed critical 0.24 MythTV - Scheduling Master Head high Fixed jpoet 0