Buffering issue with 4K HDR content after June update Vero 4K with an ethernet adapter

dillthedog · 22 June 2019 20:35

There’s no guarantee it’ll run at the right time, but we’ll know once you reboot.

sojer2005 · 22 June 2019 20:37

new log after rebooting with rc.local modified: https://paste.osmc.tv/ehuyeroqux

dillthedog · 22 June 2019 20:42

Unfortunately, rc.local runs too late.

Therefore please unplug the device, plug it back in and run grab-logs -J (big J).

sojer2005 · 22 June 2019 20:44

And I have followed your instruction:

Unplugging device.
run:
sudo modprobe r8152
echo “2357 0601” | sudo tee /sys/bus/usb/drivers/r8152/new_id
plug it back

log after this: https://paste.osmc.tv/gemocomavu

sojer2005 · 22 June 2019 20:47

osmc@osmc : ~ $ grab-logs -J

Logs successfully uploaded.

Logs available at https://paste.osmc.tv/eziqeyivug

osmc@osmc : ~ $

Should I reflash with May update firmware image? It was working perfectly.

dillthedog · 22 June 2019 20:53

It’s still picking up cdc_ether.

Perhaps @sam_nazarko can say whether blacklisting cdc_ether will cause any undesirable side effects.

sojer2005 · 22 June 2019 20:57

So I am doomed

dillthedog · 22 June 2019 21:01

Probably. It might be better if he can produce a new kernel, though officially I think he’s still on holiday.

sam_nazarko · 22 June 2019 21:01

I haven’t changed anything with Ethernet in this update

sojer2005 · 22 June 2019 21:04

I am installing fresh image from May to see what happens

dillthedog · 22 June 2019 21:06

If would be useful to repeat the iperf3 tests and to see if it picks up cdc_ether.

sojer2005 · 22 June 2019 21:13

Done.
It is back to full speed.

osmc@osmc:~$ iperf3 -R -c 192.168.1.4
Connecting to host 192.168.1.4, port 5201
Reverse mode, remote host 192.168.1.4 is sending
[  4] local 192.168.1.90 port 43397 connected to 192.168.1.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  19.1 MBytes   160 Mbits/sec                  
[  4]   1.00-2.00   sec  33.6 MBytes   282 Mbits/sec                  
[  4]   2.00-3.00   sec  31.9 MBytes   267 Mbits/sec                  
[  4]   3.00-4.00   sec  34.0 MBytes   285 Mbits/sec                  
[  4]   4.00-5.00   sec  34.2 MBytes   287 Mbits/sec                  
[  4]   5.00-6.00   sec  27.3 MBytes   229 Mbits/sec                  
[  4]   6.00-7.00   sec  34.1 MBytes   286 Mbits/sec                  
[  4]   7.00-8.00   sec  26.0 MBytes   218 Mbits/sec                  
[  4]   8.00-9.00   sec  30.2 MBytes   253 Mbits/sec                  
[  4]   9.00-10.00  sec  25.9 MBytes   217 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   298 MBytes   250 Mbits/sec  6543             sender
[  4]   0.00-10.00  sec   296 MBytes   248 Mbits/sec                  receiver

iperf Done.
osmc@osmc:~$

and the log: https://paste.osmc.tv/vijoroyaze

dillthedog · 22 June 2019 21:23

I’ll need to do a bit more investigation. Dobranoc.

sojer2005 · 22 June 2019 21:24

ok
Dobranoc

sojer2005 · 22 June 2019 21:37

I have installed June update again and the problem has repeated:

osmc@osmc:~$ iperf3 -R -c 192.168.1.4
Connecting to host 192.168.1.4, port 5201
Reverse mode, remote host 192.168.1.4 is sending
[  4] local 192.168.1.90 port 40018 connected to 192.168.1.4 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  2.58 MBytes  21.7 Mbits/sec                  
[  4]   1.00-2.00   sec  1.92 MBytes  16.1 Mbits/sec                  
[  4]   2.00-3.00   sec  2.46 MBytes  20.7 Mbits/sec                  
[  4]   3.00-4.00   sec  1.19 MBytes  9.97 Mbits/sec                  
[  4]   4.00-5.00   sec  3.46 MBytes  29.0 Mbits/sec                  
[  4]   5.00-6.00   sec  3.72 MBytes  31.2 Mbits/sec                  
[  4]   6.00-7.00   sec  1.72 MBytes  14.4 Mbits/sec                  
[  4]   7.00-8.00   sec  1.71 MBytes  14.3 Mbits/sec                  
[  4]   8.00-9.00   sec  3.77 MBytes  31.6 Mbits/sec                  
[  4]   9.00-10.00  sec  1.87 MBytes  15.7 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  26.9 MBytes  22.5 Mbits/sec  4549             sender
[  4]   0.00-10.00  sec  24.4 MBytes  20.5 Mbits/sec                  receiver

iperf Done.
osmc@osmc:~$

And a fresh log after the update: https://paste.osmc.tv/enozajifak

sam_nazarko · 22 June 2019 22:10

There would be no kernel changes responsible for this.
I did merge some IPTables changes in the kernel config – but I’d be surprised if that’s the cause of the problem.

Sam

sojer2005 · 22 June 2019 22:15

Thanks for this information. I am available to help troubleshoot and solve this problem as a tester.

bmillham · 22 June 2019 22:22

Do you really need the GB USB adapter? I have lots of 4K HDR and have never had buffering issues with my 4K using the built in connection.

sojer2005 · 22 June 2019 22:27

I have had occasionally some buffering and sound issues on 4K HDR content, which really pissed me off (even with nfs fstab enabled) . After installing the adapter it has worked perfectly - zero problems. Faster skipping, general more pleasant user experience.

bmillham · 22 June 2019 22:43

I have autofs mounted NFS drives and have not had the issue. But I do not normally do skipping.

(autofs and fstab will have the same performance, so that would not make a difference)

It may just be something with how the content was ripped that’s needing more bandwidth. All of my UHD content was ripped by myself and not remuxed in any way.