Opened 10 years ago

Closed 10 years ago

#12165 closed Patch - Bug Fix (Won't Fix)

Max episodes expiration ignores autoexpire = 0

Reported by: wowatheron@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: 0.27.1
Severity: medium Keywords:
Cc: Ticket locked: no

Description

If a recording rule is configured to have a maximum number of episodes, and an additional recording is scheduled as an override, the oldest episode will be expired even if the recording rule has autoexpire turned off.

Steps to reproduce:

  1. Create a recording rule which will record a lot of things, for example a power search with the phrase "program.category_type = 'movie'". Turn off auto-expire for the rule, and set max episodes to a reasonable value.
  1. Allow MythTV to record the specified number of episodes, it should not record more than the value specified.
  1. From the program guide, select another show which matches the rule. Myth will indicate the showing is not going to record because too many recordings have already been recorded. Select to record this showing.
  1. The show selected in step 3 above will record, and after it completes the next time the expiration runs it will delete the oldest show from the rule created in step 1.

Expected behavior: Because autoexpire=0 on the recording rule, I would expect it to always honor that setting and not expire any recorded shows from the rule. It seems reasonable to allow the user to manually schedule a recording that happens to match a rule, without affecting shows scheduled on that rule.

Actual behavior: Recorded shows are deleted

Justification: Consider the example rule above, perhaps a user has collected 5 movies to watch later. They notice a particularly good movie coming up in the guide, and override the rule to force it to record. With the current behavior, one of the 5 previously recorded movies will be deleted. This would not be the expected outcome, given the rule has auto-expire disabled and they manually scheduled a specific showing.

Proposed solution: In autoexpire.cpp AutoExpire::ExpireEpisodesOverMax?, exclude recording rules with autoexpire=0. I'll attach a patch.

Attachments (3)

autoexpire.patch (695 bytes) - added by wowatheron@… 10 years ago.
Patch to autoexpire.cpp
version.txt (948 bytes) - added by wowatheron@… 10 years ago.
mythbackend --version output
autoexpire.2.patch (696 bytes) - added by wowatheron@… 10 years ago.
Fixed patch, was missing a space in the query

Download all attachments as: .zip

Change History (4)

Changed 10 years ago by wowatheron@…

Attachment: autoexpire.patch added

Patch to autoexpire.cpp

Changed 10 years ago by wowatheron@…

Attachment: version.txt added

mythbackend --version output

Changed 10 years ago by wowatheron@…

Attachment: autoexpire.2.patch added

Fixed patch, was missing a space in the query

comment:1 Changed 10 years ago by sphery

Resolution: Won't Fix
Status: newclosed

Allow auto-expire means allow deleting to make room for new recordings when the file system is full. It is ignored by max episodes logic. Preserve is used to indicate an episode should not count toward max episodes logic (see around line 686 of autoexpire.cpp). So, you can preserve an episode and then it will not be deleted due to the max episodes specified by your recording rule. However, if the file system fills up and the episode is marked to allow auto-expire, it can be deleted to make room for new recordings.

If you want an episode to be kept--regardless of max episodes specified by the rule and regardless of whether the file system fills--you must both preserve it and disable auto-expire. Preserve is accessed in Watch Recordings by selecting an episode, hitting MENU|Storage Options|Preserve this episode (right below Enable Auto Expire).

Specifically because of incidents like this where users are surprised to find there's a preserve attribute, there have been discussions about changes to make the system less confusing to users--probably by making a single, multi-state flag rather than two independent boolean flags. I'm closing this ticket for now since the plan for changes is different from the one presented here. Regardless of whether we have a ticket, the changes will eventually be made.

If you have any questions about preserve or auto-expire, please ask on the mythtv-users mailing list or forum. If you would like to code a patch to combine the auto-expire/preserve fields and simplify the user interface (though this would not be a small/simple patch to create), please feel free to ask questions about the desired approach on the mythtv-dev mailing list or forum.

Thank you.

Note: See TracTickets for help on using tickets.