[mythtv-users] Avoiding mythbackend crash when deleting lots of recordings

[Yeechang Lee]

I am still on 0.26. A kernel panic corrupted two of four storage
drives, destroying about 1500 recordings' files. I began deleting the
associated MythTV recordings, some manually from MythFrontend, and
others with the find_orphans.py script.

Whether using find_orphans.py, or flush_deleted_recgroup.pl to empty
the Deleted recording group, mythbackend consistently crashed with

	GLib-ERROR **: Creating pipes for GWakeup: Too many open files

I was able to complete running flush_deleted_recgroup.pl by
periodically using Ctrl-S to pause the script, waiting for a few
minutes, then resuming execution with Ctrl-Q on for another few
screenfuls. This did not solve the find_orphans.py issue, however;
that script crashed after only a few deletions. I needed
find_orphans.py to work because it still listed many recordings with
missing files that no longer appeared anywhere in MythFrontend because
of, I presume, the find_orphans.py crashes. (Yes, I ran
optimize_mythdb_pl.)

After consulting
<https://lists.gt.net/mythtv/users/602735/?page=1;mh=-1;>, ulimit -Sn
and -Hn showed soft and hard limits on how many files could be open
simultaneously of 1024 and 4096, respectively. I added to
/etc/security/limits.conf

	* soft nofile 4096
	* hard nofile 20480

This let find_orphans.py successfully complete running. The sum of the
number in "All Programs" and "Deleted" correctly matches the number of
entries in the 'recorded' table in the MythTV database.

I don't know what security issues using the wildcard to raise the
limit for all users causes. After the issue was resolved I changed '*'
to 'root', the user that mythbackend runs under; if the problem recurs
the next time find_orphans.py has many recordings to delete, I'll
change it back to '*'.

-- 
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