James Abernathy <email@example.com> says: > So I ran the find_orphans.py script just to see what it would find,
> expecting nothing and I found a good bit of stuff.
It's surprising what scripts can turn up. A while ago I had a problem
with drives running out of room for recordings despite the "Extra disk
space (GB)" setting not being changed; increasing this setting to
enlarge the safety margin made no difference. One day I ran the
flush_deleted_recgroup.pl script for a different reason and found many
more entries being deleted than I expected.
What happened was that a bunch of old, leftover recording entries and
associated recording files were present in the Deleted recording
group, although not visible when manually visiting it from Watch
Recordings. Whatever caused them to be invisible also made them not
get swept up by the "Time to retain deleted recordings (days)" setting
(8 days in my case), and find_orphans.py did not find them either.
(A symptom of this problem is the total number of recordings the
frontend lists in the Change Filter popup for each individual
recording group?"Default", "Deleted" (if existing), and any others you
have created?differing from the number of entries in the 'recorded'
database schema. (Don't use the number of recordings in "All
Programs"; that excludes those in "Deleted".)
flush_deleted_recgroup.pl almost entirely solved the problem, but
there were a couple of garbage recording entries lacking associated
recording files that the script ignored. I used 'touch' to create
dummy recording files, then reran the script.
Frontend: Apple MacBook Pro 2012 2.6GHz with 1TB SSD
Backend: HP Microserver N40L 1.5GHz with 4x3TB HDDs
Video inputs: Three from CableCARD plus two over-the-air
mythtv-users mailing list
firstname.lastname@example.org http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org