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)

maxepisodes.diff (1.2 KB) - added by cpinkham 17 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 17 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham

comment:2 Changed 17 years ago by subbyz

After looking through the 0.20 source, it appears that AutoExpire::ExpireEpisodesOverMax? is not testing maxnewest > 0 in it's checks.

query.prepare("SELECT recordid, maxepisodes, title "

"FROM record WHERE maxepisodes > 0 " "ORDER BY recordid ASC, maxepisodes DESC");

should instead be:

query.prepare("SELECT recordid, maxepisodes, title "

"FROM record WHERE maxepisodes > 0 AND maxnewest > 0 " "ORDER BY recordid ASC, maxepisodes DESC");

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.

comment:3 Changed 17 years ago by subbyz

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 subbyz

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 subbyz

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 cpinkham

Attachment: maxepisodes.diff added

comment:6 Changed 17 years ago by cpinkham

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 anonymous

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 cpinkham

Resolution: fixed
Status: newclosed

(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 cpinkham

(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.

Note: See TracTickets for help on using tickets.