[mythtv-users] rebalance deleted recordings

[Michael T. Dean]

On 03/20/2014 11:35 AM, Brian J. Murrell wrote:
> On Thu, 2014-03-20 at 14:58 +0000, Simon Hobson wrote:
>> I suppose the *correct* fix for that is to expand on Myths drive usage logic so that it will correctly only expire deleted recordings until there are none of those left, and then only expire non-deleted recordings in strict priority order
> I believe that is already the case.

Yes, that is pretty much how it works, but with one proviso--it's done 
on a per-file-system basis and only on file systems when MythTV is 
actually/already writing a new recording to that file system.

MythTV will first autoexpire any Live TV recordings.  After those are 
all gone, recordings in the Deleted recording group will be expired 
(even if they are newer than the "Time to retain deleted recordings 
(days)" setting specifies).  Once all Deleted recordings are gone, 
recordings that are not Deleted (but /are/ marked to allow expiration) 
are expired.  If you've enabled the "Watched before unwatched" setting 
("If enabled, programs that have been marked as watched will be expired 
before programs that have not been watched."), then any recordings (on 
that file system) that are marked as Watched will be deleted before any 
recording that's not marked as Watched, regardless of auto-expiration 
priority/age of recordings (so last night's pilot episode of "The 100" 
that you watched/marked as watched would be expired before the Simpsons 
re-run you recorded in 2005 with your PVR-250 that you haven't watched).

>    Further I believe that if Myth has
> the choice of recording on a disk that is "full" vs. one with
> available/free space, it will choose the latter, expiring a deleted
> recording if needed.  This is why I assert that to MythTV, available
> space == free space.

At this point we don't do this because we have no idea where (on which 
file system) each recording exists.  So the file system to which we 
record is chosen without use of/knowledge of 
Deleted/Watched-Expirable/Unwatched-Expirable--or even 
Unexpirable--space usage.  (Therefore, if you have a full file system 
without any expirable recordings, MythTV will fail hard when it tries to 
record to it.)  This is also why the backend status page only shows 
"Space Available After Auto-expire" in the "Total Disk Space" summary 
and not on a per-file-system basis.

While it's possible to make a "naive" Storage Group Disk Scheduler that 
would search through the autoexpire list until it finds the first 
(highest-priority-for-expiration) recording that's on a file system 
that's also used by the Storage Group specified for the recording rule, 
it wouldn't have enough "big picture" information to do much (any?) 
better than the currently-available SG Disk Schedulers (because it may 
well find the next-to-expire recording is a 30-min recording on a 
specific file system that has no other high-priority-for-expiration 
recordings or no other expirable content, yet a different file system 
used within the same SG has hundreds of gigabytes of 
high-priority-for-expiration recordings and would be a better choice).

Eventually, we'll have more information about actual file systems, file 
system locations (local vs network), and--most importantly--actual 
locations of recording files, which will allow us to get a big-picture 
view that will allow a better-for-almost-everyone SG Disk Scheduler.  
Until then, manually balancing your content is required (whether you 
have a long "Time to retain deleted recordings (days)" value or short).  
You can do this through "limited" pre-expiration (i.e. go into Watch 
Recordings, change to the Live TV recording group and MENU|Add this 
Group to Playlist, MENU|Playlist Options|Delete, then go to the Deleted 
recording group in Watch Recordings and find the oldest/least 
interesting/... recordings (the ones you actually /want/ it to expire 
first, regardless of the computed priority, which generally means far 
less than people believe) and delete them.  Deleting from the Deleted 
recording group will actually remove the files from disk, so you'll make 
some space.  Watch the free space on your file systems and if things 
seem well balanced, you're good for now.  If not, then move around some 
recordings as desired.  (And if you have no more Live TV and Deleted 
recordings, you can go into mythfrontend's System Status screen and 
select Auto-Expire Order and start deleting some recordings you really 
don't care about, the go back to Deleting from the Deleted recording group.)

All the above boils down to this:  when MythTV records a new show, it 
needs space; if there is no free space in which to record, something 
must be deleted; you know far better than any (mostly meaningless) 
number which recordings are least important to you.

That said, a script to balance recording placement isn't a bad idea.  If 
you create it, though, please take advantage of the Python 
bindings--which will do a lot of the work for you and will continue to 
work even when we make (some planned--and major) changes to the 
database/data model.

More info on deletion is at:  
http://www.gossamer-threads.com/lists/mythtv/users/556866#556866

Mike