[mythtv-users] Mythbackend recording glitches
Allen Edwards
allen.p.edwards at gmail.com
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>
More information about the mythtv-users
mailing list