If you need an older version though, I think Archive.org / waybackmachine has them. I just downloaded a 2020 version from them to test.
Posts by Rataplan626
-
-
For this particular clip, indeed on my setup it's the same and enabling prime deinterlacing doesn't crash. I think I've had occurrences where having deinterlace enabled also crashed, as I think I had all accelerations enabled.
For what it's worth, enabling prime, but keeping acceleration and deinterlace off works too.
When I enable acceleration and play the clip and forward 10 seconds right at the start, it's not crashing either. Only when I play the full clip it crashes.
Maybe related, I still have a lot of DVD's which I ripped to ISO and placed on my NAS, mostly Disney animations. With prime enabled DVD's regularly don't 'start', the wait-circle keeps spinning. Usually I can press stop, get back to kodi, start again and then it works. With prime disabled I never have that issue. Maybe it's related.
-
Hi, continuation of RE: [RPi4] Instabilities With Prime Decoder, which was locked down as it turned out I had a banned repository installed. Fair enough. I didn't even know, I hadn't even any addons installed from it, but again, fair enough. I've removed it, and made sure non of my plugins / addons are banned (as I don't want that either), but it obviously doesn't change the issue I have.
In short, some files, especially PVR recordings with I think bad signal / bit errors, make kodi crash and restart when PRIME decoder is enabled. When it's disabled, it continues. I managed to make a short recording. With PRIME enabled it crashes at about 15/16 seconds, with PRIME disabled it works fine.
Logs: https://paste.libreelec.tv/top-rattler.log
Recording: https://1drv.ms/v/s%21As_wCUgs-pjPhEQVPqyKXA68sGvv?e=XUN7Ps[edit]
The first log might not have had the error in it, as after the kodi restarts the logs were disabled again, and hence maybe reset? I've now enabled logging, rebooted (so it sticks), played the file again, and after the Kodi crash I took another pastkodi. This time also the generated logfile name is better
-
I was lucky, got it to crash first try. The recording makes my Pi4 crash every single time I play it with PRIME enabled. With disabled it runs fine. It crashes right at the end of this 16 second clip. I just started recording and stopped recording, this is the file that came out.
Logs captured: https://paste.libreelec.tv/ultimate-spaniel.log
Actual video file at https://1drv.ms/v/s%21As_wCUgs-pjPhEQVPqyKXA68sGvv?e=XUN7PsNot sure if the kodi-restart interferes with the logging.
-
Hi, I'm using 12.0 on a Pi4, nightly-20241112-a5ae7e7 currently to be exact. I have an USB Anysee DVB-C decoder connected, which I use with TVHeadend, both server and client run on the Pi. I've used this setup for years now, first on a Odroid-C2, and since a year or 2 on a Pi4. The last half year or so I have random crashes of Kodi. So thinking back, I think it's sice LE12. I think it's related to us having a bad cable signal from time to time. So sometimes I have artifacts when viewing live TV. I'm using high quality Hirschmann coax cables, as short as possible, with only the Pi4 and my cablemodem for internet connected. But we live a bit outskirts, so there's long cables outside to the first node. Nothing I can do about that.
What happens, sometimes I get these artifacts, most people will recognise it, bad MPEG artifacts. Sometimes it will recover, but sometimes Kodi will hang for a few seconds, crash and restart. When that happens, only Kodi restarts, but the Pi itself does not reboot. So LE keeps running. Whenever Kodi restarted, after that it's usually unstable as hell crashing when I try to play a DVD, H264 or H265. Not always but most of the times. When it doesn't work there's two scenarios; the screen dims and the 'wait' circle is turning, and just keeps turning but nothing happens. Then using stop / back buttons I sometimes can get back to the menu and try again.
The other option is that Kodi starts playing the video for a few seconds, crash out and restarts again.The only way I can recover from this loop, is to properly reboot LE, ie from the power menu or by unplugging power for a bit in case it really hung. After that's it's all fine again, I can play all videos, DVD's just fine.
I fiddled around, and found that disabling PRIME decoder makes things work again too, even without a reboot. Ie, when Kodi crashed out and restarted, which would then be somewhat reproducible, and I disable PRIME, I can watch anything again.
I ran into this a lot lately, as I was asked to record a certain series from TV daily. It happens to be on a channel which resides on a mux which typically has the worst signal. This is why I think the bad PVR signal is triggering this. So I guess recording a bad signal makes it go bad as well. When I disable PRIME though, I have no issues at all, except for the Pi4 not being fast enough to decode everything, so I have stuttering then.
So I have a few questions:
- Is PRIME even involved when recording DVB-C?
- How can PRIME put the Pi4 (or the decoding) put in this state that needs a reboot? Isn't PRIME initialised at the start of every playback?
- What logs would be needed? Capturing a log of it crashing during playback I can manage, but capturing the moment that triggers the issue might be hard as it can take days before it happens.
- If I have a recording that triggers the crash on my side, I assume I should share that file? -
Yes now it compiles and the Anysee tuner works! Thank you all so much, and chewitt in particular! And I learned so much, I might be able to figure it out myself the next time
-
I can't get it to build, during the build it can't find that specific version of fakeroot:
--2024-06-10 17:29:26-- http://sources.libreelec.tv/mirror/fakeroo…oot-1.34.tar.gz
Resolving sources.libreelec.tv (sources.libreelec.tv)... 65.109.172.87
Connecting to sources.libreelec.tv (sources.libreelec.tv)|65.109.172.87|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-06-10 17:29:26 ERROR 404: Not Found.Doesn't matter if I take 12.0.0 or the latest nightly.
I'm currently finding out how I can add sources to the building mechanism, as I found multiple repositories with that version in.
-
I was just typing a reply when your last update popped up. Weird how I came up with another patch that borked it twice. Still, for the time being, how would I build the kernel for now without the borked patch, or with yout update? I can find my way in Linux, but I'm not into kernel building apart from al the builds I made during this bisecting. By the way, on my laptop the initial LE build took like 45 minutes, but with the changed kernel only a few minutes.
-
I did it on the real hardware but a vm could work I guess. It didn't even take as much time as I expected, but yes it's a bit of a hassle. I did it twice and came on the same patch both times. I wonder if you end up on the same erroneous patch.
-
Anyone? How could I continue from here reporting this bug in the kernel? Would it make sense to try a linux box with a newer kernel and see if it works again? Would I be right to assume if that would work, at some point it would work in LE again when they incorporate newer kernels as well?
-
Sorry for the late reply, life hit me hard the last couple of weeks. Getting everything back on track now. This weekend I updated to LE12 on a test SD-card, and it still doesn't work. My build-vm is still on 11 though.
git seems to report that patch is present:
Code
Display Moregit show 5d0fe30be4e28abe373bf951416f29afb0651e01 commit 5d0fe30be4e28abe373bf951416f29afb0651e01 (refs/bisect/bad) Author: Christoph Hellwig <[email protected]> Date: Tue Aug 1 19:35:44 2023 +0200 modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules commit 9011e49d54dcc7653ebb8a1e05b5badb5ecfa9f9 upstream. It has recently come to my attention that nvidia is circumventing the protection added in 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary modules into an allegedly GPL licensed module and then rexporting them. Given that symbol_get was only ever intended for tightly cooperating modules using very internal symbols it is logical to restrict it to being used on EXPORT_SYMBOL_GPL and prevent nvidia from costly DMCA Circumvention of Access Controls law suites. All symbols except for four used through symbol_get were already exported as EXPORT_SYMBOL_GPL, and the remaining four ones were switched over in the preparation patches. Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> diff --git a/kernel/module/main.c b/kernel/module/main.c index 7a6f43d2b775..7a376e26de85 100644 --- a/kernel/module/main.cand some more after that.
So that patch seems to be incorporated.
-
Sounds good. So when Raspbian incorporates that into their builds, it will one day 'automatically' end up in LE? Is that how things work? Now I have this build system up and running, can I build an 11.0.6 with this patch incorporated?
-
I'm really sorry for my compile noobness, but how do I check?
-
This is what came out:
Code
Display More5d0fe30be4e28abe373bf951416f29afb0651e01 is the first bad commit commit 5d0fe30be4e28abe373bf951416f29afb0651e01 Author: Christoph Hellwig <[email protected]> Date: Tue Aug 1 19:35:44 2023 +0200 modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules commit 9011e49d54dcc7653ebb8a1e05b5badb5ecfa9f9 upstream. It has recently come to my attention that nvidia is circumventing the protection added in 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") by importing exports from their proprietary modules into an allegedly GPL licensed module and then rexporting them. Given that symbol_get was only ever intended for tightly cooperating modules using very internal symbols it is logical to restrict it to being used on EXPORT_SYMBOL_GPL and prevent nvidia from costly DMCA Circumvention of Access Controls law suites. All symbols except for four used through symbol_get were already exported as EXPORT_SYMBOL_GPL, and the remaining four ones were switched over in the preparation patches. Fixes: 262e6ae7081d ("modules: inherit TAINT_PROPRIETARY_MODULE") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> kernel/module/main.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)It talks about NVidia, which doesn't have much to do with this I suppose, but it seemingly affects these TV tuners in TVHeadend.
So... now what
-
I got it to build. I'll try to find the breaking commit and report.
-
Had some time to fiddle with it again, but I can't get it to work. In my last try I checked out 11.0.3, build that, which builds and works fine (as expected). When I change packages/linux/package.mk to reflect the suggested commit, it fails again with the same overlay_map.dtb error.
If anyone has a clue hoe to get the kernel to build properly, that's be awesome.
-
*sigh* these are the moments I was afraid of, feeling like a total noob. I checked out 11.0.6 which was the most recent at the time. First build an image, went fine. Then I modified package.mk to reflect the bisect suggested commit. Build again and then:
[QA CHECK] [linux] [safe_remove]:
path does not exist: /home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/install_pkg/linux-2368afd60f647889d90fa4a42c7b27548f77dbd9/usr/share/bootloader/overlay_map.dtb
cp: cannot stat 'arch/arm64/boot/dts/overlays/README': No such file or directory
FAILURE: scripts/build linux:target during makeinstall_target (package.mk)
*********** FAILED COMMAND ***********
cp -p arch/${TARGET_KERNEL_ARCH}/boot/dts/overlays/README ${INSTALL}/usr/share/bootloader/overlays
**************************************
*********** FAILED COMMAND ***********
${SCRIPTS}/build "${1}" "${PARENT_PKG}"
**************************************
FAILURE: scripts/install linux:target has failed!The following log for this failure is available:
/home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/.threads/logs/142.log>>> linux:target seq 142 >>>
[273/280] [FAIL] install linux:targetThe following log for this failure is available:
/home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/.threads/logs/142.logLog attached. I've been looking for a bit to get that fixed. I checked https://github.com/raspberrypi/linux/issues/5272 but so far no sigar.
-
That figures. To learn for the future, could I have known that? I've looked into the 'how to build LibreElec' tutorial, but that didn't help.