Posts by jahutchi

    ^ that's what git bisect does; you mark a good and bad commit and it starts halving the list of commits until you find the problem one

    Understood. So it still may take ~50 builds to get close to the problem even when taking the half-way points! ...darn.


    From previous posts it sounds like it will be much easier to bisect the kernel on a Generic x86 machine that hits the problem - which I do have.


    I'd be happy to have a go at performing the bisects and compiling/testing some builds. Not something I've done before though so if anyone could provide assistance, or point me at some reliable links/documentation to get me started then I'll try my best to figure it out.


    However, if it's simply going to be too difficult for a novice then I'll step back and hope someone else with suitable expertise is able to debug the issue.

    the problem is between rev1 and rev2 are a huuuuuuuughe number of commits so its is pretty useless to to recompile if you can't do it by your self (maybe ~50 builds are needed to get close to the problem)

    Ok, just thought I would make the offer. I'm happy to do the testing, even if it means testing ~50 builds so my offer still stands. Unfortunately I have absolutely no experience at compiling kernels and bisecting the commits. I am fairly technical so if someone could provide some fairly comprehensive instructions on that then I would give it a go.


    Failing that, I wonder if it would cut down the number of potential builds if you were to build at "half-way" points each time. That is an approach I've used for solving similar problems before. Then we would know whether to go higher or lower than the current commit - again picking a half way point and checking the build. It's only an idea and I'm certainly no expert in this area - just thinking aloud.

    which DVB HW ?

    My machine (Acer Revo 3700R) has 2x DVBSky S960 USB DVB-S2 adapters and 2x MyGica T230 T2 USB adapters.

    I'm currently using the builds from smp with the 4.8.13 kernel (no media build) and don't get any continuity errors, and everything is perfect. I can even record/watch upto around 6 things at once without any artefacts etc :-)


    If I upgrade to the official release or anything with a 4.9+ kernel then I get continuity errors and artefacts every few minutes.


    Back on pages 3-4 of this thread you were sending me some builds to try out at various commit points, but I think this approach probably got too time-consuming...


    Previously, we found the issue was introduced somewhere between the commit points of these images that you supplied LibreELEC-Generic.x86_64-8.0.0-rev1-6b5e09a.img.gz and LibreELEC-Generic.x86_64-8.0.0-rev2-2937f37.img.gz


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


    okay going to build some images :)

    Not sure if you want to pick this back up.




    I am now using LE 8.0.1

    forlotto . I had something similar to the issue you're reporting. I was unable to get automatic updates working which also come from a github url. I ran some network traces and could see that my connections were being re-routed to the wrong ip by my isp (virgin media). I did a little googling and found that there were some anti-malware/parental controls which i could set in the myvirgin web interface. I had the problem both on and off vpn because the controls seemed to cause dns requests for certain hostnames to resolve to a virgin media ip. After i turned off those limitations in the myvirgin web interface then my dns requests routed to the correct place any everything worked as it should. It would be worth checking whether your isp has any similar anti-malware/parental controls, and if so switch them off and see if the problem goes away.

    Bisecting the kernel will be a lot easier on x86 where the upstream kernel can be used untouched.


    Bisecting kernel on Pi across the 4.8/4.9 boundary would need serious git skills due to the downstream patches changing.


    I am not a developer and have no idea how to bisect a kernel.


    However, I am able to easily reproduce the issue on my x86_64 machine.


    If a developer were able to perform the bisects & provide x86_64 test builds for me to download at various commit points, then I would be happy to work through testing each of those builds. My plan would be one per day - leaving it playing a PVR channel overnight, then check for continuity errors in the logfile the next morning and report back. Ideally the builds would be based on LE 8.0.1 (without media build) as that's what I'm running currently, so I'd be comparing like-for-like - knowing that only a different kernel has been swapped-in (without any other moving parts).


    If all that would be too much messing around, and it really needs the owner of an affected x86 machine to both perform the bisecting and testing then I'm afraid I can't help.... but thought I would make the above offer to help try and resolve the issue.

    Here are some examples of local streams from my machine


    Live TV

    14:02:43.189 T:140004189796096 NONE: VPN Mgr Debug: Changing VPN. Current playing pvr://channels/tv/All channels/pvr.hts_1304825683.pvr


    Library File

    14:05:53.865 T:140004189796096 NONE: VPN Mgr Debug: Changing VPN. Current playing /storage/tvshows/Bones/Bones.S12E07.720p.mkv


    PVR Recording

    14:09:09.342 T:140004189796096 NONE: VPN Mgr Debug: Changing VPN. Current playing pvr://recordings/tv/active/New_ Victoria/New%3a%20Victoria%20The%20Sins%20of%20the%20Father%3a%20Drama%20series.%20Despite%20giving%20birth%20to%20a%20healthy%20Prince%20of%20Wales%2c%20Victoria%20finds%20herself%20paralysed%20by%20an%20inexplicable%20sorrow.%20%5bAD%2cS%5d, TV%20(ITV%20Yorkshire%20HD), 20170917_200000, 1149230897.pvr

    My use-case is probably quite unusual....


    I have actually setup WindowID filtering to force it to reconnect when I use any of the PVR-related features. This is because I am using add-on filtering for certain addons e.g. BBC iPlayer, where I want the VPN to be disconnected (since they need a UK IP). When leaving the addon (e.g. BBC iPlayer), it does not automatically reconnect so I've reconfigured it so that the windows I use most commonly (e.g. TV Guide), trigger a reconnect.


    We discussed this back in March via PM and you gave me a hack to the code so I could force certain WindowID's (e.g. TV Guide) to reconnect the VPN. You then added the WindowID filtering logic to the code, and then I could remove my hack and use the built-in WindowID filtering.


    So I suppose I'm asking for the WindowID filtering I've setup to force it to reconnect to only take effect if there isn't video playing in the background. My hack of commenting that line out seems to kind of work though not 100% sure there won't be other side effects. It looks like the vpn_reconnect_while_playing does not take effect for the WindowID filtering.


    I have a suggestion for a future release....


    One thing that was annoying me was that if the VPN is dropped whilst playing LiveTV, then when you try to bring up certain windows (e.g. TVGuide) ontop of LiveTV with the current channel still playing in the background, then it reconnects the VPN, and playback stops.


    I managed to get round this by commenting out the following line in service.py:

    #Stop any media playing before switching VPNs around

    #if player.isPlaying(): player.stop()


    I had tried switching on/off the vpn_reconnect_while_playing option but that does not influence this line of code.


    Just wondering if an option could be added in future to decide whether or not a (re)connect will stop playing the video. Either that, or maybe it shouldn't run this line if the vpn_reconnect_while_playing is set to false?


    For the time being I have switched off automatic updates, since I'll need to repeat this hack after future updates.

    Annoyingly, I've tracked back and the reason I installed that repo, and it was so I could install ITV Player. Very annoying that such a widely used addon only lives in banned repos. I looked at posts on the official kodi forums and other ITV Player users share the same frustration! I hope they manage to get it into an official repo in future. For now...lesson learnt...and I'll just have to update ITV Player manually in future (if it breaks) using links on the official Release page of the kodi forum.


    Annoyingly, this all now means that the logfiles I posted here earlier will probably never be looked at now, so this bug, which affects several legitimate PVR users will go unfixed....

    I have removed the addon, and must say that I was mortified to find out that I had any kind of addon that is considered illegal, as I am actively against piracy and I hate to see the bad press that kodi receives because of these type of addons. I use kodi mainly for the fantastic PVR features which IMO blow any standalone PVR box out of the water (I think Krypton was the turning point in that respect). I am contributing to this forum to try and help identify issues and provide logs where possible to help the developers to address problems such as the one reported in this thread. I fully support your stance on the banned addons so will understand if you decide not to look any further into this issue. By providing these logs I only want to help improve the kodi experience for other users. I would be happy to provide more logs now that I've removed the questionable addon repo?

    As far as I can tell, this problem only exists on RPi, not on "regular" Linux?

    Incorrect. The problem occurs on my Generic x86_64 HTPC (Acer Revo 3700). I have the DVBSky S960. I am currently using the Generic v4.8 kernel builds supplied by smp earlier in this thread and this resolves the problem.


    It's probably dependant on hardware. Admittedly the Acer Revo 3700 is a little dated but with 4x 1.2GHz cores it should be upto the job. Whilst playing live TV my CPU is only around 20% utilised.

    I talked to a team member and it would be nice if the logs would have been debuglogs. So please enable debug logging first and then grab the log

    I enabled debug logging earlier today then left it in the PVR Section of the Home screen, and low and behold it crashed.


    Here is the debug crash log

    PGDD


    Note: This is on my RPi3 running LibreELEC 8.1.1, but I can reproduce on other LE versions too (8.0.1, 8.0.2).


    I can also reproduce on my Generic x86_64 machine, which hosts my TVHeadend server (LE 8.0.1 with Kernel 4.8).

    You will need to install and configure the pvr.hts addon in kodi so that I can connect to your TVHeadend installation.


    To clear out the old VDR stuff from the kodi database go into Settings > PVR & Live TV Settings > General > Clean Data.

    Please upgrade to a newer LE Version:


    Code
    1. 01:59:39.471 T:139829498733824 NOTICE: Running on LibreELEC (community) - Version: 8.0.1, kernel: Linux x86 64-bit version 4.8.13

    I have upgraded my RPI3 to the very latest v8.1.1 build (kodi 17.4) and the problem still exists.


    I left kodi in the PVR section of the home screen last night, and as before it crashed out.

    fWYR


    It really is that easy to reproduce - I just leave it in the PVR section of the Home Screen.

    If any further logfiles are needed to help solve the problem then I'm happy to supply them.

    This problem is not going away unfortunately.


    On my Pi3 it has crashed 5 times already this morning with no user intervention.

    Seems to always crash when left in the EPG on a past event.


    Here are the 5x crash logs for the occurrences this morning:


    SUDD

    WNIL

    THLc

    MXUX

    EQFJ


    Every time the crash log seems to end with:

    ERROR: exception in CApplication::FrameMove()


    Kodi seems to restart itself correctly of it's own accord. If I upgrade to 17.3 (LibreELEC 8.0.2) then I find that it will hang instead of automatically restarting kodi (hence why I went back to 8.0.1).

    Here is also a crash log from my generic x86 machine, which also crashed this morning.


    JKPh


    Any thoughts on what might be causing these crashes - is there anything in the crash logs that gives any clues?

    The recent discussion is something I don't really understand:)

    Anyway, if I would like to use the kernel version that has no artifacts with DVBSky S960 and TVH, running RPi3 and latest LE, which kernel should I use? And how to install that kernel?

    Thanks!


    See the links posted on page 5 by smp