You can always install EXT4 driver on Windows laptop.
Posts by adam.h.
-
-
Is force mounting going to fix errors from LE?
It won't fix anything, just mount it regardless these errors. The other (maybe better) option is to fix the disk in Windows system and change LE to mount it always as RO (the above url to autostart is good reference for details).
BTW, the option to mount external contents disks as RO could be good extension for LE, but perhaps it happens so rarely that it is not worth the effort. I'm using RPi5 with latest LE12 and SSD disk formatted as NTFS and while I had that "dirty disc" errors in the past (probably around LE10 or LE9), it works now without problems. So this could be also some combination of disc type, NTFS and LE version (driver version).
-
-
Oh sure, just be patient enough and all the problems will magically solve themselves! 😀
With the following nightly LE release I can play above stream without problems:
Code
Display MoreStarting Kodi (22.0-ALPHA1 (21.90.700) Git:db813bfaec3b3bd510e084158fec3ad7be7557a2). Platform: Linux x86 64-bit Using Release Kodi x64 Kodi compiled 2024-10-02 by GCC 14.2.0 for Linux x86 64-bit version 6.11.0 (396032) Running on LibreELEC (community): nightly-20241002-a95d055 13.0, kernel: Linux x86 64-bit version 6.11.0 FFmpeg version/source: 6.0.1 Host CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz, 8 cores available CAddonMgr::FindAddons: inputstream.adaptive v22.1.4.1 installed CAddonMgr::FindAddons: inputstream.ffmpegdirect v22.0.1.1 installed CAddonMgr::FindAddons: inputstream.rtmp v22.0.0.1 installed CAddonMgr::FindAddons: kodi.binary.instance.inputstream v3.3.0 installed SECTION:LoadDLL(/storage/.kodi/addons/inputstream.adaptive/inputstream.adaptive.so.22.1.5) CAddonMgr::FindAddons: repository.slyguy v0.0.9 installed CAddonMgr::FindAddons: script.module.slyguy v0.85.23 installed CAddonMgr::FindAddons: slyguy.dependencies v0.0.22 installed CAddonMgr::FindAddons: slyguy.disney.plus v0.17.3 installed
However someone with fresh eye catched up that it originally failed on HEVC stream and now it is openning H264 stream, so perhaps Kodi in this version has different preferences - not sure if H264 stream was available originally or was added later by Disney...
-
I'm just pointing out that it would be more useful to keep in sync releases with changelog info, but perhaps this is just me trying to make some sense out of it.
-
I'm not asking for more work from developers, just as in the attached example - if we show URLs to around 70 nightly releases, why not make Changelog table also showing 70 pull requests instead of last 18 like currently? I suppose this is some simple update to script rendering these pages?
-
Guys, could you make the changelog table a bit longer to cover all available nightly builds? For example, in Generic LE13, I have builds from May to September, but the changelog only shows releases from mid-July.
I discovered that LE13 01416e0 is not handling subtitles properly, so I had to downgrade to a randomly chosen build from July 20, as the latest changelog entry only shows releases from July 25.
I know I could spend time looking directly on GitHub, but why not make these pages a little more useful?
-
After quick discussion with addon creator and ISA maintainers finally I opened Kodi ticket for this...
-
Some more forensic analysis
Here are the stream properties:Code
Display MoreGeneral Complete name : Machine Gun Kelly’s Life in Pink.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/dby1/iso2/mp41) File size : 2.29 GiB Duration : 1 h 41 min Overall bit rate mode : Variable Overall bit rate : 3 219 kb/s Frame rate : 23.976 FPS Movie name : Machine Gun Kelly’s Life in Pink Description : 'Machine Gun Kelly’s Life in Pink' Recorded date : 2022 Writing application : Lavf60.3.100 Cover : Yes Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main [email protected]@Main Codec ID : hvc1 Codec ID/Info : High Efficiency Video Coding Duration : 1 h 41 min Bit rate : 2 958 kb/s Width : 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.134 Stream size : 2.10 GiB (92%) Title : BAMTech video Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Codec configuration box : hvcC Audio ID : 3 Format : E-AC-3 Format/Info : Enhanced AC-3 Commercial name : Dolby Digital Plus Codec ID : ec-3 Duration : 1 h 41 min Bit rate mode : Constant Bit rate : 256 kb/s Channel(s) : 6 channels Channel layout : L R C LFE Ls Rs Sampling rate : 48.0 kHz Frame rate : 31.250 FPS (1536 SPF) Compression mode : Lossy Stream size : 186 MiB (8%) Title : BAMTech audio / English Language : English Service kind : Complete Main Default : Yes Alternate group : 1 Dialog Normalization : -29 dB compr : -0.28 dB mixlevel : 105 dB roomtyp : Small dialnorm_Average : -29 dB dialnorm_Minimum : -29 dB dialnorm_Maximum : -29 dB
Suprisingly it plays well from the file, even with enabled vaapi, and the same content fails with vaapi when it is streamed. See attached 2 screenshots from playing file and playing the stream.
So perhaps the problem is not really in ffmpeg or drivers/kernel, but somewhere between InputStream Adaptive / Disney+ Addon / FFMpeg?
EDIT: I forgot to add log file.
-
Ok, so to complete this journey here is the log with Linux version 6.10.0-rc3 and FFmpeg version 6.1.1, the stream is not playable when hardware acceleration is enabled.
Let me know if you think I can contribute with anything else.
-
I'm using that setup: <setting id="debug.setextraloglevel">128,2048,32768,262144</setting> so ffmpeg is covered. I didn't try with ffmpeg 6.1.1 though.
I tried that sample file attached to 23699 and it works fine for both software codec and hardware acceleration, see the log. As expected, with vaapi enabled it plays very smoothly, while it slightly stutters with software codec.
So I suppose it is something else im my stream which causes these issues.
-
Hi chewitt, I checked that all these HEVC samples work well with and without hardware acceleration, so it seems that there is something specific with my tested HEVC stream.
I could provide like 10 sec sample of that failing HEVC stream for further investigations, but since simple hacks with playercorefactory/ffmpeg are not working with the new Kodi and this is prioprietary Disney contents I suppose I would need some guidance (PM?) how to proceed with this.
-
Thanks for the pointers. I compiled PR for 6.10-rc3 but the latest kernel didn't change anything.
In case you want to look int the log file, first part shows software codec (it works), second part shows hardware support enabled (it breaks).
-
Hi chewitt, I don't think this is LE issue (perhaps more the problem in the NUC BIOS), but if you want to see the log, here it is.
-
Maybe this was discussed already here, but I cannot find anything specific. Perhaps my adventures will help someone.
In theory NUC10 should be fine with HEVC (hardware decoding is available in 10th gen.). But not in my case, the HEVC movie was just generating sound and video screen was not refreshing. I could see multiple entries in the log file, like: ffmpeg[0x1c3b8a30]: [hevc] hardware accelerator failed to decode picture.
So it helped to disable hardware acceleration in the Player settings. Apparently hardware driver was not as good as the software driver. Attaching also screenshot for the reference.
-
Thanks chewitt, just verified that the fix works on x86 as well.
-
Can someone please trigger nightly build for x86 as well?
btw. I always had impression that nightlies are triggered via some automation if at least one PR is merged during a day? But it seems that they are triggered somehow randomly, otherwise we should see 5 builds during June 11-15 and this would be consistent for all device types:
Code
Display MoreChangelogs: 2024-06-11 (cb6b341): #8978 kernel-firmware: update to 20240610 2024-06-11 (e762f58): #8979 alsa update to 1.2.12 2024-06-12 (1a71ae6): #8976 Migrate to upstream 6.11 RTL8192DU 2024-06-13 (5301016): #8983 package updates 2024-06-13 (79d4d33): #8982 systemd: update to 256 2024-06-13 (18becd8): #8984 linux (RPi): update to 6.6.33 2024-06-14 (2216317): #8988 iwlwifi-firmware: update to githash 1303bad 2024-06-14 (12989ea): #8989 rust: update to 1.79.0 2024-06-15 (09e42f7): #8991 vulkan: update to 1.3.288 2024-06-15 (59be5f5): #8990 eventlircd: bump to fix assert issue with systemd udev RPi4 Builds: LibreELEC-RPi4.aarch64-13.0-nightly-20240611-dcca4e3.img.gz (sha256) 2024-06-11 09:35 146.8M LibreELEC-RPi4.aarch64-13.0-nightly-20240613-1a71ae6.img.gz (sha256) 2024-06-13 10:40 146.7M LibreELEC-RPi4.aarch64-13.0-nightly-20240614-18becd8.img.gz (sha256) 2024-06-14 07:50 146.8M LibreELEC-RPi4.aarch64-13.0-nightly-20240615-59be5f5.img.gz (sha256) 2024-06-15 17:02 146.8M Generic Builds: LibreELEC-Generic.x86_64-13.0-nightly-20240612-1a71ae6.img.gz (sha256) 2024-06-13 03:46 254.1M LibreELEC-Generic.x86_64-13.0-nightly-20240613-18becd8.img.gz (sha256) 2024-06-13 22:55 254.3M
-
nightly-20240613-18becd8 - remote is not working with this one (no reaction to any button)
nightly-20240612-1a71ae6 - remote is back to normal
Perhaps this is the reason:
CodeJun 15 00:10:24.294870 NUC-ELEC eventlircd[541]: Assertion 'udev_device && key' failed at src/libudev/libudev-device.c:194, function udev_device_get_property_value(). Aborting. Jun 15 00:10:24.329341 NUC-ELEC systemd[1]: eventlircd.service: Main process exited, code=dumped, status=6/ABRT Jun 15 00:10:24.329360 NUC-ELEC systemd[1]: eventlircd.service: Failed with result 'core-dump'.