[mythtv-users] MythTV 0.23 backend suddenly auto-expired a ton of recordings...

[Michael T. Dean]

  On 08/13/2010 12:31 AM, Brett Kosinski wrote:
>> The "randomness" of the order has to do with which file system is in
>> use/needs something expired.  So, if MythTV records to a file system that
>> only has shows recorded this week on it and another file system has shows
>> recorded 7 years ago, it will expire something from this week--because,
>> well, expiring one of those shows from 7 years ago won't help us fit /this/
>> recording on /this/ file system.
> While I'm sure that explains the behaviour on some other systems, that
> certainly doesn't explain what was going on with my backend, as all
> the storage is unified in a single volume.
>
> Meh, anyway, I think its clear that I'm not going to be able to figure
> out, after the fact, what happened.  But as I said earlier, if its
> possible to increase the logging so that Myth is a little more verbose
> about why its expiring certain things, I'd be happy to do that.
>
> Alternatively, I suppose I could go and hack the code myself and add
> the necessary detail if its not possible to enable it through
> command-line flags.

The logs you have would still have some interesting information in 
them.  Things like:

2010-08-13 00:25:37.505 AutoExpire: CalcParams(): Max required Free 
Space: 2.0 GB w/freq: 14 min

and more would give some picture of what was happening at the time when 
things were expired (number of recordings, when they occurred, how many 
occurred, etc.).

If you really want to watch for some failure, you can use -v 
important,general,file (or for very verbose logs, -v 
important,general,file,extra ), but I don't think you'll see anything 
too interesting.

Mike