Opened 20 years ago
Closed 19 years ago
Last modified 19 years ago
#292 closed defect (fixed)
"Never Record" in Scheduled Recordings doesn't always work.
| Reported by: | Owned by: | xris | |
|---|---|---|---|
| Priority: | minor | Milestone: | unknown |
| Component: | mythweb | Version: | 0.18.1 |
| Severity: | low | Keywords: | |
| Cc: | Ticket locked: | no |
Description (last modified by )
Quite often the Never Record link on the Scheduled Recordings doesn't work.
Can't figure out any commonalities.
Change History (8)
comment:1 by , 20 years ago
comment:2 by , 20 years ago
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 by , 20 years ago
| 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:5 by , 19 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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
follow-up: 8 comment:6 by , 19 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
please don't reopen ancient tickets involving old versions
comment:7 by , 19 years ago
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 by , 19 years ago
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
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.