[mythtv-users] arrgh, mythtv autoexpired everything - solved

[Michael T. Dean]

On 05/05/2008 08:20 AM, Janne Grunau wrote:
> A not 
> mounted filesystem with not enough space in the root fs shouldn't cause 
> autoexpirer activity since there are no expirable recordings on the 
> filesystem (since there are no recordings at all).
>
> The storage group code can handle missing mounts gracefully if you 
> specify a directory under the mounted filesystem in the storage group. 
> E.g. if your HDD with the recordings is mounted to /video create a 
> directory /video/recordings and use that in mythtv-setup. If /video 
> fails to mount mythtv will detect that /video/recordings is absent and 
> doesn't use it.

Wondering out loud... 

My guess is that the OP has multiple storage group directories on 
multiple filesystems where one filesystem contains both recordings and 
mount points for other filesystems.  So, coupled with a misconfiguration 
of the OP's system--where the OP set up storage group directories that 
were the root directory of filesystems (as described at: 
http://www.gossamer-threads.com/lists/mythtv/users/317235#317235 )--the 
autoexpirer saw that the a recording was requested for a storage group 
directory that normally refers to one of the not-mounted filesystems.  
Since the filesystem wasn't mounted, the autoexpirer determined that the 
"parent" filesystem was the same filesystem as the (not-mounted) 
filesystem containing the mount-point directory.  So, recordings were 
expired from other directories on the parent filesystem.

If this is the case, I don't know how we can prevent it--other than some 
nasty hack, like writing a file to every storage group directory when 
the directory is specified in mythtv-setup.  Then, if that file doesn't 
exist, assume that the filesystem isn't mounted.  (Oh, and the DB update 
for this one would be quite dangerous--as we couldn't verify that the 
proper filesystems were mounted at the time the DB update is run.)

Mike