<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 5/19/2022 1:03 PM, Kenneth Emerson wrote:<br>
<blockquote type="cite"
cite="mid:CADzwnhWuEjs6LqF+kPKky7=om8Tf9YxSp6pDqg-hcfwij7n=hw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022, 2:53
PM Kenneth Emerson <<a
href="mailto:kenneth.emerson@gmail.com"
moz-do-not-send="true" class="moz-txt-link-freetext">kenneth.emerson@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 11,
2022, 1:04 PM Kenneth Emerson <<a
href="mailto:kenneth.emerson@gmail.com"
target="_blank" rel="noreferrer"
moz-do-not-send="true"
class="moz-txt-link-freetext">kenneth.emerson@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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 noreferrer
noreferrer" target="_blank"
moz-do-not-send="true">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>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Update:</div>
<div dir="auto"><br>
</div>
<div dir="auto">I changed the hostname in the setup
dialog from localhost to mythtv (the actual hostname)
and then rebooted. The master backend ran after the
reboot and asked me if I wanted to upgrade the schema;
answered yes and all I good now; upgraded from 1361 to
1376. Don't fully understand the problem. There were
no clues in the mythtv-setup log. Perhaps the backend
takes care of all that now?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Anyway, sorry for all the cruft. </div>
<div dir="auto"><br>
</div>
<div dir="auto">BTW: 681Mb in .mythtv/cache</div>
<div dir="auto">Will have to wait several weeks to see
if the OOM kill problem is gone.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks for your time and help.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards,</div>
<div dir="auto">Ken Emerson</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">It's been a month now, and I haven't seen a
re-occurance of the OOM killer taking out the frontend;
however, by keeping an eye out on resources I notice that
memory is still tight. I've updated myth to version 32 and
did maintenance on the cache disk space as suggested. This
morning when a OTA program was recording with no one watching
any recordings, the frontend.real task (using top) was using
the majority of resources, both cpu and memory. CPU was 47-80%
range with memory 80-90% range. Along with the frontend,
mythcommflag was also running using minimal resources as was
the backend. frontend.real was always first in listing using
top looking at both cpu and memory. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Using free, there was only about 60mb memory
available (system has 8 gb installed). I don't understand what
the frontend is doing when there is nothing being played back:
just sitting at the recordings menu. I also have a 2gb swap
partition that is also more than 90% consumed.</div>
<div dir="auto"><br>
</div>
<div dir="auto">FYI: This is a dedicated frontend/backend server
with no other services running other than what myth requires.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I've ordered and am now waiting for an
additional 8gb of memory but would appreciate any
enlightenment on what the frontend is busy doing.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards, </div>
<div dir="auto"><br>
</div>
<div dir="auto">Ken Emerson </div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
Could it be the theme? If you're using something other than
MythCenter-wide, I suggest switching and see if that makes a
difference. I've got a v29 backend with 8gb ram, less than 600
recordings, root on an ssd and recordings and video library on three
hdds, so I don't know how useful my stats are. But in case it helps,
here's the output from top with 2 recordings in progress and the
frontend idle:<br>
<br>
top - 20:30:37 up 10 days, 6:13, 2 users, load average: 0.43,
0.42, 0.43<br>
Tasks: 193 total, 1 running, 143 sleeping, 0 stopped, 0 zombie<br>
%Cpu(s): 1.8 us, 1.6 sy, 6.6 ni, 89.6 id, 0.3 wa, 0.0 hi, 0.1
si, 0.0 st<br>
KiB Mem : 7073552 total, 128224 free, 1827240 used, 5118088
buff/cache<br>
KiB Swap: 8388604 total, 8075260 free, 313344 used. 4777420
avail Mem<br>
<br>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND<br>
11089 mythtv 37 17 1300796 82392 48304 S 14.6 1.2 4:13.86
mythcommflag<br>
11072 mythtv 37 17 1298704 81884 48116 S 12.3 1.2 4:05.09
mythcommflag<br>
1618 mythtv 20 0 5246988 1.120g 16648 S 9.9 16.6 230:07.99
mythbackend<br>
1598 buus 20 0 6539112 397308 120608 S 2.0 5.6 257:50.11
mythfrontend.re<br>
<br>
Other details: the CPU is an i3-3220 CPU @ 3.30GHz, .mythtv/cache is
140636 KiB. As part of my monthly maintenance, I remove
.mythtv/cache. I'm in the process of upgrading to v32 on another
bootable partition, but I won't switch over until I've got all my
frontends working the way I like on v32.<br>
<br>
</body>
</html>