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.