[mythtv-users] Mythbackend recording glitches

Fri Oct 19 00:03:45 UTC 2018

On Thu, Oct 18, 2018 at 3:59 PM Greg Oliver <oliver.greg at gmail.com> wrote:

> On Thu, Oct 18, 2018 at 5:14 PM Allen Edwards <allen.p.edwards at gmail.com>
> wrote:
>
>> On Thu, Oct 18, 2018 at 2:22 PM Allen Edwards <allen.p.edwards at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 18, 2018 at 1:41 PM faginbagin <mythtv at hbuus.com> wrote:
>>>
>>>> On 10/17/2018 9:53 PM, Stephen Worthington wrote:
>>>>
>>>> <snip>
>>>>
>>>> > But you really do need to change to using the 64-bit version.  As of
>>>> > 18.04, Ubuntu no longer supports the i386 version, and for a number of
>>>> > versions before that the support has not been good - the i386 versions
>>>> > tend to have problems.  And MythTV has not been tested much on i386
>>>> > versions for a long time.
>>>>
>>>> While I agree with Stephen that Allen should change to a 64-bit version
>>>> of Ubuntu, I have to say Ubuntu still supports 32-bit CPUs. They have
>>>> dropped support for CPUs that don't support Physical Address Extension
>>>> (PAE), but 32 bit CPUs manufactured since around 2004 do support PAE.
>>>> _______________________________________________
>>>>
>>>
>>> Some new information.  I did a recording with mythfrontend off and it
>>> had glitches.  So that didn't work.
>>>
>>> I also think I might have figured out why my beloved Mythbuntu 8 was not
>>> working. I said that it died because of a disk failure but what I didn't
>>> say was that it was the second disk, one that was just for additional
>>> storage. What occured to me today was that I probably needed to just delete
>>> the reference to that now missing storage.  I ran mythbackend setup as part
>>> of documenting the settings and noticed that the second storage location
>>> was not there and then I saved the settings.  I am thinking that might fix
>>> my Mythbuntu 8 system. Then I can chalk up the multitude of hours I spent
>>> trying to get Mythbuntu 16 to work to "entertainment".
>>>
>>> Just for a point of comparison to document the "progress" that myth as
>>> made in the last 10 years. I reinstalled the 6200 video card and the old HD
>>> and there is no ripping like there was with Mythbuntu 16 with that card and
>>> no glitches.  I am, as I have said, perfectly happy with the performance of
>>> Mythbuntu 8 so if this proves to actually be stable, I may just quit here.
>>> I am recording and watching at the same time in "top" below and there is no
>>> swap used.  I notice that the buffers space is much smaller and I may have
>>> increased the buffers on the new setup at some point in the debugging stage
>>> but in any event it is of interest.
>>>
>>> But I have a 1T HD coming today so I have to decide which OS I am going
>>> to put on it...
>>>
>>> Allen
>>>
>>> top - 13:52:35 up 10 min,  2 users,  load average: 0.34, 0.31, 0.24
>>> Tasks: 131 total,   1 running, 130 sleeping,   0 stopped,   0 zombie
>>> Cpu(s): 12.5%us,  1.4%sy,  0.0%ni, 85.0%id,  0.3%wa,  0.0%hi,  0.8%si,
>>> 0.0%st
>>> Mem:   2075424k total,  1433176k used,   642248k free,    27556k buffers
>>> Swap:  6072528k total,        0k used,  6072528k free,   980256k cached
>>>
>>>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>  6803 dad       20   0  306m 153m  71m S   14  7.6   0:13.38
>>> mythfrontend.re
>>>  6393 root      20   0  146m 121m  50m S    2  6.0   0:05.58 Xorg
>>>  6026 mythtv    20   0  306m  45m  11m S    0  2.2   0:12.48 mythbackend
>>>     1 root      20   0  2844 1692  544 S    0  0.1   0:01.06 init
>>>     2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
>>>     3 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/0
>>>     4 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksoftirqd/0
>>>     5 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/0
>>>     6 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/1
>>>
>>>
>> So what is up with the swap?  Looking at the screen capture for swapping
>> and the theory that it is swap that is causing the glitches, why is there
>> any swapping? There isn't any with mythbuntu 8 and there doesn't seem to be
>> a need in 16 except to clear memory for buffer/cache.  WTF?
>>
>> KiB Mem :  2061948 total,   135672 free,   450240 used,  1476036
>> buff/cache
>> KiB Swap:  2094076 total,  1704088 free,   389988 used.  1349872 avail Mem
>>
>> That says that memory used is 840M or less than half the RAM I have.  But
>> this buffer/cache is almost 1.5G. forcing about 400M to swap.
>>
>> So before I go buy more memory that I don't need, how can I limit the
>> swapping?  Google is not too helpful, something about you can't do this and
>> everyone complains about it.
>>
>> Allen
>>
>> buffer/cache are not "used" - just what it says - buffer / cache.  If
> your system has swap in use, then at some point, it *did* need to use
> swap.  buffer/cache will be regained before swap is used otherwise.  Try
> taking swap out of your fstab and see what happens..
>
> The difference in OS between those versions you mentioned is not minimal.
> Hardware requirements change significantly over time, and 2GB is definitely
> not enought for any modern x86_64 kernel (running a full GUI).  You could
> get away with something that does not run a full window manager and desktop
> probably.  I run xorg and ratpoison which I think is about as minimal as
> you can get.  I must admit I am using an older i7 with 8 threads and 16GB
> ram, but still..  I use this machine for a lot of non gui stuff - only
> mythfrontend needs a gui...
>
> I use systemd to autologin me in to a tty, which my bash profile runs
> startx and my .xinitrc starts ratpoison, and my .ratpoisonrc starts
> mythfrontend..
>
> You could probably get away with that in 2MB..
>
> -Greg
>

Can anyone say that if I go to 4G or ram with the AMD 5400 that I will not
run into some other limitation? I feel I grossly underestimated the effort
and overestimated the benefit of upgrading to Mythbuntu 16.

Perhaps I just need to figure out how to move everything from my 500G drive
to my new about to be delivered 1T drive.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20181018/05dbf263/attachment-0001.html>