<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:<br>
<br>
<br>
>> Stephen:<br>
><br>
><br>
><br>
>The system RAM is 8Gb.  There is a 2Gb swap space.  There are about 3,000<br>
>recordings.  Here is the output from swap.sh:<br>
><br>
><br>
>ken@mythtv:~$ ./swap.sh<br>
><br>
><br>
>..............................<br>
><br>
>Overall swap used: 798096 kB<br>
><br>
><br>
>========================================<br>
><br>
>kB      pid     name<br>
><br>
><br>
>========================================<br>
><br>
>404072  1408    <a href="http://mythfrontend.re" rel="noreferrer noreferrer" target="_blank">mythfrontend.re</a><br>
><br>
>77376   1365    xfdesktop<br>
><br>
>42080   1277    xfwm4<br>
><br>
>38504   1377    applet.py<br>
><br>
>37120   1509    blueman-tray<br>
><br>
>34504   1426    blueman-applet<br>
><br>
>15624   1131    xfce4-session<br>
><br>
>14224   1310    panel-1-whisker<br>
><br>
>12480   1321    panel-10-pulsea<br>
><br>
>12224   1317    panel-8-statusn<br>
><br>
>11536   1314    panel-6-notific<br>
><br>
>10552   1401    update-notifier<br>
><br>
>10216   1411    nm-applet<br>
><br>
>9408    1360    Thunar<br>
><br>
>9336    1282    xfsettingsd<br>
><br>
>8608    1313    panel-5-systray<br>
><br>
>8576    1318    panel-9-power-m<br>
><br>
>8528    1385    xfce4-power-man<br>
><br>
>8240    1315    panel-7-indicat<br>
><br>
>5840    1283    xfce4-panel<br>
><br>
>3280    12076   bash<br>
><br>
>3272    1382    xiccd<br>
><br>
>3032    3791    bash<br>
><br>
>2688    1123    systemd<br>
><br>
>2640    1442    polkit-gnome-au<br>
><br>
>1920    1130    pulseaudio<br>
><br>
>1224    1437    agent<br>
><br>
>504     1145    dbus-daemon<br>
><br>
>248     3784    tmux: server<br>
><br>
>240     1368    mythfrontend<br>
><br>
><br>
>ken@mythtv:~$ free -m<br>
><br>
><br>
>                    total        used        free      shared  buff/cache<br>
>available<br>
>Mem:           7934        2964         202           7        4768<br>
> 4668<br>
><br>
>If it's meaningful the CPU is an Intel i5-2500K 3.3GHz<br>
><br>
>Perhaps I am hitting some limit on number of recordings, but I don't ever<br>
>remember there being a (soft?) limit.<br>
>The system is a bit old, but I would hope it's powerful enough.  I only use<br>
>it as a media center with only MythTv as the main application.<br>
><br>
>Regards,<br>
><br>
>Ken Emerson<br>
<br>
With 8 Gibytes of RAM, it should be fine.  Only 3000 recordings is not<br>
a problem (I have 52880 on an 8 Gibyte frontend/backend system). There<br>
is no fixed limit on recordings - the list can grow as big as your<br>
system will allow, although things do slow down a bit when you have as<br>
many as I do.<br>
<br>
It does look like the swap space is filling up though - I would<br>
suggest increasing that to 8 Gibytes.  But it is currently using<br>
798096 kiB, which is under half full so it is not obvious that it will<br>
run out of swap.<br>
<br>
I have my system and swap partitions on a fast M.2 NVME SSD, which<br>
helps with swapping.<br>
<br>
The free command gives you the total RAM and swap usage.  This is my<br>
system with mythfrontend showing my recordings list:<br>
<br>
root@mypvr:~# free -m<br>
              total        used        free      shared  buff/cache<br>
available<br>
Mem:           7902        2829         120          23        4952<br>
4752<br>
Swap:         10239        1556        8683<br>
<br>
(Sorry about the line wrapping - my email client does that and it is<br>
not able to be turned off).<br>
<br>
So your frontend only system with only 3000 recordings should be just<br>
fine.  So my best guess is that something is triggering a bug that is<br>
causing a memory leak.  But the problem might be in another program,<br>
rather than mythfrontend.  The OOM system is known for killing the<br>
largest RAM user, when the problem program that is suddenly using up<br>
RAM is a different program.<br>
<br>
There was one old bug that caused the cache directory not to be<br>
cleaned up properly, and mythfrontend would then load the cache and<br>
run out of RAM.  That was fixed a while ago, but it is possible that<br>
you still somehow have a huge cache.  So take a look at<br>
$(HOME)/.mythtv/cache and see how big it is:<br>
<br>
root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/<br>
376M    /home/stephen/.mythtv/cache/<br>
376M    total<br>
<br>
This mine now, but when the bug was happening, it was many gibytes. If<br>
yours is too large, shut down mythfrontend and do:<br>
<br>
rm -r $(HOME)/.mythtv/cache<br>
<br>
Mythfrontend should then rebuild the cache as required.<br>
<br>
I would suggest upgrading to v32.  That is the currently supported<br>
version, so if you have a problem that needs the devs to fix it, you<br>
will need to be on v32 for them to be interested.  And it is vaguely<br>
possible your problem may be fixed already in v32-fixes.<br><br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stephen:</blockquote></div></div><div dir="auto">Unfortunately, I decided to take the plunge and upgrade to 32. Looked simple; however, in stuck years ago right at the beginning running mythtv-setup with "Failed to get schema upgrade lock". Can't go back or forward at this point. I have a good DB backup just don't know what to do with it.</div><div dir="auto"><br></div><div dir="auto">Ken Emerson</div><div dir="auto"></div></div>