Problems with LiveTV stuttering on Vero 4k+

Help and Support Vero 4K / Vero 4K +
1

I’ve had a problem with LiveTV stuttering ever since receiving my Vero4k+

By stuttering, I mean that for a second or so the playback (Video and Audio) stops, and I see the spinner in the middle of the screen; then playback starts back up again. There are no artefacts or errors in the TVHeadend Server logfile. Sometimes it will stutter a few times in a row, sometimes just once. I can normally get it back to normal by switching channels back and forth.

  • I am using the pvr.hts plugin, which is connecting to a Debian Stretch Server with TVheadend 4.2.5

  • I have used TVHeadend on this server for the past 2-3 years without these stuttering problems on other clients.

  • The TVheadend server has 2x MyGica T230 DVB/T2 USB sticks (for Freeview), and 2x DVBSky S960 DVB/S2 USB adapters (for Freesat).

  • The stutters occur more frequently when tuning to Freesat channels (i.e. using the DVBSky S960 adapter) - these appear to have higher bandwidth and an additional narrated audio track.

  • I have no problems whatsoever when playing back recordings, it only affects playback of LiveTV.

  • I am also running kodi on an PRi3 in another room, with latest stable LibreELEC v8.2.5 - PVR live playback is flawless on this machine

  • After alot of testing, I seem to be able to reduce the stuttering with the following settings:

    • Sync playback to display: disabled
    • Adjust framerate: “Always” (Note: have also tried “On Start/Stop”)
    • H/W accelleration set to “always” for all codecs
    • Fallback framerate set to “off” in PVR settings - have also tried setting to 50Hz

  • I have a soundbar connected via SP/Dif and have enabled the Mute HDMI Audio option.

  • I have tested with both -119 and -121 (video improvements) kernels (https://discourse.osmc.tv/t/testing-vero-4k-4k-video-improvements) both have same issue

  • After reverting the video improvements kernel, I still get occassional stutters but they seem less frequent.

  • I have tried iperf3 tests between Vero->TVHeadend Server - results are good both ways ~900Mbps (ran a test for 30 minutes)

  • Have tried various tweaks to the TVHeadend settings - Status Period, Input Buffer, Use Packet Backlog (none had any effect - though decreasing the Status Period made things worse so i set it to the maximum 8000ms)

  • When problem occurs I see the following error in kodi.log:
    WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

  • There was no other traffic on the network whilst performing the tests

I’m starting to wonder whether the Gigabit adapter in the Vero4K is a little too fast, causing the buffer under-runs - i.e. it’s grabbing the data too fast.

I’ve posted debug logs when I reproduced the problem this morning on the -121 video improvements test kernel are here: https://paste.osmc.tv/nuhicozara

The times I hit the stutters with debug logging enabled were
12:13:04
12:25:48
12:32:57
12:36:31
12:49:44

This afternoon I have tried adding an Audio Stream filter in the TVHeadend Config to strip out the narrated (nar) streams, which seems to have reduced the stuttering - in 2 hours I only had two occurrences, but I still get the odd stutter.

Any thoughts on what to try next?

2

Have you updated from stretch-devel in the last 24 hours and are you using bluetooth? There was a CPU hog which has just been fixed and improved my TV experience (albeit over wifi).

3

I updated from stretch-devel at approx midday today.

I had to do:
apt-get install --reinstall vero364-image-3.14.29-121-osmc

…since I already had the 121 kernel installed, and had backtracked to the previous kernel whilst testing the different kernel versions using the dpkg -i command at the top of the video testing thread.

My uname -a is currently showing:
Linux vero4k 3.14.29-121-osmc #1 SMP Sat Sep 29 05:20:26 UTC 2018 aarch64 GNU/Linux

And this is the kernel upon which I did my tests this morning, to generate the debug log.

Running ‘top’ I can see that my CPU is pretty cool at the moment, I’m playing a recording currently and the CPU is only 12% utilised. Is there anything else I can do to ensure I don’t have the bluetooth issue?

Note: I don’t have any bluetooth devices connected.

4

The BT fix was not in the kernel. If you did a dist-upgrade first you should be good. But if BT is off you would not have been affected, anyway.

Can you post full logs, please? grab-logs -A

5

Sure thing, the link was already in my inital post but here it is again:
https://paste.osmc.tv/nuhicozara

6

You have posted only the apt logs

7

Apologies, I had used
grab-logs -a

Rather than uppercase ‘A’ :laughing:

Unfortunately, I’ve rebooted a couple of times since so the kodi log is now gone, and my other half is now hogging the tv :sweat_smile:

I’ll reproduce the issue next time I get chance, and gather a fresh set of logs…

8

Admittedly i did not do a full dist-upgrade earlier, as my objective was to get back to the 121 testing kernel.

I’ve just done an
sudo apt-get update && sudo apt-get dist-upgrade

And it did find one update to libssh-4

libssh-4 armhf 0.7.3-2+deb9u1

So this is now installed…not sure if thats the update pushed in the last 24hrs

I’m also going to try disabling bluetooth completely via MyOSMC before my next round of testing.

UPDATE: I checked in MyOSMC and i already have bluetooth disabled

9

I doubt the Ethernet is too fast. But if you drop to 100Mbps using ethtool does it help?

Sam

10

I reproduced the stuttering last night and tried sending over logs at 01:02:47 uk time but it didnt give me a proper url:

osmc@vero4k:~$ grab-logs -A
Logs successfully uploaded.
Logs available at https://paste.osmc.tv/<html>

I’ve tried again twice this morning with same result unfortunately.

11

That is strange (maybe too big).
Try grab-logs -S -A to store locally. Or try manual upload via paste-log .kodi/temp/kodi.log

12

-S was not a recognized parameter. I checked the switches and looked like i wanted -C

So i tried
osmc@vero4k:~$ grab-logs -C -A
Logs copied to /boot/uploadlog.txt on the SD card FAT partition

The file is 305mb

I then tried this
osmc@vero4k:/boot$ paste-log uploadlog.txt
Unable to upload log. Log file is too large. (305MB)

Any other suggestions for getting this uploaded.

kodi.old.log is 301mb - it covers approx 3hrs usage with debug logging, and pvr.hts debug tracing enabled.

13

Can you cut a significant part of it from the time when you played and had issues and upload that via paste-log?

14

Tried trimming somewhat and had another go

Unable to upload log. Log file is too large. (20MB)

I can probably trim further. Whats the max size for uploading logs?

15

I am not 100% sure but most likely <1M which should already be thousands of lines.

Maybe you can filter a certain time using grep

16

10M is the limit from the top of my head.
We’ll increase that to 100M end-of-year.

17

As mentioned, I had enabled debug tracing in the pvr.hts addon settings, thinking that might be helpful. :unamused:

However, it looks like this was contributing greatly to the file size (~2.8 million lines).
I’ve trimmed those out using grep and that gets the size down to 4.2MB.

I’ve uploaded this trimmed version: https://paste.osmc.tv/wakedupaco

The stuttering/entries in question can be found in kodi.old.log at the following times:

22:30:31
23:05:00
23:09:16
23:47:49
23:48:02
00:05:13
00:22:42
00:29:16

I still have a copy of the 300MB file, so can provide the pvr.hts trace lines if required.

18

Had also meant to mention, I can play 4k HDR videos over samba shares which reside on the same server that hosts TVHeadend without any problems, so bandwidth between the two machines certainly isn’t a problem.

19

Here is another debug log from tonight…I had a stutter at 21:59:51.

https://paste.osmc.tv/cebarovobu

20

This was caused by an interruption in the stream which causes a decoder reset:

21:59:51.072 T:3630985984 INFO: CVideoPlayerVideo - Stillframe detected, switching to forced 50.000000 fps
21:59:51.072 T:3630985984 DEBUG: CPullupCorrection: pattern lost on diff 100000.000000, number of losses 1
21:59:51.086 T:3630985984 INFO: CVideoPlayerVideo - Stillframe left, switching to normal playback
21:59:51.086 T:3724538624 DEBUG: Stream stalled, start buffering. Audio: 15 - Video: 0
21:59:51.086 T:3724538624 DEBUG: CVideoPlayer::FlushBuffers - flushing buffers
21:59:51.090 T:4077015632 DEBUG: CRenderManager::PrepareNextRender m_QueueSkip:77 iter.pts:140.920 front.pts:140.820 renderPts:141.009 latency:0.080
21:59:51.091 T:3630985984 DEBUG: CAMLCodec::Reset

Would be interesting to know if this happens for recordings.