Opened 17 years ago
Closed 17 years ago
Last modified 17 years ago
#3196 closed defect (fixed)
Autoexpire and backend fail to heed maxnewest = 0, deletes old programs that shouldn't and records new ones
Reported by: | anonymous | Owned by: | cpinkham |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | 0.20 |
Severity: | medium | Keywords: | expire autoexpire maxnewest limit |
Cc: | Ticket locked: | no |
Description
I've setup a custom rule to record all programs with a genre of "Documentary" with a limit of 30 episodes kept, no autoexpire on either the recording rule or the show records themselves, and with "Don't record if this would exceed the maximum episodes" set.
I've confirmed that the DB has ALL rules set as record.autoexpire = 0, and ALL programs have recorded.autoexpire = 0. In addition, the recording rule the shows are still (wrongly) being expired and recording other newer ones has record.maxepisodes = 30 and record.maxnewest = 0.
With the above settings, I still get log messages like: "Expiring "Dead Men's Secrets" from Thu Mar 8 10:00:00 2007, 477 MBytes, too many episodes (only want 30)." and the backend is continuing to schedule and record new programs for this rule even though it has obviously reached the limit of 30 shows.
Happy to provide any additional info that may be useful.
Attachments (1)
Change History (10)
comment:1 Changed 17 years ago by
Owner: | changed from Isaac Richards to cpinkham |
---|
comment:2 Changed 17 years ago by
comment:3 Changed 17 years ago by
I've confirmed that the fix to the SQL above corrects the problem where the recorded programs continue to be expired when they shouldn't. However, it does not fix the problem that the backend continues to record new programs even though it has surpassed the maxepisodes limit.
comment:4 Changed 17 years ago by
In Scheduler::AddNewRecords?, it appears that the maxepisodes check is using the title of the show rather than the recordid for checking the limits. While the current way works for simple rules based on show title, it doesn't work for other more complex custom rules.
Here is a modification to make it attribute all shows to the rule that caused them to be recorded, based on the recordid rather than the title.
epicnt.prepare("SELECT count(*) FROM recorded "
"WHERE title = :TITLE AND duplicate <> 0;");
epicnt.bindValue(":TITLE", qtitle.utf8());
should instead be:
epicnt.prepare("SELECT count(*) FROM recorded "
"WHERE recordid = :RECID AND duplicate <> 0;");
epicnt.bindValue(":RECID", recid);
Haven't yet tested this, but seems like it should work.
comment:5 Changed 17 years ago by
Have now tested this fix, and confirmed it now behaves correctly for more complicated recording rules than simple title matches.
Changed 17 years ago by
Attachment: | maxepisodes.diff added |
---|
comment:6 Changed 17 years ago by
The patch above is not a complete fix. I had one in my tree already and have posted on the list about this ticket.
Can you give the attached patch a try and see if it works correctly for you? It should handle all cases, including cases where a single recording is split up into multiple parts such as when the backend is restarted mid-recording. This patch should handle everything the expirer does so they are using the same logic.
I don't like the while loop in the patch just to count curEpisodes, but off the top of my head, I can't think of any other way we can do this inside a single MySQL v3.x compatible SQL statement.
maxepisodes.diff is attached.
comment:7 Changed 17 years ago by
Figured it might be worth reporting some unofficial test results here.
Note: I am not the originator of this bug report.
I was experiencing similar symptoms with a custom record rule over the last few weeks. I applied the maxepisodes.diff patch last night and it certainly appeared to work for me.
Myth was at the max limit for episodes and with the fix applied the scheduler (finally) stopped scheduling new recordings, marked the upcoming recordings as 'T' in MythWeb and did not expire the oldest like it has been for the previous two weeks.
Thanks for the fix.
comment:8 Changed 17 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [13109]) Make the scheduler's maxepisode counting using the same logic that the AutoExpirer? uses so they agree on where each scheduled recording rule is at relative to its maxepisodes value.
Closes #3196.
comment:9 Changed 17 years ago by
(In [13110]) Carry over [13109] from trunk.
Make the scheduler's maxepisode counting using the same logic that the AutoExpirer? uses so they agree on where each scheduled recording rule is at relative to its maxepisodes value.
References #3196.
After looking through the 0.20 source, it appears that AutoExpire::ExpireEpisodesOverMax? is not testing maxnewest > 0 in it's checks.
should instead be:
This looks like it should fix the autoexpire problem. There may or may not still be an issue with the backend continuing to record new episodes though.