[solved][TVH] Some recordings start with audio dropouts and buffering

truncrel · April 19, 2018 at 5:40 PM

Hello,

I'm not exactly new to the forum and hope it's not a duplicate, but I couldn't find another issue with a matching description. Spoiler: It's not fixable with buffermode=1 (files streamed via network). I posted this as general bug, but it works perfectly fine on smb or local playback. The following decription is copy-pasted mostly from Bug Reports thread, so some parts are maybe not necessary, but I'm not too sure.

Problem description:

All tested on a clean install (only setup Wifi and SSH and disabled Samba Server). Certain MPEG-TS (recordings) start jittery with sound dropouts and then buffering for sometimes 20 seconds. Happens again with every skip in the same file.

Problem isolation:

8.2.4 on RPi2 and 8.2.3.1(kszaq) on C2 do not show this behavior for the same files
tested on RPi2 and Odroid-C2 for 8.2.x (playback fine) and devel-leia-build (described problem)
~~tested~~ problem occurs on RPi2 with devel-build 201815 and most current devel-20180417082800
~~does not happen with every MPEG-TS file~~
happens primarily with HD content
currently reproducible with every file I recorded of a certain TV show
no network bottleneck, tested with iperf3 and vastly different WiFi-Receivers (one with effectively 30mbit/s throughput and the other with 100mbit/s)
also happens with deactivated hardware acceleration (RPi2 and C2)
same files/recordings are played back fine via smb and problem happens only if I open it via recordings in TVHeadend (recorded with TVH)
TVH versions are 3.4.27.1 (on LE 8.2) and 4.2.13.2 (on LE 9) and the problem occurs only on the latter

If it helps I can upload a snippet of one of the problematic files.

Kind regards,

truncrel

truncrel · April 19, 2018 at 9:11 PM

CvH : Why is this moved to Amlogic when this also happens on the RPi2? It happens only within TVHeadend client and only in the version that is in LE9 development build.

**CvH** · April 19, 2018 at 11:19 PM Official Post

sry I was too quick in moving

truncrel · April 20, 2018 at 4:10 PM

I want to remind that this only occurs on TVHeadend Client and not via SMB and the same files and otherwise same setup.

I didn't find anything too weird in the logs (especially when compared to the working logs). However I found that the RAM usage seems way too low at the start of the video. It is as if the video is not buffered at all. This is in contrast to SMB which has about 10mb buffer at start and the old TVHeadend which has about 10mb buffer at start with the same recording. Buffering over SMB seems nevertheless way more aggressive than with the old and working TVHeadend client.

And yeah that seems to be the culprit. The new TVHeadend client buffers incredibly slow in comparison with smb or the old TVHeadend client. Any ideas why that is?

**CvH** · April 22, 2018 at 12:37 AM Official Post

hmm strange, never heard of such an issue but as K18 is at development this might be something "new"

did you tried an milhouse build (LibreELEC Testbuilds for RaspberryPi (Kodi 18.0)) if the same problem appears there too ?

truncrel · April 23, 2018 at 11:51 AM

Thank you for your reply CvH

The problem persists on Milhouse builld (TVHeadend-Client 4.2.14? the 999 in front of version is probably a workaround).

**CvH** · April 23, 2018 at 5:18 PM Official Post

So pls try to get some kodi.log , maybe the problem gets visible

truncrel · April 23, 2018 at 9:06 PM

I made debug logs for the working (which is LE8) and the one that isnt and saw no different messages what so ever. I can attach it, it is very long however (16k+ lines). The log was made with trace logging from TVHeadend client which is very spammy.

**CvH** · April 23, 2018 at 10:29 PM Official Post

yea pls zip and upload it, MAYBE, maybe not

truncrel · April 24, 2018 at 3:43 PM

Here it is

truncrel · April 30, 2018 at 6:04 PM

With the latest build from Milhouse it's still the same. Version of the client didn't change, but the fault may be in the dependencies, so I gave it a try. Also connected the "High Gain" Wifi-Stick* to the RPi2 and the result remains the same. Buffer is still not really filling. I guess something like 8MBit/s or a bit more because SD Recordings don't show this behavior very often, but yeah, it happens even there.

*(measured data rates with iperf3 from server to client are around 95-100mbit/s)

