Just been looking through my router settings - it’s a Virgin Media Hub 3.0.
Cannot find any settings for QoS - the only options I could find which may be related were:
Firewall Protection: Enabled
Block Fragmented IP Packets: Disabled
Port Scan Detection: Disabled
IP Flood Detection: Disabled
A couple of thoughts, have you tried your VM Hub 3 in modem mode? When I first got mine I had weird network glitches which after a few days forced me into reinstalling my router and going to the aforementioned modem mode.
Also if you find modem mode effective but want to offload some of the devices on your switch I have a spare 5 port dumb GB switch in my tech drawer doing nothing which I’ll gladly mail to a fellow UK OSMC community member .
I doubt the Super Hub is causing problems here.
If you opened Wireshark, I wouldn’t be surprised if we found your TV was spamming the network. For one customer this was so extreme we dropped UPNP traffic via iptables which worked for him.
Sam
If the problem persists after latest couple of changes then ill take the tv offline completely, and see if things improve. Had moved it to wifi but its still on the same subnet at the end of the day.
Through all this it’s still puzzling me as to why the rpi3 is fine with livetv.
Ive taken the tv off the network altogether, and the problem persists
Okay, I think we need to debug dropped packets as described above
Sam
Sure, will have a go later today at getting dropwatch compiled. Will i need a kernel with debug symbols enabled as you mentioned?
Really starting to wonder if something is wrong with my vero4k+. This morning used the box no problems, then returned to it and the TV was saying that the device wasn’t supported. I connected via SSH and saw this in dmesg:
[ 5078.996844] aml_spdif_dai: aml_hw_iec958_init,runtime->rate=44100, runtime->channels=2, same source mode(1), stream format=1
[ 5078.996849] aml_spdif_dai: set divider = 2 for i2s shared clock
[ 5078.996857] aml_audio_hw: IEC958 PCM32
[ 5078.996861] hdmitx: audio: aout notify rate 44100
[ 5078.996863] hdmitx: audio: aout notify size 32
[ 5078.996865] hdmitx: audio: hdmi_ch: 0 speaker_layout: 0
[ 5078.996866] hdmitx: audio: no update
[ 5078.997030] channel count should be 8, we got 2 aborting
I’ve rebooted and uploaded the logs which are available here: https://paste.osmc.tv/camalasoso
A couple more times today it’s been playing LiveTV before suddenly the TV goes black showing a message to say no input signal, although sounds is still coming through my soundbar - connected by SPDif.
This morning it did an upgrade from 121 to 122 kernel (I’m on devel channel), so have now rolled back as I suspect that was the issue.
Logfile was provided in my previous post.
That’s just a warning that we can safely remove.
We have some changes in the kernel re. video handling; it’s possible there’s some incompatibility with your equipment here.
Thanks for the heads-up. I’ve gone back to the 121 kernel and will likely stick with that at least until we’ve bottomed out this issue.
Just wondering whether you’ve had chance to get a kernel together with the debug symbols so I can have a go at running dropwatch to further diagnose. Or is there a better way?
I don’t know if the symbols are needed. We should still get enough of a backtrace to see the function that causes the drop.
Sam
OK no problem, I’ll have a go when I get chance and see what kind out output we get.
OK, I managed to compile dropwatch but when I try to run it I get
osmc@vero4k:~/drop_watch-master/src$ ./dropwatch -l kas
Unable to find NET_DM family, dropwatch can't work
Cleaning up on socket creation error
Reading around a little it looks like we need to have the CONFIG_NET_DROP_MONITOR option enabled in the kernel in order to use this tool, which it also states on their github project page
I’m building a new kernel with that enabled. I’ve also cleaned up the ‘channel count should be 8’ warning.
Should be in the staging repository in an hour or so.
Sam
Don’t upgrade yet. I might’ve broken something 
Sam
False alarm: it’s safe to upgrade.
I’ve upgraded from staging and am running dropwatch.
It’s only been running a couple of minutes and a load of output is appearing already
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring
1 drops at (null)+0 (0x182b07c)
2 drops at (null)+0 (0x181d3a4)
1 drops at (null)+0 (0x1808328)
2 drops at (null)+3b330 (0x1843658)
4 drops at (null)+3bd54 (0x184407c)
2 drops at (null)+1507c (0x181d3a4)
2 drops at (null)+3bd54 (0x184407c)
2 drops at (null)+3b330 (0x1843658)
4 drops at (null)+3bd54 (0x184407c)
2 drops at (null)+3b330 (0x1843658)
2 drops at (null)+3b330 (0x1843658)
3 drops at (null)+3bd54 (0x184407c)
4 drops at (null)+3b330 (0x1843658)
6 drops at (null)+3b330 (0x1843658)
2 drops at (null)+1507c (0x181d3a4)
2 drops at (null)+1507c (0x181d3a4)
2 drops at (null)+1507c (0x181d3a4)I’ll build a kernel with debugging soon, then we can use addr2line to work out where the drop is occurring.
Sam