Logs confirm an unreliable connection, and channels 6 and 8 are reporting unacceptable uncorrected errors, even though the low error count on several channels indicates a relatively recent restart (as that resets the error counters). Assuming you've made sure the connections between the hub and the coax wall socket are all secure and tightened up to finger tightness, there's not much you can do.
This will need forum staff to advise is there's an area fault that's to blame, and that would have a fault reference and fix date, but I suspect the channel-specific error problems may be unique to your line, and then it will need them to book a technician visit to fix it.
I'd recommend avoiding calling the offshore "support" call centre - their track record is appalling.
The reason a reboot temporarily fixes this is because after a reboot the hub has to renegotiate all 28 channels from scratch, and it keeps trying until it gets a fully working connection. But that doesn't fix the underlying cause of WHY the hub is unable to maintain synchronisation, so the problem recurs, and that's what VM need to fix.
Thank you for reaching out with your concerns, I'm really sorry that you've been having trouble maintaining a stable broadband connection.
Can I just check whether you've performed a basic reboot or a full factory reset using the pinhole? If you've not tried a full reset, this would definitely be worth a try to ensure all internal processes are refreshed. This helps to rule out any technical blips within the Hub's processing or functionality, sometimes it just needs a bit of a kick. Please bear in mind that this would revert any settings or passwords to their default and disconnect any wireless devices.
I haven't been able to identify any cause for concern in looking at your services from our end, although this may be due to the recent reboot as explained by Andruser. Most of the stats you've shared correlate with what I'm seeing here and all appear within spec. I appreciate that a couple of channels have run up high post-RS errors, so we'd certainly need to look to address this.
There's nothing on the wider network which would account for the symptoms you've described or the high post-RS count, so it would be really helpful if you're able to set up a BQM to monitor the connection to your modem. This should flag any anomalies and help to compare with our backend logs. If nothing indicates an issue further out into the network, we can certainly see whether a new hub would improve the situation.
Factory reset from Wednesday was looking good until about 10-15 mins ago when the connection went caput again. (Back down to sub 1Mb/s d/l)
My BQM chart was solid red and only now did I realise that you have to activate it the ping in the Hub's settings for it to work! As I can't get into the web interface I'll have to manually reboot the Hub, change the setting and let the BQM run until next time I get the issue.
From the snapshot you can see when the latency and packet loss went through the roof. At those moments the connection comes all but unusuable except for the most basic of tasks. I also took some speedtests during two of those incidents:
Glasgow: 17th Feb, 17.35
Edinburgh: 17th Feb, 17.37
Edinburgh: 18th Feb, 10.42
Glasgow: 18th Feb, 10.43
I can't give you up to date modem/router stats as the Superhub has been unreachable since at least 17.35 yesterday.
Superhub Admin Page: 18th Feb, 10.55
Pinging the Superhub (192.168.100.1) and my router (192.168.0.1), i get the following:
Superhub + Router Ping: 18th Feb, 10.58
As you can see the Superhub times out whereas the Asus Router responds with no packet loss.