[mythtv-users] Backend Deleting Files for no Reason - *again*...

[Greg Oliver]

On Mon, Jan 13, 2020 at 10:25 PM Michael T. Dean <mtdean at thirdcontact.com>
wrote:

> On 01/13/2020 09:58 PM, Greg Oliver wrote:
> > This has been happening for quite some time now and it is finally
> > getting annoying since it happened on CBS and they offer no free
> > streaming.
> >
> > Just a simple message """
> > N DeleteThread mainserver.cpp:2502 (DeleteRecordedFiles)
> > DeleteRecordedFiles - recording id 10569 filename
> > /ramdisk/mythtv/recordings/11101_20200108030000.ts
> > """
> >
> > Does anyone know what backend debugs I need to turn on to trap these
> > messages?
> >
> > I do not want to turn on anything too extra since it is currently
> > running on an underpowered machine, but I do need to put an end to it.
> >
> > I have TB of free space and a single StorageGroup, so I know no
> > auto-expire is happening.
> >
>
> Backend log at default verbosity should tell you exactly why it's
> deleting the file (in lines above the one you quoted).


Nothing relevant for sure.  All of the normal recording entries and then
the delete entry.

FWIW, the only reasons I can think of that MythTV would ever delete a
> recording without directly being told to do so by a user are: 1) the
> recording is in the Deleted recording group (make sure that's not the
> case on your recording rule), 2) the recording is Live TV (make sure the
> recording rule doesn't use the Live TV recording group), 3) the
> recording needs to be autoexpired for low disk space (check your
> threshold setting, too), 4) "record new and delete old" is set on the
> recording rule and you've reached the max recordings for the rule.
>

1.  not in the deleted group
2.  it is a scheduled recording
3.  plenty of space
4.  I cannot find that setting in the rule, but everything I have is
"default" (recording groups, playback profiles, etc)..  I have had the
luxury of plenty of space and tuners forever, so never needed to dive into
those settings.

Note, too, that you might have problems with low disk space if you mount
> your recordings disk incorrectly (misconfigure your disk layout).  For
> example, if you specify /ramdisk/mythtv/recordings as a directory in
> your storage group and you also mount the recordings disk at
> /ramdisk/mythtv/recordings, then any time the disk is not mounted,
> MythTV will get the available disk space of the parent file
> system--which, if it's a ramdisk, could be too small.  Then if some
> automounter mounted the file system and MythTV is already in the process
> of autoexpiring a recording due to low disk space, it won't stop until
> the recording is gone.  The right way to configure your mount point is
> to use a subdirectory underneath the mount point--never use the mount
> point directory directly.  So, if /ramdisk/mythtv were the mountpoint
> for the 1TB+ disk and /ramdisk/mythtv/recordings were the directory for
> the storage group, the recordings directory doesn't exist until/unless
> the file system is mounted and, therefore, MythTV can't get a file
> system available space until/unless the file system is mounted.
>

I use a 10Mbyte ramdisk for all of my mount points so my internal storage
(OS drive) never fills up when something dies.

/ramdisk = 10Mbyte ramdisk
/ramdisk/mythtv is where I mount it and /ramdisk/mythtv/recordings is my SG
entry.

I just went through the journal (systemd journal) and dmesg - there are no
disk entries or hiccups around that time (or at all for that matter).  I
have 1GB set in autoexpire and well over a TB free.

It does seem my Max Free Required jumps around...?

Jan 13 21:56:56 mythtv mythbackend[14001]: mythbackend[14001]: N Expire
autoexpire.cpp:261 (CalcParams) AutoExpire: CalcParams(): Max required Free
Space: 3.0 GB w/freq: 7 min
Jan 13 22:03:56 mythtv mythbackend[14001]: mythbackend[14001]: N Expire
autoexpire.cpp:261 (CalcParams) AutoExpire: CalcParams(): Max required Free
Space: 1.0 GB w/freq: 15 min


> Oh, and some users have seen files deleted without "user" interaction
> because they had MythWeb (or, I could imagine the MythTV Web Frontend)
> exposed to the Internet without proper authentication protection--in
> which case the person telling MythTV to do the deleting wasn't supposed
> to be a user.
>

Nah, it is running, but definitely not exposed.



> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200113/4c30f92b/attachment.htm>