<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Mon, Jan 13, 2020 at 10:25 PM Michael T. Dean <<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 01/13/2020 09:58 PM, Greg Oliver wrote:<br>
> This has been happening for quite some time now and it is finally <br>
> getting annoying since it happened on CBS and they offer no free <br>
> streaming.<br>
><br>
> Just a simple message """<br>
> N DeleteThread mainserver.cpp:2502 (DeleteRecordedFiles) <br>
> DeleteRecordedFiles - recording id 10569 filename <br>
> /ramdisk/mythtv/recordings/11101_20200108030000.ts<br>
> """<br>
><br>
> Does anyone know what backend debugs I need to turn on to trap these <br>
> messages?<br>
><br>
> I do not want to turn on anything too extra since it is currently <br>
> running on an underpowered machine, but I do need to put an end to it.<br>
><br>
> I have TB of free space and a single StorageGroup, so I know no <br>
> auto-expire is happening.<br>
><br>
<br>
Backend log at default verbosity should tell you exactly why it's <br>
deleting the file (in lines above the one you quoted)<span class="gmail_default" style="font-family:monospace,monospace">.</span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Nothing relevant for sure.  All of the normal recording entries and then the delete entry.</div><br></div><div class="gmail_default" style="font-family:monospace,monospace"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
FWIW, the only reasons I can think of that MythTV would ever delete a <br>
recording without directly being told to do so by a user are: 1) the <br>
recording is in the Deleted recording group (make sure that's not the <br>
case on your recording rule), 2) the recording is Live TV (make sure the <br>
recording rule doesn't use the Live TV recording group), 3) the <br>
recording needs to be autoexpired for low disk space (check your <br>
threshold setting, too), 4) "record new and delete old" is set on the <br>
recording rule and you've reached the max recordings for the rule.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">1.  not in the deleted group</div><div class="gmail_default" style="font-family:monospace,monospace">2.  it is a scheduled recording</div><div class="gmail_default" style="font-family:monospace,monospace">3.  plenty of space</div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note, too, that you might have problems with low disk space if you mount <br>
your recordings disk incorrectly (misconfigure your disk layout).  For <br>
example, if you specify /ramdisk/mythtv/recordings as a directory in <br>
your storage group and you also mount the recordings disk at <br>
/ramdisk/mythtv/recordings, then any time the disk is not mounted, <br>
MythTV will get the available disk space of the parent file <br>
system--which, if it's a ramdisk, could be too small.  Then if some <br>
automounter mounted the file system and MythTV is already in the process <br>
of autoexpiring a recording due to low disk space, it won't stop until <br>
the recording is gone.  The right way to configure your mount point is <br>
to use a subdirectory underneath the mount point--never use the mount <br>
point directory directly.  So, if /ramdisk/mythtv were the mountpoint <br>
for the 1TB+ disk and /ramdisk/mythtv/recordings were the directory for <br>
the storage group, the recordings directory doesn't exist until/unless <br>
the file system is mounted and, therefore, MythTV can't get a file <br>
system available space until/unless the file system is mounted.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">I use a 10Mbyte ramdisk for all of my mount points so my internal storage (OS drive) never fills up when something dies.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">/ramdisk = 10Mbyte ramdisk</div><div class="gmail_default" style="font-family:monospace,monospace">/ramdisk/mythtv is where I mount it and /ramdisk/mythtv/recordings is my SG entry.</div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">It does seem my Max Free Required jumps around...?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div>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<br>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<br><div class="gmail_default" style="font-family:monospace,monospace"></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Oh, and some users have seen files deleted without "user" interaction <br>
because they had MythWeb (or, I could imagine the MythTV Web Frontend) <br>
exposed to the Internet without proper authentication protection--in <br>
which case the person telling MythTV to do the deleting wasn't supposed <br>
to be a user.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Nah, it is running, but definitely not exposed.</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Mike<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</blockquote></div></div>