Opened 16 years ago

Closed 14 years ago

Last modified 14 years ago

#292 closed defect (fixed)

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

Reported by: myth@… Owned by: xris
Priority: minor Milestone: unknown
Component: mythweb Version: 0.18.1
Severity: low Keywords:
Cc: Ticket locked: no

Description (last modified by xris)

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

Can't figure out any commonalities.

Change History (8)

comment:1 Changed 16 years ago by 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.

comment:2 Changed 16 years ago by 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.)

comment:3 Changed 15 years ago by xris

Description: modified (diff)

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.

comment:4 Changed 15 years ago by xris

Resolution: fixed
Status: newclosed

(In [7695]) close #292

comment:5 Changed 14 years ago by tmetro+mythtv-bugs@…

Resolution: fixed
Status: closedreopened

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.


comment:6 Changed 14 years ago by Janne Grunau

Resolution: fixed
Status: reopenedclosed

please don't reopen ancient tickets involving old versions

comment:7 Changed 14 years ago by 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.

comment:8 in reply to:  6 Changed 14 years ago by 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.


Note: See TracTickets for help on using tickets.