Mailing List Archive

Hoi Kenneth,

Monday, April 11, 2022, 12:03:35 AM, you wrote:

> Looking for a little help from the group: 
> I'm running v31 fixes on Xubuntu v20.04 and have recently and only
> occasionally have the kernel kill mythfrontend.re for the reason of
> "Out of memory".  It has happened 3 times in the last 4 weeks and a
> total of 6 times since 2020.  It's not a show-stopper, as it does
> recover after about 5-10 minutes (I assume that's the amount of time
> it's using chewing up all the RAM).   There isn't anything of
> interest in the mythfrontend.log file.  Just normal stuff while
> watching a recording.  This is a snippet from kern.log specifically about mythfrontend:


> Apr  9 22:00:03 MythTV kernel: [703811.529409] [  pid  ]   uid
> tgid total_vm      rss pgtables_bytes swapents oom_score_adj name

> Apr  9 22:00:03 MythTV kernel: [703811.529507] [   3635]  1000
> 3635    97165     1257   204800      987             0 xfce4-terminal
> Apr  9 22:00:03 MythTV kernel: [703811.529508] [   3640]  1000
> 3640     2751      196    61440      248             0 bash
> Apr  9 22:00:03 MythTV kernel: [703811.529510] [   3753]  1000
> 3753      652        1    45056       30             0 mythfrontend
> Apr  9 22:00:03 MythTV kernel: [703811.529511] [   3762]  1000
> 3762  3609880  1093884 12263424   307492             0 mythfrontend.re
> Apr  9 22:00:03 MythTV kernel: [703811.529512] [   5513]   107
> 5513     2648       37    53248        5             0 uuidd
> Apr  9 22:00:03 MythTV kernel: [703811.529513] [   8712]   127
> 8712      652        0    40960       23             0 sh
> Apr  9 22:00:03 MythTV kernel: [703811.529514] [   8713]   127
> 8713   768613   462526  4624384    46665             0 mythcommflag


> Has anyone else seen this anomaly?


> Regards,


> Ken Emerson

What other processes are running when it happens? Any memory hungry
programs or badly written ones that could gobble up your memory?
How much memory and swap do you have to start with?
What is the hardware?
etc, etc!

Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 10 Apr 2022 17:03:35 -0500, you wrote:

>Looking for a little help from the group:
>I'm running v31 fixes on Xubuntu v20.04 and have recently and only
>occasionally have the kernel kill mythfrontend.re for the reason of "Out of
>memory". It has happened 3 times in the last 4 weeks and a total of 6
>times since 2020. It's not a show-stopper, as it does recover after about
>5-10 minutes (I assume that's the amount of time it's using chewing up all
>the RAM). There isn't anything of interest in the mythfrontend.log file.
>Just normal stuff while watching a recording. This is a snippet from
>kern.log specifically about mythfrontend:
>
>Apr 9 22:00:03 MythTV kernel: [703811.529409] [ pid ] uid tgid
>total_vm rss pgtables_bytes swapents oom_score_adj name
>Apr 9 22:00:03 MythTV kernel: [703811.529507] [ 3635] 1000 3635
> 97165 1257 204800 987 0 xfce4-terminal
>Apr 9 22:00:03 MythTV kernel: [703811.529508] [ 3640] 1000 3640
>2751 196 61440 248 0 bash
>Apr 9 22:00:03 MythTV kernel: [703811.529510] [ 3753] 1000 3753
> 652 1 45056 30 0 mythfrontend
>Apr 9 22:00:03 MythTV kernel: [703811.529511] [ 3762] 1000 3762
> 3609880 1093884 12263424 307492 0 mythfrontend.re
>Apr 9 22:00:03 MythTV kernel: [703811.529512] [ 5513] 107 5513
>2648 37 53248 5 0 uuidd
>Apr 9 22:00:03 MythTV kernel: [703811.529513] [ 8712] 127 8712
> 652 0 40960 23 0 sh
>Apr 9 22:00:03 MythTV kernel: [703811.529514] [ 8713] 127 8713
>768613 462526 4624384 46665 0 mythcommflag
>
>Has anyone else seen this anomaly?
>
>Regards,
>
>Ken Emerson

There have been some memory leak problems with mythfrontend in the
past, but I have not seen any in v31 or v32. It is possible that you
have just accumulated too many recordings now. Mythfrontend is quite
memory hungry - it keeps the full recording list in RAM. So, how much
RAM does the system have? How much swap space is allocated? How much
swap space is mythfrontend.real using? How many recordings are there?

In general, these days I would recommend using at least 8 Gibytes of
RAM for systems where there are lots of recordings.

To find out what is using swap space, I use this script:

https://gist.github.com/samqiu/5954487

The pmap command will show the RAM usage of a process, but its output
is not easy to interpret. You can get all the available information
about a process from its /proc entry (under its PID number). Pmap
just copies information from some of those entries.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Apr 10, 2022 at 10:23 PM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 10 Apr 2022 17:03:35 -0500, you wrote:
>
> >Looking for a little help from the group:
> >I'm running v31 fixes on Xubuntu v20.04 and have recently and only
> >occasionally have the kernel kill mythfrontend.re for the reason of "Out
> of
> >memory". It has happened 3 times in the last 4 weeks and a total of 6
> >times since 2020. It's not a show-stopper, as it does recover after about
> >5-10 minutes (I assume that's the amount of time it's using chewing up all
> >the RAM). There isn't anything of interest in the mythfrontend.log file.
> >Just normal stuff while watching a recording. This is a snippet from
> >kern.log specifically about mythfrontend:
> >
> >Apr 9 22:00:03 MythTV kernel: [703811.529409] [ pid ] uid tgid
> >total_vm rss pgtables_bytes swapents oom_score_adj name
> >Apr 9 22:00:03 MythTV kernel: [703811.529507] [ 3635] 1000 3635
> > 97165 1257 204800 987 0 xfce4-terminal
> >Apr 9 22:00:03 MythTV kernel: [703811.529508] [ 3640] 1000 3640
> >2751 196 61440 248 0 bash
> >Apr 9 22:00:03 MythTV kernel: [703811.529510] [ 3753] 1000 3753
> > 652 1 45056 30 0 mythfrontend
> >Apr 9 22:00:03 MythTV kernel: [703811.529511] [ 3762] 1000 3762
> > 3609880 1093884 12263424 307492 0 mythfrontend.re
> >Apr 9 22:00:03 MythTV kernel: [703811.529512] [ 5513] 107 5513
> >2648 37 53248 5 0 uuidd
> >Apr 9 22:00:03 MythTV kernel: [703811.529513] [ 8712] 127 8712
> > 652 0 40960 23 0 sh
> >Apr 9 22:00:03 MythTV kernel: [703811.529514] [ 8713] 127 8713
> >768613 462526 4624384 46665 0 mythcommflag
> >
> >Has anyone else seen this anomaly?
> >
> >Regards,
> >
> >Ken Emerson
>
> There have been some memory leak problems with mythfrontend in the
> past, but I have not seen any in v31 or v32. It is possible that you
> have just accumulated too many recordings now. Mythfrontend is quite
> memory hungry - it keeps the full recording list in RAM. So, how much
> RAM does the system have? How much swap space is allocated? How much
> swap space is mythfrontend.real using? How many recordings are there?
>
> In general, these days I would recommend using at least 8 Gibytes of
> RAM for systems where there are lots of recordings.
>
> To find out what is using swap space, I use this script:
>
> https://gist.github.com/samqiu/5954487
>
> The pmap command will show the RAM usage of a process, but its output
> is not easy to interpret. You can get all the available information
> about a process from its /proc entry (under its PID number). Pmap
> just copies information from some of those entries.
> _______________________________________________
> Stephen:



The system RAM is 8Gb. There is a 2Gb swap space. There are about 3,000
recordings. Here is the output from swap.sh:


ken@mythtv:~$ ./swap.sh


..............................

Overall swap used: 798096 kB


========================================

kB pid name


========================================

404072 1408 mythfrontend.re

77376 1365 xfdesktop

42080 1277 xfwm4

38504 1377 applet.py

37120 1509 blueman-tray

34504 1426 blueman-applet

15624 1131 xfce4-session

14224 1310 panel-1-whisker

12480 1321 panel-10-pulsea

12224 1317 panel-8-statusn

11536 1314 panel-6-notific

10552 1401 update-notifier

10216 1411 nm-applet

9408 1360 Thunar

9336 1282 xfsettingsd

8608 1313 panel-5-systray

8576 1318 panel-9-power-m

8528 1385 xfce4-power-man

8240 1315 panel-7-indicat

5840 1283 xfce4-panel

3280 12076 bash

3272 1382 xiccd

3032 3791 bash

2688 1123 systemd

2640 1442 polkit-gnome-au

1920 1130 pulseaudio

1224 1437 agent

504 1145 dbus-daemon

248 3784 tmux: server

240 1368 mythfrontend


ken@mythtv:~$ free -m


total used free shared buff/cache
available
Mem: 7934 2964 202 7 4768
4668

If it's meaningful the CPU is an Intel i5-2500K 3.3GHz

Perhaps I am hitting some limit on number of recordings, but I don't ever
remember there being a (soft?) limit.
The system is a bit old, but I would hope it's powerful enough. I only use
it as a media center with only MythTv as the main application.

Regards,

Ken Emerson

On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:


>> Stephen:
>
>
>
>The system RAM is 8Gb. There is a 2Gb swap space. There are about 3,000
>recordings. Here is the output from swap.sh:
>
>
>ken@mythtv:~$ ./swap.sh
>
>
>..............................
>
>Overall swap used: 798096 kB
>
>
>========================================
>
>kB pid name
>
>
>========================================
>
>404072 1408 mythfrontend.re
>
>77376 1365 xfdesktop
>
>42080 1277 xfwm4
>
>38504 1377 applet.py
>
>37120 1509 blueman-tray
>
>34504 1426 blueman-applet
>
>15624 1131 xfce4-session
>
>14224 1310 panel-1-whisker
>
>12480 1321 panel-10-pulsea
>
>12224 1317 panel-8-statusn
>
>11536 1314 panel-6-notific
>
>10552 1401 update-notifier
>
>10216 1411 nm-applet
>
>9408 1360 Thunar
>
>9336 1282 xfsettingsd
>
>8608 1313 panel-5-systray
>
>8576 1318 panel-9-power-m
>
>8528 1385 xfce4-power-man
>
>8240 1315 panel-7-indicat
>
>5840 1283 xfce4-panel
>
>3280 12076 bash
>
>3272 1382 xiccd
>
>3032 3791 bash
>
>2688 1123 systemd
>
>2640 1442 polkit-gnome-au
>
>1920 1130 pulseaudio
>
>1224 1437 agent
>
>504 1145 dbus-daemon
>
>248 3784 tmux: server
>
>240 1368 mythfrontend
>
>
>ken@mythtv:~$ free -m
>
>
> total used free shared buff/cache
>available
>Mem: 7934 2964 202 7 4768
> 4668
>
>If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
>
>Perhaps I am hitting some limit on number of recordings, but I don't ever
>remember there being a (soft?) limit.
>The system is a bit old, but I would hope it's powerful enough. I only use
>it as a media center with only MythTv as the main application.
>
>Regards,
>
>Ken Emerson

With 8 Gibytes of RAM, it should be fine. Only 3000 recordings is not
a problem (I have 52880 on an 8 Gibyte frontend/backend system). There
is no fixed limit on recordings - the list can grow as big as your
system will allow, although things do slow down a bit when you have as
many as I do.

It does look like the swap space is filling up though - I would
suggest increasing that to 8 Gibytes. But it is currently using
798096 kiB, which is under half full so it is not obvious that it will
run out of swap.

I have my system and swap partitions on a fast M.2 NVME SSD, which
helps with swapping.

The free command gives you the total RAM and swap usage. This is my
system with mythfrontend showing my recordings list:

root@mypvr:~# free -m
total used free shared buff/cache
available
Mem: 7902 2829 120 23 4952
4752
Swap: 10239 1556 8683

(Sorry about the line wrapping - my email client does that and it is
not able to be turned off).

So your frontend only system with only 3000 recordings should be just
fine. So my best guess is that something is triggering a bug that is
causing a memory leak. But the problem might be in another program,
rather than mythfrontend. The OOM system is known for killing the
largest RAM user, when the problem program that is suddenly using up
RAM is a different program.

There was one old bug that caused the cache directory not to be
cleaned up properly, and mythfrontend would then load the cache and
run out of RAM. That was fixed a while ago, but it is possible that
you still somehow have a huge cache. So take a look at
$(HOME)/.mythtv/cache and see how big it is:

root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
376M /home/stephen/.mythtv/cache/
376M total

This mine now, but when the bug was happening, it was many gibytes. If
yours is too large, shut down mythfrontend and do:

rm -r $(HOME)/.mythtv/cache

Mythfrontend should then rebuild the cache as required.

I would suggest upgrading to v32. That is the currently supported
version, so if you have a problem that needs the devs to fix it, you
will need to be on v32 for them to be interested. And it is vaguely
possible your problem may be fixed already in v32-fixes.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <stephen_agent@jsw.gen.nz>
wrote:

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

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.

Ken Emerson

On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <kenneth.emerson@gmail.com>
wrote:

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

Update:

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?

Anyway, sorry for all the cruft.

BTW: 681Mb in .mythtv/cache
Will have to wait several weeks to see if the OOM kill problem is gone.

Thanks for your time and help.

>
Regards,
Ken Emerson

>
>

On Mon, 11 Apr 2022 13:04:13 -0500, you wrote:


>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.
>
>Ken Emerson

The recommended method of upgrading is to use mythtv-setup to do the
schema upgrade, but in order to do that, you have to remember to
prevent mythbackend from being automatically restarted after MythTV is
updated:

sudo systemctl disable mythtv-backend

So by the time you ran mythtv-setup, mythbackend was already running
and in the middle of doing the schema upgrade. Unless there is
actually a problem with the schema upgrade (rare), then letting
mythbackend do it is not a problem. After running mythtv-setup, you
are then supposed to re-enable and restart mythbackend:

sudo systemctl enable --now mythtv-backend

Also, when doing any update where a repository has changed, you are
supposed to use the command:

sudo apt full-upgrade

rather than the usual:

sudo apt upgrade

If you did not do that, you need to run full-upgrade now, as otherwise
it is possible to have a situation where some packages did not upgrade
correctly (usually, libmythtv does not get upgraded properly).

Personally, I now normally run apt full-upgrade unless there is a
specific reason not to.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

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

That bit is easy. Install from new then mythconverg_restore.
For me, fumbled something, and restored ‘broken’ cards. Steven explained howto avoid that, what I did was (1) clean install (2) edit a copy of the backup (with vim - the backup is big) delete everything except `video-something` tables that were not empty restore those manually:

$ sudo mysql mythconverg < modified_backup

(in the olden days $ was the prompt and writing $ ment enter in a terminal)
Voila all videos and metadata restored.
James


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson <kenneth.emerson@gmail.com>
wrote:

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

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.

FYI: This is a dedicated frontend/backend server with no other services
running other than what myth requires.

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.

Regards,

Ken Emerson

>

On 5/19/2022 10:03 AM, Kenneth Emerson wrote:
>
>
> On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson
> <kenneth.emerson@gmail.com> wrote:
>
>
>
> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson
> <kenneth.emerson@gmail.com> wrote:
>
>
>
> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington
> <stephen_agent@jsw.gen.nz> wrote:
>
> On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:
>
>
> >> Stephen:
> >
> >
> >
> >The system RAM is 8Gb.  There is a 2Gb swap space.  There
> are about 3,000
> >recordings.  Here is the output from swap.sh:
> >
> >
> >ken@mythtv:~$ ./swap.sh
> >
> >
> >..............................
> >
> >Overall swap used: 798096 kB
> >
> >
> >========================================
> >
> >kB      pid     name
> >
> >
> >========================================
> >
> >404072  1408 mythfrontend.re <http://mythfrontend.re>
> >
> >77376   1365    xfdesktop
> >
> >42080   1277    xfwm4
> >
> >38504   1377    applet.py
> >
> >37120   1509    blueman-tray
> >
> >34504   1426    blueman-applet
> >
> >15624   1131    xfce4-session
> >
> >14224   1310    panel-1-whisker
> >
> >12480   1321    panel-10-pulsea
> >
> >12224   1317    panel-8-statusn
> >
> >11536   1314    panel-6-notific
> >
> >10552   1401    update-notifier
> >
> >10216   1411    nm-applet
> >
> >9408    1360    Thunar
> >
> >9336    1282    xfsettingsd
> >
> >8608    1313    panel-5-systray
> >
> >8576    1318    panel-9-power-m
> >
> >8528    1385    xfce4-power-man
> >
> >8240    1315    panel-7-indicat
> >
> >5840    1283    xfce4-panel
> >
> >3280    12076   bash
> >
> >3272    1382    xiccd
> >
> >3032    3791    bash
> >
> >2688    1123    systemd
> >
> >2640    1442    polkit-gnome-au
> >
> >1920    1130    pulseaudio
> >
> >1224    1437    agent
> >
> >504     1145    dbus-daemon
> >
> >248     3784    tmux: server
> >
> >240     1368    mythfrontend
> >
> >
> >ken@mythtv:~$ free -m
> >
> >
> >                    total        used       free     
> shared  buff/cache
> >available
> >Mem:           7934        2964  202           7        4768
> > 4668
> >
> >If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
> >
> >Perhaps I am hitting some limit on number of recordings,
> but I don't ever
> >remember there being a (soft?) limit.
> >The system is a bit old, but I would hope it's powerful
> enough.  I only use
> >it as a media center with only MythTv as the main
> application.
> >
> >Regards,
> >
> >Ken Emerson
>
> With 8 Gibytes of RAM, it should be fine. Only 3000
> recordings is not
> a problem (I have 52880 on an 8 Gibyte frontend/backend
> system). There
> is no fixed limit on recordings - the list can grow as big
> as your
> system will allow, although things do slow down a bit when
> you have as
> many as I do.
>
> It does look like the swap space is filling up though - I
> would
> suggest increasing that to 8 Gibytes.  But it is currently
> using
> 798096 kiB, which is under half full so it is not obvious
> that it will
> run out of swap.
>
> I have my system and swap partitions on a fast M.2 NVME
> SSD, which
> helps with swapping.
>
> The free command gives you the total RAM and swap usage. 
> This is my
> system with mythfrontend showing my recordings list:
>
> root@mypvr:~# free -m
>               total        used free      shared  buff/cache
> available
> Mem:           7902        2829  120          23        4952
> 4752
> Swap:         10239        1556 8683
>
> (Sorry about the line wrapping - my email client does that
> and it is
> not able to be turned off).
>
> So your frontend only system with only 3000 recordings
> should be just
> fine.  So my best guess is that something is triggering a
> bug that is
> causing a memory leak.  But the problem might be in
> another program,
> rather than mythfrontend.  The OOM system is known for
> killing the
> largest RAM user, when the problem program that is
> suddenly using up
> RAM is a different program.
>
> There was one old bug that caused the cache directory not
> to be
> cleaned up properly, and mythfrontend would then load the
> cache and
> run out of RAM.  That was fixed a while ago, but it is
> possible that
> you still somehow have a huge cache.  So take a look at
> $(HOME)/.mythtv/cache and see how big it is:
>
> root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
> 376M    /home/stephen/.mythtv/cache/
> 376M    total
>
> This mine now, but when the bug was happening, it was many
> gibytes. If
> yours is too large, shut down mythfrontend and do:
>
> rm -r $(HOME)/.mythtv/cache
>
> Mythfrontend should then rebuild the cache as required.
>
> I would suggest upgrading to v32.  That is the currently
> supported
> version, so if you have a problem that needs the devs to
> fix it, you
> will need to be on v32 for them to be interested.  And it
> is vaguely
> possible your problem may be fixed already in v32-fixes.
>
>
> Stephen:
>
> 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.
>
> Ken Emerson
>
>
> Update:
>
> 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?
>
> Anyway, sorry for all the cruft.
>
> BTW: 681Mb in .mythtv/cache
> Will have to wait several weeks to see if the OOM kill problem is
> gone.
>
> Thanks for your time and help.
>
> Regards,
> Ken Emerson
>
>
> 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.
>
> 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.
>
> FYI: This is a dedicated frontend/backend server with no other
> services running other than what myth requires.
>
> 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.
>
> Regards,
>
> Ken Emerson
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
My combined FE/BE also has 8GB or RAM and has no issues (running 0.28). 
Something to keep in mind when looking at how much RAM is 'free'
(/proc/meminfo) is that the linux kernel will use any available RAM for
caching, so the reported free RAM is usually low. This is not indicative
of a problem (i.e., memory leak).
Jay

On Thu, May 19, 2022 at 12:19 PM Jay Foster <jayf0ster@roadrunner.com>
wrote:

> On 5/19/2022 10:03 AM, Kenneth Emerson wrote:
>
>
>
> On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson <kenneth.emerson@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <kenneth.emerson@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <
>>> stephen_agent@jsw.gen.nz> wrote:
>>>
>>>> On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:
>>>>
>>>>
>>>> >> Stephen:
>>>> >
>>>> >
>>>> >
>>>> >The system RAM is 8Gb. There is a 2Gb swap space. There are about
>>>> 3,000
>>>> >recordings. Here is the output from swap.sh:
>>>> >
>>>> >
>>>> >ken@mythtv:~$ ./swap.sh
>>>> >
>>>> >
>>>> >..............................
>>>> >
>>>> >Overall swap used: 798096 kB
>>>> >
>>>> >
>>>> >========================================
>>>> >
>>>> >kB pid name
>>>> >
>>>> >
>>>> >========================================
>>>> >
>>>> >404072 1408 mythfrontend.re
>>>> >
>>>> >77376 1365 xfdesktop
>>>> >
>>>> >42080 1277 xfwm4
>>>> >
>>>> >38504 1377 applet.py
>>>> >
>>>> >37120 1509 blueman-tray
>>>> >
>>>> >34504 1426 blueman-applet
>>>> >
>>>> >15624 1131 xfce4-session
>>>> >
>>>> >14224 1310 panel-1-whisker
>>>> >
>>>> >12480 1321 panel-10-pulsea
>>>> >
>>>> >12224 1317 panel-8-statusn
>>>> >
>>>> >11536 1314 panel-6-notific
>>>> >
>>>> >10552 1401 update-notifier
>>>> >
>>>> >10216 1411 nm-applet
>>>> >
>>>> >9408 1360 Thunar
>>>> >
>>>> >9336 1282 xfsettingsd
>>>> >
>>>> >8608 1313 panel-5-systray
>>>> >
>>>> >8576 1318 panel-9-power-m
>>>> >
>>>> >8528 1385 xfce4-power-man
>>>> >
>>>> >8240 1315 panel-7-indicat
>>>> >
>>>> >5840 1283 xfce4-panel
>>>> >
>>>> >3280 12076 bash
>>>> >
>>>> >3272 1382 xiccd
>>>> >
>>>> >3032 3791 bash
>>>> >
>>>> >2688 1123 systemd
>>>> >
>>>> >2640 1442 polkit-gnome-au
>>>> >
>>>> >1920 1130 pulseaudio
>>>> >
>>>> >1224 1437 agent
>>>> >
>>>> >504 1145 dbus-daemon
>>>> >
>>>> >248 3784 tmux: server
>>>> >
>>>> >240 1368 mythfrontend
>>>> >
>>>> >
>>>> >ken@mythtv:~$ free -m
>>>> >
>>>> >
>>>> > total used free shared
>>>> buff/cache
>>>> >available
>>>> >Mem: 7934 2964 202 7 4768
>>>> > 4668
>>>> >
>>>> >If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
>>>> >
>>>> >Perhaps I am hitting some limit on number of recordings, but I don't
>>>> ever
>>>> >remember there being a (soft?) limit.
>>>> >The system is a bit old, but I would hope it's powerful enough. I
>>>> only use
>>>> >it as a media center with only MythTv as the main application.
>>>> >
>>>> >Regards,
>>>> >
>>>> >Ken Emerson
>>>>
>>>> With 8 Gibytes of RAM, it should be fine. Only 3000 recordings is not
>>>> a problem (I have 52880 on an 8 Gibyte frontend/backend system). There
>>>> is no fixed limit on recordings - the list can grow as big as your
>>>> system will allow, although things do slow down a bit when you have as
>>>> many as I do.
>>>>
>>>> It does look like the swap space is filling up though - I would
>>>> suggest increasing that to 8 Gibytes. But it is currently using
>>>> 798096 kiB, which is under half full so it is not obvious that it will
>>>> run out of swap.
>>>>
>>>> I have my system and swap partitions on a fast M.2 NVME SSD, which
>>>> helps with swapping.
>>>>
>>>> The free command gives you the total RAM and swap usage. This is my
>>>> system with mythfrontend showing my recordings list:
>>>>
>>>> root@mypvr:~# free -m
>>>> total used free shared buff/cache
>>>> available
>>>> Mem: 7902 2829 120 23 4952
>>>> 4752
>>>> Swap: 10239 1556 8683
>>>>
>>>> (Sorry about the line wrapping - my email client does that and it is
>>>> not able to be turned off).
>>>>
>>>> So your frontend only system with only 3000 recordings should be just
>>>> fine. So my best guess is that something is triggering a bug that is
>>>> causing a memory leak. But the problem might be in another program,
>>>> rather than mythfrontend. The OOM system is known for killing the
>>>> largest RAM user, when the problem program that is suddenly using up
>>>> RAM is a different program.
>>>>
>>>> There was one old bug that caused the cache directory not to be
>>>> cleaned up properly, and mythfrontend would then load the cache and
>>>> run out of RAM. That was fixed a while ago, but it is possible that
>>>> you still somehow have a huge cache. So take a look at
>>>> $(HOME)/.mythtv/cache and see how big it is:
>>>>
>>>> root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
>>>> 376M /home/stephen/.mythtv/cache/
>>>> 376M total
>>>>
>>>> This mine now, but when the bug was happening, it was many gibytes. If
>>>> yours is too large, shut down mythfrontend and do:
>>>>
>>>> rm -r $(HOME)/.mythtv/cache
>>>>
>>>> Mythfrontend should then rebuild the cache as required.
>>>>
>>>> I would suggest upgrading to v32. That is the currently supported
>>>> version, so if you have a problem that needs the devs to fix it, you
>>>> will need to be on v32 for them to be interested. And it is vaguely
>>>> possible your problem may be fixed already in v32-fixes.
>>>>
>>>>
>>>> Stephen:
>>>
>>> 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.
>>>
>>> Ken Emerson
>>>
>>
>> Update:
>>
>> 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?
>>
>> Anyway, sorry for all the cruft.
>>
>> BTW: 681Mb in .mythtv/cache
>> Will have to wait several weeks to see if the OOM kill problem is gone.
>>
>> Thanks for your time and help.
>>
>> Regards,
>> Ken Emerson
>>
>
> 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.
>
> 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.
>
> FYI: This is a dedicated frontend/backend server with no other services
> running other than what myth requires.
>
> 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.
>
> Regards,
>
> Ken Emerson
>
>>
> _______________________________________________
> mythtv-users mailing listmythtv-users@mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
> My combined FE/BE also has 8GB or RAM and has no issues (running 0.28).
> Something to keep in mind when looking at how much RAM is 'free'
> (/proc/meminfo) is that the linux kernel will use any available RAM for
> caching, so the reported free RAM is usually low. This is not indicative
> of a problem (i.e., memory leak).
> Jay
>
> Thanks for the input. The problem seems to be intermittent. I'm looking
at the memory now with two programs recording (just for a test). The
results from the 'free' command are:

total used free shared buff/cache
available
Mem: 7.7Gi 6.8Gi 130Mi 5.0Mi 884Mi
752Mi
Swap: 2.0Gi 2.0Gi 0B

With the exception of the swap numbers, this seems reasonable. Maybe
everything is fine. Watching the numbers it appears the kernel is doing
what it's supposed to do. I still don't understand why swap is getting
used. I'll see what happens when I add the addtional 8Gb of RAM next week.

Regards,

Ken Emerson

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

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:

top - 20:30:37 up 10 days,  6:13,  2 users,  load average: 0.43, 0.42, 0.43
Tasks: 193 total,   1 running, 143 sleeping,   0 stopped,   0 zombie
%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
KiB Mem :  7073552 total,   128224 free,  1827240 used,  5118088 buff/cache
KiB Swap:  8388604 total,  8075260 free,   313344 used.  4777420 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
11089 mythtv    37  17 1300796  82392  48304 S  14.6  1.2   4:13.86
mythcommflag
11072 mythtv    37  17 1298704  81884  48116 S  12.3  1.2   4:05.09
mythcommflag
 1618 mythtv    20   0 5246988 1.120g  16648 S   9.9 16.6 230:07.99
mythbackend
 1598 buus      20   0 6539112 397308 120608 S   2.0  5.6 257:50.11
mythfrontend.re

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.

> On 20 May 2022, at 4:30 am, Kenneth Emerson <kenneth.emerson@gmail.com> wrote:
>
>
>
> On Thu, May 19, 2022 at 12:19 PM Jay Foster <jayf0ster@roadrunner.com> wrote:
> On 5/19/2022 10:03 AM, Kenneth Emerson wrote:
>>
>>
>> On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson <kenneth.emerson@gmail.com> wrote:
>>
>>
>> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <kenneth.emerson@gmail.com> wrote:
>>
>>
>> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>> On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:
>>
>>
>> >> Stephen:
>> >
>> >
>> >
>> >The system RAM is 8Gb. There is a 2Gb swap space. There are about 3,000
>> >recordings. Here is the output from swap.sh:
>> >
>> >
>> >ken@mythtv:~$ ./swap.sh
>> >
>> >
>> >..............................
>> >
>> >Overall swap used: 798096 kB
>> >
>> >
>> >========================================
>> >
>> >kB pid name
>> >
>> >
>> >========================================
>> >
>> >404072 1408 mythfrontend.re
>> >
>> >77376 1365 xfdesktop
>> >
>> >42080 1277 xfwm4
>> >
>> >38504 1377 applet.py
>> >
>> >37120 1509 blueman-tray
>> >
>> >34504 1426 blueman-applet
>> >
>> >15624 1131 xfce4-session
>> >
>> >14224 1310 panel-1-whisker
>> >
>> >12480 1321 panel-10-pulsea
>> >
>> >12224 1317 panel-8-statusn
>> >
>> >11536 1314 panel-6-notific
>> >
>> >10552 1401 update-notifier
>> >
>> >10216 1411 nm-applet
>> >
>> >9408 1360 Thunar
>> >
>> >9336 1282 xfsettingsd
>> >
>> >8608 1313 panel-5-systray
>> >
>> >8576 1318 panel-9-power-m
>> >
>> >8528 1385 xfce4-power-man
>> >
>> >8240 1315 panel-7-indicat
>> >
>> >5840 1283 xfce4-panel
>> >
>> >3280 12076 bash
>> >
>> >3272 1382 xiccd
>> >
>> >3032 3791 bash
>> >
>> >2688 1123 systemd
>> >
>> >2640 1442 polkit-gnome-au
>> >
>> >1920 1130 pulseaudio
>> >
>> >1224 1437 agent
>> >
>> >504 1145 dbus-daemon
>> >
>> >248 3784 tmux: server
>> >
>> >240 1368 mythfrontend
>> >
>> >
>> >ken@mythtv:~$ free -m
>> >
>> >
>> > total used free shared buff/cache
>> >available
>> >Mem: 7934 2964 202 7 4768
>> > 4668
>> >
>> >If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
>> >
>> >Perhaps I am hitting some limit on number of recordings, but I don't ever
>> >remember there being a (soft?) limit.
>> >The system is a bit old, but I would hope it's powerful enough. I only use
>> >it as a media center with only MythTv as the main application.
>> >
>> >Regards,
>> >
>> >Ken Emerson
>>
>> With 8 Gibytes of RAM, it should be fine. Only 3000 recordings is not
>> a problem (I have 52880 on an 8 Gibyte frontend/backend system). There
>> is no fixed limit on recordings - the list can grow as big as your
>> system will allow, although things do slow down a bit when you have as
>> many as I do.
>>
>> It does look like the swap space is filling up though - I would
>> suggest increasing that to 8 Gibytes. But it is currently using
>> 798096 kiB, which is under half full so it is not obvious that it will
>> run out of swap.
>>
>> I have my system and swap partitions on a fast M.2 NVME SSD, which
>> helps with swapping.
>>
>> The free command gives you the total RAM and swap usage. This is my
>> system with mythfrontend showing my recordings list:
>>
>> root@mypvr:~# free -m
>> total used free shared buff/cache
>> available
>> Mem: 7902 2829 120 23 4952
>> 4752
>> Swap: 10239 1556 8683
>>
>> (Sorry about the line wrapping - my email client does that and it is
>> not able to be turned off).
>>
>> So your frontend only system with only 3000 recordings should be just
>> fine. So my best guess is that something is triggering a bug that is
>> causing a memory leak. But the problem might be in another program,
>> rather than mythfrontend. The OOM system is known for killing the
>> largest RAM user, when the problem program that is suddenly using up
>> RAM is a different program.
>>
>> There was one old bug that caused the cache directory not to be
>> cleaned up properly, and mythfrontend would then load the cache and
>> run out of RAM. That was fixed a while ago, but it is possible that
>> you still somehow have a huge cache. So take a look at
>> $(HOME)/.mythtv/cache and see how big it is:
>>
>> root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
>> 376M /home/stephen/.mythtv/cache/
>> 376M total
>>
>> This mine now, but when the bug was happening, it was many gibytes. If
>> yours is too large, shut down mythfrontend and do:
>>
>> rm -r $(HOME)/.mythtv/cache
>>
>> Mythfrontend should then rebuild the cache as required.
>>
>> I would suggest upgrading to v32. That is the currently supported
>> version, so if you have a problem that needs the devs to fix it, you
>> will need to be on v32 for them to be interested. And it is vaguely
>> possible your problem may be fixed already in v32-fixes.
>>
>>
>> Stephen:
>> 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.
>>
>> Ken Emerson
>>
>> Update:
>>
>> 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?
>>
>> Anyway, sorry for all the cruft.
>>
>> BTW: 681Mb in .mythtv/cache
>> Will have to wait several weeks to see if the OOM kill problem is gone.
>>
>> Thanks for your time and help.
>>
>> Regards,
>> Ken Emerson
>>
>> 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.
>>
>> 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.
>>
>> FYI: This is a dedicated frontend/backend server with no other services running other than what myth requires.
>>
>> 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.
>>
>> Regards,
>>
>> Ken Emerson
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>>
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>>
>> MythTV Forums:
>> https://forum.mythtv.org
> My combined FE/BE also has 8GB or RAM and has no issues (running 0.28). Something to keep in mind when looking at how much RAM is 'free' (/proc/meminfo) is that the linux kernel will use any available RAM for caching, so the reported free RAM is usually low. This is not indicative of a problem (i.e., memory leak).
> Jay
>
> Thanks for the input. The problem seems to be intermittent. I'm looking at the memory now with two programs recording (just for a test). The results from the 'free' command are:
>
> total used free shared buff/cache available
> Mem: 7.7Gi 6.8Gi 130Mi 5.0Mi 884Mi 752Mi
> Swap: 2.0Gi 2.0Gi 0B
>
> With the exception of the swap numbers, this seems reasonable. Maybe everything is fine. Watching the numbers it appears the kernel is doing what it's supposed to do. I still don't understand why swap is getting used. I'll see what happens when I add the addtional 8Gb of RAM next week.

The trouble is when us mere mortals try to understand ,,,
If you have oodles of ram and some of it is untouched (as opposed to unused) then the kernel will swap that out so that you’ve got more cache that is *touched* and there are *signicant* arguments on ram vs swap with tuning available.
So you might go from

4G used 4G free swap 0
to
2G used 6G free swap 2G

eg consider these

'echo 'vm.swappiness=1' > /etc/sysctl.d/99-sysctl.conf'
'echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.d/99-sysctl.conf’

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Fri, May 20, 2022 at 10:36 AM James Linder <jam@tigger.ws> wrote:

>
>
> > On 20 May 2022, at 4:30 am, Kenneth Emerson <kenneth.emerson@gmail.com>
> wrote:
> >
> >
> >
> > On Thu, May 19, 2022 at 12:19 PM Jay Foster <jayf0ster@roadrunner.com>
> wrote:
> > On 5/19/2022 10:03 AM, Kenneth Emerson wrote:
> >>
> >>
> >> On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson <
> kenneth.emerson@gmail.com> wrote:
> >>
> >>
> >> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <
> kenneth.emerson@gmail.com> wrote:
> >>
> >>
> >> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
> >> On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:
> >>
> >>
> >> >> Stephen:
> >> >
> >> >
> >> >
> >> >The system RAM is 8Gb. There is a 2Gb swap space. There are about
> 3,000
> >> >recordings. Here is the output from swap.sh:
> >> >
> >> >
> >> >ken@mythtv:~$ ./swap.sh
> >> >
> >> >
> >> >..............................
> >> >
> >> >Overall swap used: 798096 kB
> >> >
> >> >
> >> >========================================
> >> >
> >> >kB pid name
> >> >
> >> >
> >> >========================================
> >> >
> >> >404072 1408 mythfrontend.re
> >> >
> >> >77376 1365 xfdesktop
> >> >
> >> >42080 1277 xfwm4
> >> >
> >> >38504 1377 applet.py
> >> >
> >> >37120 1509 blueman-tray
> >> >
> >> >34504 1426 blueman-applet
> >> >
> >> >15624 1131 xfce4-session
> >> >
> >> >14224 1310 panel-1-whisker
> >> >
> >> >12480 1321 panel-10-pulsea
> >> >
> >> >12224 1317 panel-8-statusn
> >> >
> >> >11536 1314 panel-6-notific
> >> >
> >> >10552 1401 update-notifier
> >> >
> >> >10216 1411 nm-applet
> >> >
> >> >9408 1360 Thunar
> >> >
> >> >9336 1282 xfsettingsd
> >> >
> >> >8608 1313 panel-5-systray
> >> >
> >> >8576 1318 panel-9-power-m
> >> >
> >> >8528 1385 xfce4-power-man
> >> >
> >> >8240 1315 panel-7-indicat
> >> >
> >> >5840 1283 xfce4-panel
> >> >
> >> >3280 12076 bash
> >> >
> >> >3272 1382 xiccd
> >> >
> >> >3032 3791 bash
> >> >
> >> >2688 1123 systemd
> >> >
> >> >2640 1442 polkit-gnome-au
> >> >
> >> >1920 1130 pulseaudio
> >> >
> >> >1224 1437 agent
> >> >
> >> >504 1145 dbus-daemon
> >> >
> >> >248 3784 tmux: server
> >> >
> >> >240 1368 mythfrontend
> >> >
> >> >
> >> >ken@mythtv:~$ free -m
> >> >
> >> >
> >> > total used free shared
> buff/cache
> >> >available
> >> >Mem: 7934 2964 202 7 4768
> >> > 4668
> >> >
> >> >If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
> >> >
> >> >Perhaps I am hitting some limit on number of recordings, but I don't
> ever
> >> >remember there being a (soft?) limit.
> >> >The system is a bit old, but I would hope it's powerful enough. I
> only use
> >> >it as a media center with only MythTv as the main application.
> >> >
> >> >Regards,
> >> >
> >> >Ken Emerson
> >>
> >> With 8 Gibytes of RAM, it should be fine. Only 3000 recordings is not
> >> a problem (I have 52880 on an 8 Gibyte frontend/backend system). There
> >> is no fixed limit on recordings - the list can grow as big as your
> >> system will allow, although things do slow down a bit when you have as
> >> many as I do.
> >>
> >> It does look like the swap space is filling up though - I would
> >> suggest increasing that to 8 Gibytes. But it is currently using
> >> 798096 kiB, which is under half full so it is not obvious that it will
> >> run out of swap.
> >>
> >> I have my system and swap partitions on a fast M.2 NVME SSD, which
> >> helps with swapping.
> >>
> >> The free command gives you the total RAM and swap usage. This is my
> >> system with mythfrontend showing my recordings list:
> >>
> >> root@mypvr:~# free -m
> >> total used free shared buff/cache
> >> available
> >> Mem: 7902 2829 120 23 4952
> >> 4752
> >> Swap: 10239 1556 8683
> >>
> >> (Sorry about the line wrapping - my email client does that and it is
> >> not able to be turned off).
> >>
> >> So your frontend only system with only 3000 recordings should be just
> >> fine. So my best guess is that something is triggering a bug that is
> >> causing a memory leak. But the problem might be in another program,
> >> rather than mythfrontend. The OOM system is known for killing the
> >> largest RAM user, when the problem program that is suddenly using up
> >> RAM is a different program.
> >>
> >> There was one old bug that caused the cache directory not to be
> >> cleaned up properly, and mythfrontend would then load the cache and
> >> run out of RAM. That was fixed a while ago, but it is possible that
> >> you still somehow have a huge cache. So take a look at
> >> $(HOME)/.mythtv/cache and see how big it is:
> >>
> >> root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
> >> 376M /home/stephen/.mythtv/cache/
> >> 376M total
> >>
> >> This mine now, but when the bug was happening, it was many gibytes. If
> >> yours is too large, shut down mythfrontend and do:
> >>
> >> rm -r $(HOME)/.mythtv/cache
> >>
> >> Mythfrontend should then rebuild the cache as required.
> >>
> >> I would suggest upgrading to v32. That is the currently supported
> >> version, so if you have a problem that needs the devs to fix it, you
> >> will need to be on v32 for them to be interested. And it is vaguely
> >> possible your problem may be fixed already in v32-fixes.
> >>
> >>
> >> Stephen:
> >> 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.
> >>
> >> Ken Emerson
> >>
> >> Update:
> >>
> >> 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?
> >>
> >> Anyway, sorry for all the cruft.
> >>
> >> BTW: 681Mb in .mythtv/cache
> >> Will have to wait several weeks to see if the OOM kill problem is gone.
> >>
> >> Thanks for your time and help.
> >>
> >> Regards,
> >> Ken Emerson
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> FYI: This is a dedicated frontend/backend server with no other services
> running other than what myth requires.
> >>
> >> 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.
> >>
> >> Regards,
> >>
> >> Ken Emerson
> >>
> >>
> >> _______________________________________________
> >> mythtv-users mailing list
> >>
> >> mythtv-users@mythtv.org
> >> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> >> http://wiki.mythtv.org/Mailing_List_etiquette
> >>
> >> MythTV Forums:
> >> https://forum.mythtv.org
> > My combined FE/BE also has 8GB or RAM and has no issues (running 0.28).
> Something to keep in mind when looking at how much RAM is 'free'
> (/proc/meminfo) is that the linux kernel will use any available RAM for
> caching, so the reported free RAM is usually low. This is not indicative
> of a problem (i.e., memory leak).
> > Jay
> >
> > Thanks for the input. The problem seems to be intermittent. I'm looking
> at the memory now with two programs recording (just for a test). The
> results from the 'free' command are:
> >
> > total used free shared buff/cache
> available
> > Mem: 7.7Gi 6.8Gi 130Mi 5.0Mi 884Mi
> 752Mi
> > Swap: 2.0Gi 2.0Gi 0B
> >
> > With the exception of the swap numbers, this seems reasonable. Maybe
> everything is fine. Watching the numbers it appears the kernel is doing
> what it's supposed to do. I still don't understand why swap is getting
> used. I'll see what happens when I add the addtional 8Gb of RAM next week.
>
> The trouble is when us mere mortals try to understand ,,,
> If you have oodles of ram and some of it is untouched (as opposed to
> unused) then the kernel will swap that out so that you’ve got more cache
> that is *touched* and there are *signicant* arguments on ram vs swap with
> tuning available.
> So you might go from
>
> 4G used 4G free swap 0
> to
> 2G used 6G free swap 2G
>
> eg consider these
>
> 'echo 'vm.swappiness=1' > /etc/sysctl.d/99-sysctl.conf'
> 'echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.d/99-sysctl.conf’
>
> James
>
>
Kenneth,
please state the theme you are using (including version).
Do you use plugins from MythTV?
Is mythwelcome part of the game?
How often does the frontend restart because of an error?
What is the output of
dpkg -l | grep -i mythtv

Roland

On Fri, May 20, 2022 at 5:05 PM Roland Ernst <rcrernst@gmail.com> wrote:

>
>
> On Fri, May 20, 2022 at 10:36 AM James Linder <jam@tigger.ws> wrote:
>
>>
>>
>> > On 20 May 2022, at 4:30 am, Kenneth Emerson <kenneth.emerson@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Thu, May 19, 2022 at 12:19 PM Jay Foster <jayf0ster@roadrunner.com>
>> wrote:
>> > On 5/19/2022 10:03 AM, Kenneth Emerson wrote:
>> >>
>> >>
>> >> On Mon, Apr 11, 2022, 2:53 PM Kenneth Emerson <
>> kenneth.emerson@gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <
>> kenneth.emerson@gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>> >> On Sun, 10 Apr 2022 23:00:17 -0500, you wrote:
>> >>
>> >>
>> >> >> Stephen:
>> >> >
>> >> >
>> >> >
>> >> >The system RAM is 8Gb. There is a 2Gb swap space. There are about
>> 3,000
>> >> >recordings. Here is the output from swap.sh:
>> >> >
>> >> >
>> >> >ken@mythtv:~$ ./swap.sh
>> >> >
>> >> >
>> >> >..............................
>> >> >
>> >> >Overall swap used: 798096 kB
>> >> >
>> >> >
>> >> >========================================
>> >> >
>> >> >kB pid name
>> >> >
>> >> >
>> >> >========================================
>> >> >
>> >> >404072 1408 mythfrontend.re
>> >> >
>> >> >77376 1365 xfdesktop
>> >> >
>> >> >42080 1277 xfwm4
>> >> >
>> >> >38504 1377 applet.py
>> >> >
>> >> >37120 1509 blueman-tray
>> >> >
>> >> >34504 1426 blueman-applet
>> >> >
>> >> >15624 1131 xfce4-session
>> >> >
>> >> >14224 1310 panel-1-whisker
>> >> >
>> >> >12480 1321 panel-10-pulsea
>> >> >
>> >> >12224 1317 panel-8-statusn
>> >> >
>> >> >11536 1314 panel-6-notific
>> >> >
>> >> >10552 1401 update-notifier
>> >> >
>> >> >10216 1411 nm-applet
>> >> >
>> >> >9408 1360 Thunar
>> >> >
>> >> >9336 1282 xfsettingsd
>> >> >
>> >> >8608 1313 panel-5-systray
>> >> >
>> >> >8576 1318 panel-9-power-m
>> >> >
>> >> >8528 1385 xfce4-power-man
>> >> >
>> >> >8240 1315 panel-7-indicat
>> >> >
>> >> >5840 1283 xfce4-panel
>> >> >
>> >> >3280 12076 bash
>> >> >
>> >> >3272 1382 xiccd
>> >> >
>> >> >3032 3791 bash
>> >> >
>> >> >2688 1123 systemd
>> >> >
>> >> >2640 1442 polkit-gnome-au
>> >> >
>> >> >1920 1130 pulseaudio
>> >> >
>> >> >1224 1437 agent
>> >> >
>> >> >504 1145 dbus-daemon
>> >> >
>> >> >248 3784 tmux: server
>> >> >
>> >> >240 1368 mythfrontend
>> >> >
>> >> >
>> >> >ken@mythtv:~$ free -m
>> >> >
>> >> >
>> >> > total used free shared
>> buff/cache
>> >> >available
>> >> >Mem: 7934 2964 202 7 4768
>> >> > 4668
>> >> >
>> >> >If it's meaningful the CPU is an Intel i5-2500K 3.3GHz
>> >> >
>> >> >Perhaps I am hitting some limit on number of recordings, but I don't
>> ever
>> >> >remember there being a (soft?) limit.
>> >> >The system is a bit old, but I would hope it's powerful enough. I
>> only use
>> >> >it as a media center with only MythTv as the main application.
>> >> >
>> >> >Regards,
>> >> >
>> >> >Ken Emerson
>> >>
>> >> With 8 Gibytes of RAM, it should be fine. Only 3000 recordings is not
>> >> a problem (I have 52880 on an 8 Gibyte frontend/backend system). There
>> >> is no fixed limit on recordings - the list can grow as big as your
>> >> system will allow, although things do slow down a bit when you have as
>> >> many as I do.
>> >>
>> >> It does look like the swap space is filling up though - I would
>> >> suggest increasing that to 8 Gibytes. But it is currently using
>> >> 798096 kiB, which is under half full so it is not obvious that it will
>> >> run out of swap.
>> >>
>> >> I have my system and swap partitions on a fast M.2 NVME SSD, which
>> >> helps with swapping.
>> >>
>> >> The free command gives you the total RAM and swap usage. This is my
>> >> system with mythfrontend showing my recordings list:
>> >>
>> >> root@mypvr:~# free -m
>> >> total used free shared buff/cache
>> >> available
>> >> Mem: 7902 2829 120 23 4952
>> >> 4752
>> >> Swap: 10239 1556 8683
>> >>
>> >> (Sorry about the line wrapping - my email client does that and it is
>> >> not able to be turned off).
>> >>
>> >> So your frontend only system with only 3000 recordings should be just
>> >> fine. So my best guess is that something is triggering a bug that is
>> >> causing a memory leak. But the problem might be in another program,
>> >> rather than mythfrontend. The OOM system is known for killing the
>> >> largest RAM user, when the problem program that is suddenly using up
>> >> RAM is a different program.
>> >>
>> >> There was one old bug that caused the cache directory not to be
>> >> cleaned up properly, and mythfrontend would then load the cache and
>> >> run out of RAM. That was fixed a while ago, but it is possible that
>> >> you still somehow have a huge cache. So take a look at
>> >> $(HOME)/.mythtv/cache and see how big it is:
>> >>
>> >> root@mypvr:~# du -hcs /home/stephen/.mythtv/cache/
>> >> 376M /home/stephen/.mythtv/cache/
>> >> 376M total
>> >>
>> >> This mine now, but when the bug was happening, it was many gibytes. If
>> >> yours is too large, shut down mythfrontend and do:
>> >>
>> >> rm -r $(HOME)/.mythtv/cache
>> >>
>> >> Mythfrontend should then rebuild the cache as required.
>> >>
>> >> I would suggest upgrading to v32. That is the currently supported
>> >> version, so if you have a problem that needs the devs to fix it, you
>> >> will need to be on v32 for them to be interested. And it is vaguely
>> >> possible your problem may be fixed already in v32-fixes.
>> >>
>> >>
>> >> Stephen:
>> >> 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.
>> >>
>> >> Ken Emerson
>> >>
>> >> Update:
>> >>
>> >> 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?
>> >>
>> >> Anyway, sorry for all the cruft.
>> >>
>> >> BTW: 681Mb in .mythtv/cache
>> >> Will have to wait several weeks to see if the OOM kill problem is gone.
>> >>
>> >> Thanks for your time and help.
>> >>
>> >> Regards,
>> >> Ken Emerson
>> >>
>> >> 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.
>> >>
>> >> 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.
>> >>
>> >> FYI: This is a dedicated frontend/backend server with no other
>> services running other than what myth requires.
>> >>
>> >> 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.
>> >>
>> >> Regards,
>> >>
>> >> Ken Emerson
>> >>
>> >>
>> >> _______________________________________________
>> >> mythtv-users mailing list
>> >>
>> >> mythtv-users@mythtv.org
>> >> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> >> http://wiki.mythtv.org/Mailing_List_etiquette
>> >>
>> >> MythTV Forums:
>> >> https://forum.mythtv.org
>> > My combined FE/BE also has 8GB or RAM and has no issues (running
>> 0.28). Something to keep in mind when looking at how much RAM is 'free'
>> (/proc/meminfo) is that the linux kernel will use any available RAM for
>> caching, so the reported free RAM is usually low. This is not indicative
>> of a problem (i.e., memory leak).
>> > Jay
>> >
>> > Thanks for the input. The problem seems to be intermittent. I'm
>> looking at the memory now with two programs recording (just for a test).
>> The results from the 'free' command are:
>> >
>> > total used free shared buff/cache
>> available
>> > Mem: 7.7Gi 6.8Gi 130Mi 5.0Mi 884Mi
>> 752Mi
>> > Swap: 2.0Gi 2.0Gi 0B
>> >
>> > With the exception of the swap numbers, this seems reasonable. Maybe
>> everything is fine. Watching the numbers it appears the kernel is doing
>> what it's supposed to do. I still don't understand why swap is getting
>> used. I'll see what happens when I add the addtional 8Gb of RAM next week.
>>
>> The trouble is when us mere mortals try to understand ,,,
>> If you have oodles of ram and some of it is untouched (as opposed to
>> unused) then the kernel will swap that out so that you’ve got more cache
>> that is *touched* and there are *signicant* arguments on ram vs swap with
>> tuning available.
>> So you might go from
>>
>> 4G used 4G free swap 0
>> to
>> 2G used 6G free swap 2G
>>
>> eg consider these
>>
>> 'echo 'vm.swappiness=1' > /etc/sysctl.d/99-sysctl.conf'
>> 'echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.d/99-sysctl.conf’
>>
>> James
>>
>>
> Kenneth,
> please state the theme you are using (including version).
> Do you use plugins from MythTV?
> Is mythwelcome part of the game?
> How often does the frontend restart because of an error?
> What is the output of
> dpkg -l | grep -i mythtv
>
> Roland
>
>
Sorry, I had a thinko:
What is the output of
dpkg -l | grep -i myth
This is the better way to check.

Roland

On Mon, 11 Apr 2022 at 06:54, Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:
>
>
> It does look like the swap space is filling up though - I would
> suggest increasing that to 8 Gibytes. But it is currently using
> 798096 kiB, which is under half full so it is not obvious that it will
> run out of swap.
>
Linux will in most default configurations use swap if it's available,
by default it will attempt to swap out unused pages to maximise the
amount of disk cache available, especially in an IO heavy workload
like Myth.

You will probably find if you increase it it will fill further
(although with only 8GB main memory the amount it could pro-activly
swap out would be less).

Whilst there seems to be a memory issue here, using swap doesn't
necesseraly mean you're running out of memory.

Cheers

Ian
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Thanking each of you for all the input, especially the info on how Linux
uses swap space; I had no idea.

Theme info: I'm using a modified version of Robert Siebert's Blue Abstract
(I think it was version 10 when I cloned it). I made minor modifications
mostly around display season/episode data.

MythWelcome is not used. I have installed mythmusic and mythgallery. I
believe mythweb is installed but I don't use it.

It appears that the only time the frontend dies is when killed by the OOM
service (or by me for other purposes). That's all that shows up in the
kern.log files which go back to 16 April 2022.

The output from dpkg -l | grep -i myth:
ii libmyth
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Common
library code for MythTV and add-on modules (runtime)
ii libmyth-python
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Python
library to access some MythTV features
ii libmythes-1.2-0:amd64 2:1.2.4-3build1
amd64 simple thesaurus library
ii libmythtv-perl
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Perl
library to access some MythTV features
ii mythes-en-us 1:6.4.3-1
all English (USA) Thesaurus for LibreOffice
ii mythmusic
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Music
add-on module for MythTV
ii mythtv
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Personal
video recorder application (client and server)
ii mythtv-backend
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
video recorder application (server)
ii mythtv-backend-master
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Metapackage
to setup and configure a "Master Backend" profile of MythTV
ii mythtv-common
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
video recorder application (common data)
ii mythtv-database
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Personal
video recorder application (database)
ii mythtv-frontend
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
video recorder application (client)
ii mythtv-transcode-utils
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Utilities
used for transcoding MythTV tasks
ii mythweb
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Web
interface add-on module for MythTV
ii php-mythtv
2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all PHP
Bindings for MythTV

Thanks again for your time and input.

Regards,

Ken Emerson

On Fri, May 20, 2022 at 1:06 PM Mr Roooster <mrrooster@gmail.com> wrote:

> On Mon, 11 Apr 2022 at 06:54, Stephen Worthington
> <stephen_agent@jsw.gen.nz> wrote:
> >
> >
> > It does look like the swap space is filling up though - I would
> > suggest increasing that to 8 Gibytes. But it is currently using
> > 798096 kiB, which is under half full so it is not obvious that it will
> > run out of swap.
> >
> Linux will in most default configurations use swap if it's available,
> by default it will attempt to swap out unused pages to maximise the
> amount of disk cache available, especially in an IO heavy workload
> like Myth.
>
> You will probably find if you increase it it will fill further
> (although with only 8GB main memory the amount it could pro-activly
> swap out would be less).
>
> Whilst there seems to be a memory issue here, using swap doesn't
> necesseraly mean you're running out of memory.
>
> Cheers
>
> Ian
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>

On Fri, May 20, 2022 at 4:08 PM Kenneth Emerson <kenneth.emerson@gmail.com>
wrote:

> Thanking each of you for all the input, especially the info on how Linux
> uses swap space; I had no idea.
>
> Theme info: I'm using a modified version of Robert Siebert's Blue Abstract
> (I think it was version 10 when I cloned it). I made minor modifications
> mostly around display season/episode data.
>
> MythWelcome is not used. I have installed mythmusic and mythgallery. I
> believe mythweb is installed but I don't use it.
>
> It appears that the only time the frontend dies is when killed by the OOM
> service (or by me for other purposes). That's all that shows up in the
> kern.log files which go back to 16 April 2022.
>
> The output from dpkg -l | grep -i myth:
> ii libmyth
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Common
> library code for MythTV and add-on modules (runtime)
> ii libmyth-python
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Python
> library to access some MythTV features
> ii libmythes-1.2-0:amd64 2:1.2.4-3build1
> amd64 simple thesaurus library
> ii libmythtv-perl
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Perl
> library to access some MythTV features
> ii mythes-en-us 1:6.4.3-1
> all English (USA) Thesaurus for LibreOffice
> ii mythmusic
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Music
> add-on module for MythTV
> ii mythtv
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Personal
> video recorder application (client and server)
> ii mythtv-backend
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
> video recorder application (server)
> ii mythtv-backend-master
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Metapackage
> to setup and configure a "Master Backend" profile of MythTV
> ii mythtv-common
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
> video recorder application (common data)
> ii mythtv-database
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Personal
> video recorder application (database)
> ii mythtv-frontend
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Personal
> video recorder application (client)
> ii mythtv-transcode-utils
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 amd64 Utilities
> used for transcoding MythTV tasks
> ii mythweb
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all Web
> interface add-on module for MythTV
> ii php-mythtv
> 2:32.0+fixes.202205111848.26079f815a~ubuntu20.04.1 all PHP
> Bindings for MythTV
>
> Thanks again for your time and input.
>
> Regards,
>
> Ken Emerson
>
> On Fri, May 20, 2022 at 1:06 PM Mr Roooster <mrrooster@gmail.com> wrote:
>
>> On Mon, 11 Apr 2022 at 06:54, Stephen Worthington
>> <stephen_agent@jsw.gen.nz> wrote:
>> >
>> >
>> > It does look like the swap space is filling up though - I would
>> > suggest increasing that to 8 Gibytes. But it is currently using
>> > 798096 kiB, which is under half full so it is not obvious that it will
>> > run out of swap.
>> >
>> Linux will in most default configurations use swap if it's available,
>> by default it will attempt to swap out unused pages to maximise the
>> amount of disk cache available, especially in an IO heavy workload
>> like Myth.
>>
>> You will probably find if you increase it it will fill further
>> (although with only 8GB main memory the amount it could pro-activly
>> swap out would be less).
>>
>> Whilst there seems to be a memory issue here, using swap doesn't
>> necesseraly mean you're running out of memory.
>>
>> Cheers
>>
>> Ian
>> _______________________________________________
>>
>> Just an update. I have just added an additional 8Gb of RAM, so now the
system looks like:
total used free shared buff/cache
available
Mem: 16370300 1641832 9548284 8656 5180184
14408088
Swap: 2097148 0 2097148
We'll see what transpires over the course of a few weeks or months.

Thanks for all of your input.

Ken Emerson