Posts by truncrel

Ah ok, thank you for your answer

Hello,

Basically it is already in the title. I am not sure that this is only on Odroid-C2/amlogic devices as I use milhouse build on my RPi2 without this issue, but I think it is.

In debug I have these messages

DEBUG: CAddonInstallJob[pvr.hts]: requires kodi.binary.instance.pvr version 5.9.0 which is not available
ERROR: CAddonInstallJob[pvr.hts]: The dependency on kodi.binary.instance.pvr version 5.9.0 could not be satisfied.

DEBUG: CAddonInstallJob[inputstream.adaptive]: requires kodi.binary.instance.inputstream version 2.0.6 which is not available
ERROR: CAddonInstallJob[inputstream.adaptive]: The dependency on kodi.binary.instance.inputstream version 2.0.6 could not be satisfied.

and therefore it's not possible to install anything that depends on these including most(or all) PVR clients. What I also noticed is that pvr.hts client is still on version 4.12.4 although it is updated (4.13.x) in the LE github repo.

The build you are referring to is about 9 months old; have you tried a recent version? Either this or this ?

Also tried a clean install with the build from test.libreelec.tv on Odroid-C2 with the build from 20th of June and got the same error. As far as I can tell the build from 24th won't bring anything that would change that.

milhouse could it be that this is related to the old kernel, because the same change is working on RPi2? I saw something regarding this from you, but I don't know where and in which context anymore

Ok, the problem is resolved by new pvr.hts version 4.3.0 thanks to ksooo

It would even help if someone could reproduce it or, also very helpful, can't reproduce it. It could be valuable for error isolation, especially with bitrate and setup known

First of, thanks for the answer.

I guessed that it is not the main cause of this problem, but rather triggering an error that was somewhere before. Also the problem might be directly related to TVH after all, because it doesnt happen with SMB (as mentioned in OP). It was however the first PR that leads to the described (mis)behavior and I thought it is more than nothing.

What else can I do to isolate the error or even find it?

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.

I'm a bit late to the party. How can you use ir-keytable with keyboard keymaps? I'm asking because I usually use double maps for remotes via modifier ("longpress"). This is currently only possible in keyboard keymaps iirc.

PS.: Is it normal that certain protocols such as NEC (and I think sanyo and JVC as well) are not really working well, having erratic multipresses? Not a big issue for me, just asking.

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

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).

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

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.

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)

Here it is

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.

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).

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 : 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.