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

[myth@…]

Quite often the Never Record link on the Scheduled Recordings doesn't work.

Can't figure out any commonalities.

[Adam Di Carlo <aph@…>]

I've experienced this as well. I find that if I use "don't record" it works, or, of course, I can mark it not to record in MythFrontend.

I'm guessing its some SQL join edge case.

[anonymous]

I've had a similar problem; however, I usually find hitting "Never Record" again (and possibly a third time) does the trick. I'm not entirely sure whether in my case it's just misdisplaying the status, or if it really failed to set it.

(There's also a bug in that "never record" is shown when it doesn't actually work e.g. if duplicate matching is disabled for whatever reason. Mythfrontend gets this right.)

[xris]

This isn't really a bug.. It's just that mythweb doesn't wait long enough after submitting the changes to the backend. I'll add a small delay.

[xris]

(In [7695]) close #292

[tmetro+mythtv-bugs@…]

This issue is still a problem. I see the fix was committed back in 2005, but I'm seeing it in 0.20 releases built from code that is just a few months old.

I've also observed two different behaviors for this problem.

In one case hitting "Never Record" 2 to 3 times resolves it. Sometimes hitting refresh after hitting "Never Record" once will do it. This case is undoubtedly the same as the one xris addressed with the patch that adds a delay, though it seems like there should be a more deterministic solution than using a fixed delay, which will be too short in some cases and unnecessarily long in others. I'm also wondering if maybe there is some error checking missing somewhere along the way... (I'll look into the code myself if someone can provide some high-level info on how the mythweb <-> myth-backend interaction works and a few pointers to source files.)

With the other situation, which I've seen far more rarely, multiple clicks on "Never Record" have no effect. Yet the recording status can be changed using Mythfrontend. I'm not sure, but I think I observed a message logged by myth-backend saying that the program ID was -1. Further investigation is required.

In both cases no feedback is provided to the user. The status just remains unchanged. I'd at least like to see the first issue addressed, and this variation can be addressed in another ticket.

-Tom

[Janne Grunau]

please don't reopen ancient tickets involving old versions

[xris]

fyi, if you have a slow backend, it can take several seconds for the scheduler to catch up. There's nothing I can do to speed this up. It's just a factor of how things are for now. Hopefully integrating mysql into the backend (and allowing for faster things like subqueries) will speed up the scheduler query enough that this won't be an issue.

[anonymous]

Replying to janne:

please don't reopen ancient tickets involving old versions

If it was a regression, different symptoms, or a different cause, then I agree. In this case it was the same symptom, apparently same cause, and it appears that the original fix (in my opinion) was inadequate. I see value in keeping all the related history of the problem together.

But if your policies dictate otherwise, I'll open a new ticket.

-Tom