We have to see if we can find some of this affected devices to bisect the commit that break it, everything I have access to works "unfortunately".
Hi CvH,
Let me know how can I be useful to help here if I can , what is the needed know-how? I never compiled a kernel before, but I think it is not rocket_sc_nce 
I am interested to get me device working
Setup / available resources.
RPI 2 / 3 with Hauppauge Solo HD, DVBc German TV
Windows 10, Mac OSX, Mint as OS.
badway
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.
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.
However, I am able to easily reproduce the issue on my x86_64 machine.
which DVB HW ?
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
Not sure if you want to pick this back up.
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)
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.
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.
^ 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
^ 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)
You are vastly over-estimating the number of tests needed in a bisect.
50 builds would allow for identifying a single commit in ~1000000000000000 commits (2^50).
Around 9 builds are actually needed for bisecting the ~343 commits in the "Here is the big USB, and PHY, and extcon, patchsets for 4.9-rc1" merge that is believed to contain the regression.
the numbers were just guessed, btw there are 13000 commits between - ofc much less PRs
as soon I get my hands at some affected hw I bisect it - currently still searching for someone who has such hw to avoid buying one.
Hi there,
currently Im running opensuse 42.3 and am willing to bisect the kernel. I have the adapter (
NXP TDA10071) PCTV Systems PCTV 460e.
at the moment im running a self compiled Kernel 4.9.40-rt30-19-default. I compiled tvheadend and tryed running a mux detection and programmviewing without any problems.
Could someone tell be wich is the kernelversion the problems began with ?
Could someone tell be wich is the kernelversion the problems began with ?
the problem is somewhere between
GitHub - torvalds/linux at 6b5e09a748ad0a0b198d0e268c7e689044bfe48a and GitHub - torvalds/linux at 2937f375751922ffce9ef1d5fa84491840b0c8e0
well I dont know how to bisect between trees - only between kernelversions - can you help ?
well I dont know how to bisect between trees
you need to build your own kernel and test it, the change is somewhere at 4.9rc1-4.9.rc2
o.k. I startet now with an stabel Kernel Version: 4.9.47-19-default -- the problem is with this kernel on my OpenSuse System (42.3) I dont have any Problems with continuity counter errors - not a zero one.
OS: Open Suse Leap 42.3.20170731
Kernel: 4.9.47-19-default (cleanly compiled 20 minutes ago)
tvheadend: 4.2.1
Kodi: 17.3 Git:20170524-147cec4
Since I dont have the problems on my compiling machine I can`t bisect the vanilla Kernel.
CvH thank you for versionnumbers
o.k. found something strange ... I looked at the firmwarefiles of libreelec and the firmwarefiles that I downloaded onto my compiling machine.
The strange thing - I thought this are binary files so the filesizes have to be equal ?
... to go on I copied over the firmwarefiles of libreelec to my system and now I also get continuity counter errors on my compiling machine - changing the files back reverts the Problems!
working version: size 40504 dvb-fe-tda10071.fw
failing version: size 43558 dvb-fe-tda10071.fw
Can anyone compile an actual libreelec including the firmware from: Pinnacle PCTV DVB-S2 Stick (460e) - LinuxTVWiki
Can anyone compile an actual libreelec including the firmware from:
just place the fw here how_to:add_firmware [LibreELEC]
and reboot
thats a bit silly but if it works I pr the change asap
