Posts by jahutchi

    I was seeing the same on my RPI3. I often leave it in the EPG whilst Idle. I would return to the RPI3 and find it was frozen on the EPG screen. I also noticed in the top-right corner it would say "Loading Channels from clients - 0%" or similar so maybe it was doing something PVR-related when it froze.

    I could get it going again by SSH'ing into the machine and running "systemctl restart kodi" - or simply with an old-fashioned poweroff/poweron at the plug.

    On my RPI3 I have a very minimal build - just pvr.hts plugin, itvplayer, docker, inadyn.

    I have my TVH Server in another room on generic x86 machine which I have left at v8.0.1.

    I've just reverted back to 8.0.1 on the RPI3 and (fingers crossed) it now seems more stable.

    Happy to try putting the RPI3 back to v8.0.2 and provide logs if someone could advise which logs to provide.


    I'm finding that on my LibreELEC 8.0.1 installation I am unable to download the following file using wget:

    MediaPC:~/downloads # wget
    Connecting to (
    Connecting to (
    wget: error getting response: Connection reset by peer

    However, the same URL from my FF browser on my laptop works fine.

    I find the same with other files on github too, and my machine seems incapable of auto-updating from some repositories because of this e.g. Zomboided for the OpenVPN addon.

    I have a Generic x86_64 machine and also an RPI3 which are both running LE 8.0.1.
    Both machines fail with the same error above when trying to download this file.

    Do some ssl packages need to be updated or something?

    At the moment, whenever I find packages that won't update from the repos then I download the zip file manually via my laptop and sftp it across.

    NOTED: This is a banned add-on - I actually only want to use this repository for the TV Guide Full Screen add-on which looks awesome.

    Any thoughts?


    so revert 1 is not working, revert 2 is working so the problem is somewhere between

    okay going to build some images :)

    Is it worth picking this back up? smp has confirmed that the issue is still present in kernel 4.11-rc4 so looks like it's not been fixed upstream.

    I'm happy to do some more testing to help pinpoint the dodgy commit.

    Official 8.0.1 RPi2 is still unusable for me. That's why I did a custom 8.0.1 with kernel 4.8.
    I can only test the RPi2 builds. No idea what's going on with Generic builds, you will have to test those yourself.

    I've been using the generic build you supplied without media build and it's working perfect for me. I did try the official 8.0.1 release straight after it was released but the continuity counter errors returned. Hopefully someone will figure out what's been broken in the kernel that's being shipped with the official builds.

    okay next try Index of /Test/dvbskys960/

    1.1-1.3 there are still more than enough commits between :/ but somewhere we have to begin

    I tried all 3 builds. However, these builds don't work whatsoever since Xorg fails to start with the following error in the logfile Xorg log: Failed to load /usr/lib/xorg/modules/drivers/ /usr/lib/xorg/modules/drivers/ cannot open shared object file: No such file or directory

    This morning I tried: LibreELEC-Generic.x86_64-8.0.0-rev1-6b5e09a.img.gz
    This one still had the Continuity Counter errors - and infact they seemed to occur more regularly than with all the other 4.9 kernel-based builds I've tried (like every 10-20 seconds, rather than every 2-3 minutes).

    I'll try to find time at some point to test the other two.

    I have just been testing: LibreELEC-Generic.x86_64-8.0.0-rev2-2937f37.img.gz
    This one seems to resolve the issue - I've been playing a HD channel for over an hour now without any issues.
    I'll continue running this build for the rest of the day just to be sure, but early indications are good.

    here are 3 versions (Generic) with partly reverted kernel 4.9
    Index of /Test/dvbskys960/

    would be nice if someone could test it, if one of the images work it is much much easier to track down the faulty commit

    This morning I tried: LibreELEC-Generic.x86_64-8.0.0-rev1-6b5e09a.img.gz
    This one still had the Continuity Counter errors - and infact they seemed to occur more regularly than with all the other 4.9 kernel-based builds I've tried (like every 10-20 seconds, rather than every 2-3 minutes).

    I'll try to find time at some point to test the other two.


    I'll play around with the code as you suggest when I get chance... in the meantime this link does seem to confirm your theory that Window ID's in the range of 10600-10699 are for various PVR functions - though it looks like 10600-10610 are the only ones currently assigned. Looking at that list, I wonder whether we may want to also add 10700 -10799?

    jahutchi from thread-4067-post-38733.html#pid38733

    Maybe I'll look to see if I can detect Live TV and switch based on that. I think I looked at this before and concluded I couldn't.

    That would be great if it were possible - I'm using TVHeadend here.

    In the meantime I've been looking at the API but can't find a way to achieve what I'm after.

    I only want to reconnect the VPN if I'm sure that one of the filtered addons is not running e.g. BBCiPlayer... but I can't see any way to reliably detect that. Also, obviously if the wife hits stop then she is still within BBCiPlayer and may then try playing another program... so forcing the VPN to reconnect when the stop button is pressed is probably not the way to go.

    Looks like we're in a bit of a catch 22 situation.... We do use Live TV all the time so if there's any way to detect that LiveTV is playing and re-establish the VPN connection at that point then I'm all ears.

    It won't reconnect until it sees another add-on (ie you have to do more than just exit to the main Kodi screen).

    That's certainly the behaviour I see.... I guess the question then, is whether it's possible to improve it to detect when the user has exited the excluded add-on (I'm guessing not, or it probably would have been done by now), rather than wait for them to enter another add-on before re-establishing the VPN connection?

    I have various background shell scripts that rely on the VPN being active, and those scripts exit out if the VPN is not up...
    When my Wife watches TV during the day she comes out of BBC iPlayer and then typically goes into Live TV (which isn't an Add-on, so the VPN is not auto-reconnected). If I then come to the machine and go into the OpenVPN add-on, I don't have to click anything and the VPN re-connects itself.

    I've been looking at the API and managed to implement a basic cron job to re-establish a connection at 1am each morning if it's not already connected by basically running:
    /usr/bin/kodi-send -a "RunScript(special://home/addons/service.vpn.manager/, Connect 1)"

    It seemed 1am is probably safe, as we won't be watching BBCiPlayer at that time.

    I could run the API sooner, or even trigger it by my scripts (which run throughout the day). But I'm not sure it's possible to guarantee that an excluded addon (BBC iPlayer) is not running.

    Maybe I could look at re-programming my "Stop" button to run a 2xStep shell script - e.g.
    kodi-send -a "Stop"
    kodi-send -a "RunScript(special://home/addons/service.vpn.manager/, Connect 1)"

    Rather than just mapping it to a Stop action.... maybe that would achieve what I'm after???

    Typically, there are credits after a program finishes on iPlayer, so my wife would hit Stop to come out.

    One question / something I can't quite get working with the Addon...

    In my Addon Filter settings I've put "BBC iPlayer WWW" in the Excluded List (add-ons for which a VPN will not be used).
    Once I've finished using the Addon I would like the VPN Manager to reconnect to the VPN it was previously connected to (i.e. Revert to previous state) but it's just not happening :-(

    Maybe I need to adjust a couple of the settings?

    I've ticked the "Revert to previous state for Non-Filtered addons" option, and have my connection validation frequency set quite low (30 seconds)
    I have also unticked the "Reconnect if connection lost during playback" option - as that gave me problems when watching live tv as it would stop whatever was being played should it need to reconnect.

    It seems to work better if I add BBC iPlayer to the inclusion list. I can use a UK VPN from my provider (PIA) as Connection#2 and assign the addon to that. However, BBC iPlayer refuses to play when connected to the London VPN (presumably BBCiPlayer/Akkemai have the VPN IP's blacklisted so I'm not classed as being on a true UK IP Address).

    Obviously I can workaround this by going into the OpenVPN addon and connecting manually after coming out of BBC iPlayer...but that's not very Wife-friendly ;-) so would prefer for the VPN to just reconnect when I leave the BBCiPlayer addon.

    Another discovery is that when I go back into the OpenVPN addon after coming out of BBC iPlayer then it seems to connect automatically before I click anything - so at that point it seems to know that it needs to reconnect...So not too sure why this is not happening automatically?

    I'm on v2.6.0 of the Addon and LibreELEC 8.0.0

    Any thoughts?

    I have here Index of /Test/dvbskys960/
    an Generic image with 4.9-RC1, would be nice if someone could confirm that the error is there or not

    I have just been testing this build and the error is there too...
    I received Continuity Counter errors in my tvh logfile and a blocky on-screen picture within a couple of minutes of playing live tv:

    Prior to that I've been running smp's Generic build with the 4.8 kernel for a whole week, and didn't get a single Continuity Counter error.

    Let me know if there are any more 4.9-based builds you'd like me to try, if that would help pin-point where the problem was introduced.

    what tuner do you use ? (pls test also Generic x86_64, ver. 8.0.0, kernel 4.8.13, with media_build - tx!! smp)

    We are currently suspecting that some usb change made it worse then in 4.8, but still didn't found a solution.

    I'm using the DVBSky S960 USB DVB-S2 adapter.

    BTW I had also posted here: thread-4878.html and tried the various test builds with the 4.9 kernel which you sent me last week...

    I shall test with Generic x86_64, ver. 8.0.0, kernel 4.8.13, with media_build later today or tomorrow and report back.

    Dropbox - Link not found - Generic x86_64, ver. 8.0.0, kernel 4.8.13, without media_build

    Dropbox - Link not found - Generic x86_64, ver. 8.0.0, kernel 4.8.13, with media_build

    Thanks ever so much smp... I've installed your LibreELEC-Generic.x86_64-8.0.0.kernel.4.8.13.without.mb.tar on my HTPC and it's been running a good couple of hours without any of those dreaded Continuity Counter errors (the 4.9 kernel-based builds would generate the errors every few minutes). So finally I can move away from the Alpha 9 release :)

    Hopefully someone will figure out where the problems lie in the 4.9 kernel and fix it upstream for future releases, but in the meantime I can finally sit back and enjoy the LibreELEC 8.0.0 release.

    I'm also experiencing continuity counter errors with my technotrend s2-4600 usb tv card on my pi3 on latest Milhouse build. Livetv is ok, only recording has issues, even when kodi is stopped (systemctl stop kodi).

    tvheadend service log KahD
    dmesg hgag

    It might be worth checking this thread: DVB issue since LE switched to kernel 4.9.x

    The problem seems to lie somewhere in the 4.9 kernel. LibreELEC switched from a 4.8 to a 4.9 kernel between the alpha 9 -> alpha 10 builds, and this seems to be where the problem was introduced. On the thread above, smp has posted links to some 8.0.0 builds he's put together with a 4.8, rather than 4.9 kernel.

    This morning I have installed his "LibreELEC-Generic.x86_64-8.0.0.kernel.4.8.13.without.mb.tar" build on my HTPC - which has been running a couple of hours now without any Continuity errors :) ... on the 4.9 kernel-based builds I would receive Counter Continuity errors normally within a few minutes.

    On the thread above there is a link to his builds for RPi2/3 on post #14.