**CvH** · May 2, 2018 at 8:10 PM Official Post

hmm

Code

ERROR: ffmpeg[596FE380]: [h264] SPS unavailable in decode_picture_timing
DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - Getting play position 0 for recording strassen stars
ERROR: ffmpeg[596FE380]: [h264] non-existing PPS 0 referenced
DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - Getting play position 0 for recording strassen stars
ERROR: ffmpeg[596FE380]: [AVBSFContext] Invalid NAL unit 0, skipping.
ERROR: ffmpeg[596FE380]: [h264] SPS unavailable in decode_picture_timing
ERROR: ffmpeg[596FE380]: [h264] non-existing PPS 0 referenced
ERROR: ffmpeg[596FE380]: [h264] decode_slice_header error
ERROR: ffmpeg[596FE380]: [h264] no frame!
DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - vfs read id=2 size=4096
DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - sending message [fileRead : 6086]
DEBUG: AddOnLog: Tvheadend HTSP Client: pvr.hts - received response [6086]
ERROR: ffmpeg[596FE380]: [h264] SPS unavailable in decode_picture_timing
ERROR: ffmpeg[596FE380]: [h264] non-existing PPS 0 referenced
ERROR: ffmpeg[596FE380]: [AVBSFContext] Invalid NAL unit 0, skipping.
ERROR: ffmpeg[596FE380]: [h264] SPS unavailable in decode_picture_timing
ERROR: ffmpeg[596FE380]: [h264] non-existing PPS 0 referenced
ERROR: ffmpeg[596FE380]: [h264] decode_slice_header error
ERROR: ffmpeg[596FE380]: [h264] no frame!

Display More

from my perspective this sounds like an ffmpeg/kodi problem, could you try to revert the builds till you have an working state ?

truncrel · May 3, 2018 at 11:52 AM

I opened an issue in pvr.hts github yesterday before you posted or at least before I saw your post. Thank you for your suggestion. I think I found the offending version which is in Milhouse 2017-09-12.

**CvH** · May 3, 2018 at 12:08 PM Official Post

Quote from truncrel

found the offending version which is in Milhouse 2017-09-12

the first not working version ? or the last working ?

truncrel · May 3, 2018 at 2:31 PM

The first version that exhibits the described problem. It wouldn't be offending otherwise, would it? :p

**CvH** · May 3, 2018 at 4:34 PM Official Post

I asked milhouse if he sees something that could triggers that problem, I can't find something that is obvious

truncrel · May 9, 2018 at 10:22 PM

Meh, this gets frustrating. I wanted to test this bug with reverted versions of kodi and pvr.hts to pinpoint the problem there or at least try. But I got stuck before that. On the most current version (070518 it was at that time) it shows the same problematic behavior on Arch, which is just what I hoped for basically. But I have that on my laptop and it is slow, so I moved to a beefier PC, which is way older, but still has more CPU power for compilation aaaand it works... crap.

First of, the only line that the logs from LE8.2 and LE9 differ are the lines with

Code

Getting play position 0 ....

These lines are also present on the working version on the "beefier" PC which runs Ubuntu, but I outline the config of the x86 computers.

Not working config (Laptop):

- i5-7200U

- 8GB RAM

- SSD

- Arch Linux

Working config (PC):

- Phenom X4 965

- 12GB RAM

- mechanical HDD

- Ubuntu

- 40mbit/s network throughput

Basically the only difference that might be relevant is the OS. However the outline might help anyway even if it only rules out some things (at list disk speed and network speed doesn't play a role).

I also wonder if anyone else has that problem at least on C2 or RPi2 or even more interesting doesn't have that problem with a similar setup (ARM-SoC-based client and separate TVH server).

truncrel · May 24, 2018 at 4:58 PM

Ok, so I tested it further on Arch. I reseted kodi to commit f92bedcb63bf5d8cf6a1aa55b760aced6c7fc1f1which is from 11.09.17

Compiled it and fixed everything to make the build process work (mostly renaming). Also reverted TVH to an older version. I tried the usual videos and they worked *yay*.

Then I cherry-picked these four commits (and didnt change anything else): LinuxRendererGLES: implement hq scalers by lrusak · Pull Request #12474 · xbmc/xbmc · GitHub and voila the problem begins again.