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

[Michael T. Dean]

  On 08/13/2010 10:58 AM, Brett Kosinski wrote:
>>> 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
> I checked those, as I wanted to see if it was getting the max required
> wrong, but unfortunately, no, they all just look like this:
>
> 2010-08-11 15:51:03.427 AutoExpire: CalcParams(): Max required Free
> Space: 30.0 GB w/freq: 15 min
>
> Where the free space count varies between 30 and 32 GB (which itself
> is a bit odd... makes me wonder how that value is computed for
> display).

Based on how much is recording.  With "Extra disk space" set to 30GB and 
0 recordings in progress, the value is 30.  With one (through some other 
number, depending on bitrate) recording in progress, the value is 32GB.

>> 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.).
> I'm not sure where to look for these things.  I've spent many a year
> combing logs on unix systems, and from what I can tell, the events
> before the start of the expiration sequence are pretty vanilla.   One
> recording had stopped and two started 5 minutes prior.  There was one
> file that had a bad read ("Invalid file (fd -1) when opening"), which
> could be indicative of FS corruption.  Max free space was indicated as
> 32 GB, and then it started expiring.
>
> And note, most of the other expiration events are not preceded by
> open() errors, which makes me think that's unrelated...
>> 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.
> Hmm... sounds like I should patch the code, then.

The "I don't think you'll see anything too interesting," was intended to 
mean that I still think something other than autoexpire is to blame.  
With the above verbosity, you would see all the information you need to 
determine why "autoexpire went crazy."

Again, though, /someone else/ could likely see enough in your existing 
(unabridged) logs to tell you what did happen.

Mike