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

[Andre Newman]

On 30 Oct 2013, at 10:48, warpme <warpme at o2.pl> 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…

I have had a similar sounding problem a few times.

I found that accessing the recordings directory with some other application had changed the access rights of some of the recordings, I found that Myth was trying to expire old recordings but was unable to delete them. I had some failed recordings and a lot of recent recordings expired.

Maybe it's worth checking the rights on your recording?

Andre

> 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?
> 
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users