"Never Record" in Scheduled Recordings doesn't always work.

[anonymous]

Same issue as documented in Ticket #292. I commented on it there already, but was told to open a new ticket.

[tmetro+mythtv-bugs@…]

fyi, if you have a slow backend, it can take several seconds for the scheduler to catch up.

Without a benchmark for some particular operation to compare against, I can't say whether something is out of tune on my back-end causing it to behave slowly, but the problem is easily reproducible on a system with:

# cat /proc/cpuinfo model name : AMD Athlon(tm) XP 2600+ cpu MHz : 2088.170 cache size : 256 KB bogomips : 4179.22

while sitting idle.

I suppose the delay will vary based not only on the system, but the complexity of the schedule. I hadn't given it much thought, but I suppose the problem has gotten worse as the number of items on my schedule has grown.

There's nothing I can do to speed this up. It's just a factor of how things are for now.

I wasn't looking for a speedup, but a more deterministic way to know when the updated value was ready.

For example, is there a way to ask the back-end if it is in the midst of a schedule recalculation? Can you get notified when a recalculation is complete?

Why is a schedule recalculation needed in order to update a "never record" setting? Clearly it affects the schedule, but shouldn't the "never record" status be immediately reflected in the recording settings for that entry? Or does the process require that you adjust a schedule setting, and then the back-end propagates that change to the specific program record being shown by mythweb? (I'm guessing a program detail page in mythweb combines data from both a program record and a schedule record.)

If the request to change the value succeeded (assuming the back-end provides such feedback), and you have every reason to believe the scheduler will change the status of "never record", can you "cheat" and carry that information forwarded to the page being rendered?

Why doesn't modification of any of the other scheduling parameters (all the stuff in the blue box) not suffer from this same delay problem? Is that because that data is held in a scheduling record that mythweb accesses directly and gets updated immediately, without needing the scheduler to update it?

So presumably the "Possible conflicts with this show" list shown on the show detail page is similarly suffering from delayed updating after a scheduling change, just that it is less noticeable.

Thanks for the reply.

-Tom

[Nick Morrott <knowledgejunkie@…>]

I regularly see this behaviour too, on my AMD64-3000-based master backend (running 32-bit 2.6.16 kernel).

When the 'Never Record' option successfully matches the episode, the refreshes page just misses catching the updated schedule. An immediate refresh of the Upcoming Recordings page shows the corrected schedule. Using the frontend, any Never Record changes are instantaneous.

I've also seen total failures where the Never Record option fails to match the episode it is run against - this has been fixed by changing the dupe matching method (and new schedules nearly always use the newer Subtitle Then Description method).

Nick

[xris]

nothing I can do about this until there is a "reschedule finished" kind of event added to the backend.

My guess with the frontend is that you're just seeing that one get marked, but not seeing any associated updates that might go along with it (e.g. other shows then being activated). Feel free to reopen if this is not the case, and it's actually rescheduling everything on the fly.