Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.
Page 1 of 3 123 LastLast
Results 1 to 15 of 38

Thread: Possibly malfunctioning h7s

  1. #1

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts

    Possibly malfunctioning h7s

    Some of you may remember before I reported I had to auto reboot the box every 3 days to keep it working.

    Well I have been observing the past few months that on iptv I would get a picture freeze every 2-3 seconds, the obvious thought is a network problem right?

    Well if I watch 'top' in the shell every 2-3 seconds the 'si' usage goes to 100%. The software interrupts counter.

    I have just clean flashed the latest vix 5.4 image and its still happening.

    Given how highly rated these units are I am starting to think mine is defective, but I am hoping someone may know of a workaround to the problem.

    Code:
    # top
    top - 18:05:38 up 10 min,  1 user,  load average: 0.06, 0.04, 0.00
    Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,100.0 si,  0.0 st
    MiB Mem :   1004.0 total,    174.9 free,    729.9 used,     99.2 buff/cache
    MiB Swap:    256.0 total,    256.0 free,      0.0 used.    241.3 avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                         
     2051 root      20   0  145292  73808  15600 S   0.7   7.2   0:12.22 enigma2                                                         
     2193 root      20   0    6288   2276   1940 R   0.7   0.2   0:01.39 top                                                             
        7 root      20   0       0      0      0 S   0.3   0.0   0:00.07 rcu_sched                                                       
     1452 root      20   0       0      0      0 S   0.3   0.0   0:01.58 nxsched                                                         
        1 root      20   0    1604    328    284 S   0.0   0.0   0:01.39 init                                                            
        2 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kthreadd                                                        
        4 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 kworker/0:0H                                                    
        6 root      20   0       0      0      0 S   0.0   0.0   0:00.08 ksoftirqd/0                                                     
        8 root      20   0       0      0      0 S   0.0   0.0   0:00.00 rcu_bh                                                          
        9 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/0                                                     
       10 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 lru-add-drain                                                   
       11 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 watchdog/0                                                      
       12 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0                                                         
       13 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/1                                                         
       14 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 watchdog/1                                                      
       15 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 migration/1                                                     
       16 root      20   0       0      0      0 S   0.0   0.0   0:00.00 ksoftirqd/1
    Last edited by chrcoluk; 14-08-21 at 18:06. Reason: removed sig as out of date

  2. #2
    twol's Avatar
    Title
    Moderator
    Join Date
    Apr 2012
    Posts
    7,486
    Thanks
    910
    Thanked 2,604 Times in 1,997 Posts
    Which plugins have you installed???
    Gigablue Quad 4K & UE 4K
    .........FBC Tuners:
    ------------------> DUR-Line DCR 5-1-8-L4 Multiswitch to 1.5M dish(28.2E)
    ------------------> Spaun SUS 5581/33 NFA Multiswitch to 80 cm dish(19.2E)
    .......................> FBC & DVB-S2X into 90cm dish (27.5W) Opticum robust Unicable LNB
    AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 using Legacy ports on multiswitches
    Zgemma H9 C/S into Giga4K

  3. #3

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    Can a plugin cause software interrupts?

    List of plugins is.

    crossepg
    iptv bouquet maker
    open webif
    Last edited by chrcoluk; 14-08-21 at 18:22. Reason: typo
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  4. #4

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    On the new version of vix I have left the auto reboot disabled, and will see what happens on that particular issue.

    The iptv is not confirmed working or not as I havent reinstalled the plugins for it.

    I did find a thread elsewhere with people discussing hanging h7s boxes a few of them, and they all had faulty receiver's.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  5. #5

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    A little update, I have identified over committing of memory, the unit even when firstly booted up has under 200 meg of free ram, the committed memory isnt on temporary things like cache is its fully committed to things that cannot be removed from memory if needed.

    Due to the memory constraints I looked into ways to ease the problem. With a swap file installed and default vm.swappiness, it routinely will use the swap file setting the swapinness to as low as 5 is not utilising it, removing the swapfile causes the box to crash with OOM.

    Part of the problem has also been identified the use of /var/volatile/tmp using a ram disk, its default sized to 500meg, this is where I made some progress, the disk is backed by swap, so wont error out when is not enough memory providing there is a swap device present, the default size of 500meg when the system only has circa 200 meg of memory to allocate is obviously a disaster waiting to happen, interestingly when I capped the ram disk to 100meg enigma crashed over night and went into a boot loop so I had proof enigma was doing something that required a lot of tmp storage (in ram), and it was epg updates.

    I have since made a tmp dir on the hdd and bind mounted it over /var/volatile/tmp, existing /tmp is symlinked to /var/volatile/tmp, I thought about changing that symlink but I expect that was too risky with system updates undoing that change.

    There has been some clear overconfidence in the capabilities of this unit in terms of ram, I feel selling a device with only 1 gig of ram in 2021 is a bit questionable, the manufacturers of this device probably should rethink that one. The amount of stories on the net of this unit been unstable is starting to make some sense, although at least some of those stories confirmed to be faulty receiver chips.

    So will now see if this can stay stable overnight for a decent period of time, hopefully I wont report back for a week or two and only then to confirm no more problems. A usb stick is been ordered as using the hdd for tmp has a little risk if it fills up with recordings.

    In addition cat /proc/interrupts shows a bunch of strangely named processes with varying length of 'b' in their name. Seems lots of oddly proprietary stuff running that is hard to debug including the earlier identified '999999999999999' process.

    I am not sure if this is a clean install of vix as I did the upgrade via image manager and chose not to restore the backed up config, I may still do an install from the recovery image if instability prevails. Also htop oddly doesnt show the 100% usage that normal top shows under 'si' usage.
    Last edited by chrcoluk; 15-08-21 at 21:32.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  6. #6
    ccs's Avatar
    Title
    ViX Beta Tester
    Join Date
    Sep 2014
    Posts
    5,815
    Thanks
    551
    Thanked 1,253 Times in 1,071 Posts
    Where do you store epg.dat? If it's in flash, then move it to hdd or usb.
    Last edited by ccs; 15-08-21 at 21:47.

  7. #7

    Title
    ViX Beta Tester
    Join Date
    Apr 2011
    Location
    Ireland
    Posts
    1,943
    Thanks
    399
    Thanked 641 Times in 524 Posts
    Quote Originally Posted by chrcoluk View Post
    A little update, I have identified over committing of memory, the unit even when firstly booted up has under 200 meg of free ram, the committed memory isnt on temporary things like cache is its fully committed to things that cannot be removed from memory if needed.

    Due to the memory constraints I looked into ways to ease the problem. With a swap file installed and default vm.swappiness, it routinely will use the swap file setting the swapinness to as low as 5 is not utilising it, removing the swapfile causes the box to crash with OOM.

    Part of the problem has also been identified the use of /var/volatile/tmp using a ram disk, its default sized to 500meg, this is where I made some progress, the disk is backed by swap, so wont error out when is not enough memory providing there is a swap device present, the default size of 500meg when the system only has circa 200 meg of memory to allocate is obviously a disaster waiting to happen, interestingly when I capped the ram disk to 100meg enigma crashed over night and went into a boot loop so I had proof enigma was doing something that required a lot of tmp storage (in ram), and it was epg updates.

    I have since made a tmp dir on the hdd and bind mounted it over /var/volatile/tmp, existing /tmp is symlinked to /var/volatile/tmp, I thought about changing that symlink but I expect that was too risky with system updates undoing that change.

    There has been some clear overconfidence in the capabilities of this unit in terms of ram, I feel selling a device with only 1 gig of ram in 2021 is a bit questionable, the manufacturers of this device probably should rethink that one. The amount of stories on the net of this unit been unstable is starting to make some sense, although at least some of those stories confirmed to be faulty receiver chips.

    So will now see if this can stay stable overnight for a decent period of time, hopefully I wont report back for a week or two and only then to confirm no more problems. A usb stick is been ordered as using the hdd for tmp has a little risk if it fills up with recordings.

    In addition cat /proc/interrupts shows a bunch of strangely named processes with varying length of 'b' in their name. Seems lots of oddly proprietary stuff running that is hard to debug including the earlier identified '999999999999999' process.

    I am not sure if this is a clean install of vix as I did the upgrade via image manager and chose not to restore the backed up config, I may still do an install from the recovery image if instability prevails. Also htop oddly doesnt show the 100% usage that normal top shows under 'si' usage.
    I don't see a flood of stories on the net about the h7. Mine has never run out of memory with the default 256MB swap.
    Zgemma H7S running OpenVIX 5.4, Darkmotor, Triax TD110 dish, Inverto Black Ultra dual lnb
    LG 50UM7450 4K TV, Pioneer VSX-534 Atmos AVR , Panasonic DP-UB450 4K Bluray & a Playstation 4.

  8. #8

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    Quote Originally Posted by ccs View Post
    Where do you store epg.dat? If it's in flash, then move it to hdd or usb.
    on the hdd, that has no bearing on the memory consumption, during the process of creating the epg there is temporary files written to /tmp and /tmp is hosted on a ramdisk.

    The vix crash logs were very useful in diagnosing this.

    The initial crashes reported /tmp had ran out of space to store epg files (after I reduced it to 100meg thinking vix wouldnt need so much scratch space). The decision to reduce it was a bad one but did serve to help me debug what is going on, the ram disk only consumes ram for used space. It is backed by swap if there isnt enough ram.

    Also thanks guys for confirming swap is on by default, as due to me been unsure if this is an actual clean vix install, I wasnt sure if I added the swap or it was default. It is 256meg, so I am assuming now its a default enabled swap.

    After I did the bind mount moving tmp to my hdd, the crashes stopped, thus far since I made those changes the box has been fine and responsive, but I need more than 1-2 days to consider if its working ok, if it makes a week, then this is great progress as before I had to automate reboots every 2-3 days.

    There is currently nearly 600 gig in my trash of recordings which will be deleted probably in next day or so and currently 40 gig of free space, so hdd wont be full for a while now. By then I will have the usb taking over /tmp duties.
    Last edited by chrcoluk; 16-08-21 at 17:35.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  9. #9
    ccs's Avatar
    Title
    ViX Beta Tester
    Join Date
    Sep 2014
    Posts
    5,815
    Thanks
    551
    Thanked 1,253 Times in 1,071 Posts
    Quote Originally Posted by chrcoluk View Post
    on the hdd, that has no bearing on the memory consumption, during the process of creating the epg there is temporary files written to /tmp and /tmp is hosted on a ramdisk.
    If it's on the hdd then there's no problem, but the default is to save an epg copy in a file called epg.dat in internal flash, which can cause problems.

  10. #10
    BrokenUnusableAccount
    Quote Originally Posted by ronand View Post
    I don't see a flood of stories on the net about the h7. Mine has never run out of memory with the default 256MB swap.
    I'd never really investigated how much memory was free, or the swapfile.

    It seems that by default it uses /dev/mmcblk0p7 as a 256MB swap partition.

    Using emmc flash as swap can't really be a good idea, if you ever run something big that makes it really thrash it'll wear out the emmc.

    However I can't work out how to permanantly stop it using /dev/mmcblk0p7 as swap.

    Code:
    swapoff /dev/mmcblk0p7
    stops it right now, but next time it boots up there it is again 256MB swap using /dev/mmcblk0p7 !

    I'd feel a lot happier using a swapfile on my hard drive.

  11. #11

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    Hmm I honestly dont know if I tinkered with the swap in the past but my swap is on the hdd currently, I dont think its a good idea to use the flash as swap for the same reasons I was advised to make sure the epg is not on my flash.

    root@zgemmah7:/tmp# cat /proc/swaps
    Filename Type Size Used Priority
    /media/hdd/swapfile file 262140 320 -1

    in /etc/fstab (where it is set to apply at boot), there needs to be a swapfile created first.

    /media/hdd/swapfile swap swap defaults 0 0
    Last edited by chrcoluk; 17-08-21 at 00:34.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  12. #12
    BrokenUnusableAccount

    Angry

    Quote Originally Posted by chrcoluk View Post
    Hmm I honestly dont know if I tinkered with the swap in the past but my swap is on the hdd currently, I dont think its a good idea to use the flash as swap for the same reasons I was advised to make sure the epg is not on my flash.

    root@zgemmah7:/tmp# cat /proc/swaps
    Filename Type Size Used Priority
    /media/hdd/swapfile file 262140 320 -1

    in /etc/fstab (where it is set to apply at boot), there needs to be a swapfile created first.

    /media/hdd/swapfile swap swap defaults 0 0
    My H7 just completely refuses to do that.
    It dosn't seem to care what's in /etc/fstab
    I can't get anything except:
    Code:
    root@Zgemmah7:~# cat /proc/swaps
    Filename                                Type            Size    Used    Priority
    /dev/mmcblk0p7                          partition       262140  0       -1
    root@Zgemmah7:~#
    or no swap at all.


    Oh well. At least mine seems to be almost never using the swap.
    Last edited by BrokenUnusableAccount; 17-08-21 at 01:48.

  13. #13

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    Yeah at least you not using the swap, I got the swappiness set down to 5, and its still using 320k albeit a tiny amount. Currently only 62 meg of free ram with another 62 meg allocated to caching, its been creeping down so still curious if the box makes it a week.

    Interestingly as well not all of the combined free+caching is available either. Just under 100M available. From around 200M on a fresh boot.

    # free
    total used free shared buff/cache available
    Mem: 1028056 897756 64360 76 65940 99212
    Swap: 262140 320 261820
    Last edited by chrcoluk; 17-08-21 at 03:11.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

  14. #14

    Title
    ViX Beta Tester
    Join Date
    Apr 2011
    Location
    Ireland
    Posts
    1,943
    Thanks
    399
    Thanked 641 Times in 524 Posts
    On any linux box I've had (and I've had a few) the system seems to allocate most of the available RAM no matter how much there actually is. So I wouldn't read too much into that. If you are getting OOM then there must a plugin that you are using that it doing it - there is definitely enough resources for use as a satellite receiver.
    Zgemma H7S running OpenVIX 5.4, Darkmotor, Triax TD110 dish, Inverto Black Ultra dual lnb
    LG 50UM7450 4K TV, Pioneer VSX-534 Atmos AVR , Panasonic DP-UB450 4K Bluray & a Playstation 4.

  15. #15

    Title
    Forum Supporter
    Donated Member
    Join Date
    Mar 2014
    Location
    UK
    Posts
    163
    Thanks
    36
    Thanked 6 Times in 6 Posts
    Quote Originally Posted by ronand View Post
    On any linux box I've had (and I've had a few) the system seems to allocate most of the available RAM no matter how much there actually is. So I wouldn't read too much into that. If you are getting OOM then there must a plugin that you are using that it doing it - there is definitely enough resources for use as a satellite receiver.
    I agree though that as long as the box works, which is ultimately what matters then its ok, which is why I am seeing if it will work for the entire week.

    How do I diagnose memory usage for plugins? right now in the UI there is only 3 basic plugins there. enigma itself is only using 110meg of ram. A lot of the memory usage seems tied up in proprietary kernel drivers.
    Last edited by chrcoluk; 17-08-21 at 17:25.
    Zgemma H7S, internal 2tb WDC WD20NPVZ-00W HDD, ViX as below
    System OE: OE-Alliance 4.4
    Firmware version: OpenViX 5.4.013 (2021-06-24)
    Kernel / Drivers: 4.10.12 / 20191123

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.