[Resolved] PVR Buffering with TVH 4.2 and LE 8.2.0

  • Hi,


    I'm having issues with PVR buffering on my Wetek Play (1) and LibreElec 8.2 + HTS Tvheadend 4.2.3-20 ~ LibreELEC Tvh-addon v8.2.112.

    Before updating to 8.2.0 I was using TVH 4.0 which was not ideal but was working fine. Right now after upadting to LE 8.2.0 I was forced to swtich to TVH 4.2 which for some reason buffers the DVB-S2 stream every couple minutes. I'm not sure what can be the issue here.

    I will post some logs but because of the Wetek Play poor performance, when I enable debug and play any PVR channel the image is very slow and I get 15fps which is causing tons of useless log entries. Is there any other way of enabling debug without OSD info?

    UPDATE

    I was able to run debug without OSD thanks to the advancedsettings.xml and here is the logfile :

    kodi.log.zip?dl=1

    Thank you!

    Edited once, last by newkind (October 30, 2017 at 3:32 PM).

  • Code
    wget http://chewitt.libreelec.tv/advancedsettings.xml -O /storage/.kodi/userdata/advancedsettings.xml
    systemctl restart kodi

    ^ that will put in debug without OSD

    Thank you, I was already able to do it and I have added the logs to the first post.

  • A follow up. Here are the logs from Kodi and HTPS TvH Addon : XVDQ

    And here are the TVH logs with some OSCam entries : BJKK

    Let me just add that TimeShift is disabled both. Also the EPG transfer is set to Asynchronous transfer in the addon, and in the PVR configuration to be not updated while playing and not kept in the database.

    If anyone has any ideas about what can be wrong, I'd highly appreciate that.

    Thank you!

  • Sorry for late reply, didn't had time to play with the logs.

    I'm sorry for pasting not complete ones before.

    Here are full logs :

    1. Kodi (had to split it in parts as it was too big for sprunge) :

    - Part 1 : LHDh

    - Part 2 : dACK

    - Part 3 : CcTg

    - Part 4 : AhJi

    - Part 5 : SgcQ

    At the end of the last part of log you can see that it started to drop packets :

    2. TVHeadend 4.2 : aWNb (service.log) ; HjHQ (extended debug with +all flag)

    One thing I noticed is that it creates TimeShift buffers even though the TimeShift is disabled.

    Code
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-0 (size 38624422)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-60132877 (size 41502396)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-120132877 (size 38981819)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-180132877 (size 35435610)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-240132877 (size 37313429)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-300132877 (size 40758738)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-360132877 (size 41805400)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-420132877 (size 40017993)
    2017-11-03 18:58:02.900 [  DEBUG]:timeshift: ts 11 remove /storage/.kodi/userdata/addon_data/service.tvheadend42/cache/timeshift/buffer/11/tvh-480132877 (size 32451810)

    Also I got all extra EPG modules disabled and still I can see the informations to notify the HTPS addon about event changes and that TVHeadend created disabled by me EPG modules :

    UPDATE :

    I checked the config files in user_data directory and TimeShift config file shows that it's enabled even though the web admin shows the enabled checkbox unchecked. I'll try to disable it via config file and see if it's gonna make it any better.

    Edited 3 times, last by newkind (November 3, 2017 at 9:16 PM).

  • the stream problems are due too late keys from oscam (6sec+) - have a look at oscam for this - it should output some errors

    the timeshift problem is a bit suspicious, you can try to deactivate tvh, and delete /storage/.kodi/userdata/addon_data/service.tvheadend42/timeshift/config that reverts it to default

  • I just checked my LiveLog in OSCam and I can see only two entries that are around 1000ms - rest is around 400 - 650ms.

    Not sure why in the logs they would appear as 6sec+...


    After disabling TimeShift via config file (like mentioned above) seems to be better now (although still not sure if fixed). I don't want to praise the day before the sun goes down so I'll keep testing it some more and report back tomorrow.

  • Hmmm maybe it was a one time situation with this late key, but I know for sure that it's not the root of the problem. The OSCam config and CA config in the TVH are the same as I used with 4.0 and it didn't had such issues.

    Anyways, just like I mentioned, I'm gonna report back In couple hours after some more testing ;)

    Thank you for your answers ;)

  • Back with a report after some extra hours testing. It looks like it's RESOLVED :) So far no issues and all works flawlessly. I hope it will stay like that. Since my Wetek Play isn't a very fast device, I think that the TimeShift could slow it down alot.

    For others : There might be a bug in TVH 4.2 in TimeShift configuration where the "Enabled" checkbox is unchecked but it really is enabled in the config. Please check the TImeShift config file in userdata/addon_data/service.tvheadend42/timeshift/config and make sure it's disabled there.

    I have also increased the Input Buffer and Status period in my adapter configuration just to be sure. Not sure if it helps anything, but so far it doesn't do any harm.

    vt1Gqs3gYL5NrocOtPo0UZ0mVqReqW.png