[mythtv-users] Immediate autoexpire recent rec. despite plenty of old rec. to expire

[Raymond Wagner]

On 10/30/2013 7:09 AM, John Pilkington wrote:
> On 30/10/13 09:48, warpme wrote:
>> Hi *
>>
>> I need small consultancy regarding unpleasant issue witch started
>> recently in my production system: random recent recordings are quickly
>> 'disappearing' causing users complain like 'argh my favorite show again
>> wasn't recorded'.
>>
>> Checking on logs it looks like those recording were recorded OK - but
>> they expired immediately (within minutes after rec. finishes).
>> My hypothesis is that myth expiring them for making room for new
>> recordings. But in the same time few weeks old recordings are not
>> expired...
>> It was surprise for me as on 6T Default SG I have 2T space which is
>> "Used by Auto-expirable Recordings" - so theoretically old. recordings
>> from this pool should be used first for making room for new recordings.
>>
>> My 6T Default SG is sum of 2 volumes: 2T partition used since initial
>> system build (/mythtv/tv) and 4T drive (/myth/tv1) added half Year ago
>> as storage expansion.
>> StorageScheduler is "Combination".
>> Looking on few 'too quickly' expired recordings - they always were on
>> '/mythtv/tv' (old drive).
>>
>> Now I see potential root cause: if 'old drive' is almost full with
>> non-expirable recordings - then if scheduler schedules multiple new rec
>> (my wife can schedule 4-7 concurrent on prime time) - some of them will
>> be assigned to this drive and will cause expiration of other, recent
>> recordings despite other drive (/myth/tv1) had candidates 1-month old
>> rec. to expire. This is just theory.
>>
>> To verify this hypothesis will be good to count space occupied by
>> non-expirable recordings per SG member ( '/mythtv/tv' here).
>> Is there easy way to do this?
>>
>> Generally, looking on this issue from overall perspective: potentially I
>> see where I do mistake: I assume SG is nice way to expand storage when
>> user has lack of space.
>> I was happy not going with things like LVM (as member failure brings
>> whole volume down).
>>
>> Hypothesis from beginning of this post (if verified as correct one)
>> shows that SG is perfect for IO scaling - but not for space scaling.
>> I suspect only proper solution of my issue is moving from application
>> level striping (mythtv SG) to fs level striping (LVM) or mass storage
>> level striping (RAID)...
>> Unfortunately this is quite difficult to do me as I don't have 6T temp
>> storage needed for such conversion.
>>
>> Do anybody see other solution here?
>>
>
> It sounds as if you have a problem with the storage group disk
> scheduler, on around page 3 of the General menu in mythtvsetup.  I know
> I lost some recordings when I changed from 'Balanced free space'
> recently after, IIRC, Mike Dean had said that that one had a bug.  For
> me the alternatives seemed worse, and I went back.  I can't really
> investigate further without disrupting things, but that's what I would
> check.  Of course, I don't know why you are suddenly seeing this.

It's not so much a bug, but merely a deficiency in the disk scheduler. 
It is operating as designed, but does not factor expiration of 
recordings into its decision, since that information is only available 
during the process of recording.  The only real solution is to 
periodically, manually balance out your free space between your two disks.