Posts by chewitt

nasawyer7 not sure what hardware you are using, but if RPi5, this image contains the patch mglae suggested:

https://chewitt.libreelec.tv/testing/LibreELEC-RPi5.aarch64-12.80.0.tar

If not RPi5, tell us and I'll create something to test.

Quote from strittlu

Are there some requirements to the SD card im not aware oft?

Nope. Does the problem persist with other cards? Can you imge/boot RaspiOS from the problem card?

popcornmix has a draft fix for this issue, see: https://github.com/raspberrypi/linux/pull/6218

This update uses 16K pages and includes the patch: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.0.tar

Please test and report back.

HDR/HDR10/HLG is already supported in LE and Kodi subject to the hardware supporting them; which is complicated on NUC type devices with LSPCON chips as those can modify the capabilities of the "HDMI" output path and prevent a universal/simple answer to what's supported. There are also bugs in Intel drivers that muddy the waters.

DV is already supported in Kodi (on Android with appropriately licensed hardware). However on Linux you will also need licensed hardware (so handling exists in silicon) and FFMpeg support. The latter appears to be progressing, but it will be a while before all pieces are version aligned. Kodi 'P' is about to bump from FFMpeg 6.0 to 7.0 and those patches are merged to FFMpeg master so should be in FFMpeg 8.x (or something post v7.0 at least) and there's likely to be more patching needed.

And for purists: There will never be an open-source implementation of DV to Dolby standards because the tooling and technical info needed for that require sign-up to their license regime (which is the polar opposite of open-source). So open-source DV support will always be limited to making something that looks nice on screen.

garbear?

Thanks for confirming. It will go into LE12 nightlies and 12.0.1: https://github.com/LibreELEC/LibreELEC.tv/pull/8975

LE builds ffmpeg for Kodi "externally" i.e. we roll our own instead of allowing Kodi to build it. We do not explicitly enable "--enable-demuxer=dash" in the config as per the ffmpegdirect recipe, but we set "--enable-demuxers" which should be the superset of all demuxers. See https://github.com/LibreELEC/Libr…package.mk#L201

This is the list of demuxers from current LE (taken from the compile log): https://pastebin.com/raw/b0LuUrec

This is the list with "--enable-demuxer=dash" set: https://pastebin.com/raw/a9cQstDw

If you diff the output, they are identical.

nasawyer7 what hardware are you trying to use this on? .. and did you configure the Tidal add-on with "supports dash"?

I have loads of these: https://www.amazon.de/-/en/UART-TTL-…/dp/B0B7RHPMT7/ but they are mostly all the same.

The UART pinout is here: https://wiki.odroid.com/odroid-c2/application_note/gpio/uart. Note that you only need to connect GND, TX, and RX. Black is always ground. TX/RX are varied and it's harmless to mix them up and swap them. Avoid the 5V pin on both ends as it's not required and it's easy to damage things.

garbear .. any clues?

echo 'modetest -M vc4 -w "32:Broadcast RGB:1"' > /storage/.config/autostart.sh
reboot

^ this will be persistent

Option #1 is to change the source URL that we download from in the package.mk.

Option #2 is to manually download and place in your sources folder, then create the filename.sha256 checksum and filename.url for the package and the buildsystem will process them as if it had downloaded them.

Option #3 is to ask nicely and someone on staff can usually upload it to our mirror (which I've done now).

Quote from ilovebytes

is there anything i could investigate on my side maybe to help you find a working solution ?

Connect a UART cable to the pins on the board and boot, and when it fails .. wait until it drops to the initramfs shell and copy/paste the log to pastebin, then share the URL so we can see what/how things went wrong.

git remote add chewitt https://github.com/chewitt/LibreELEC.tv.git
git fetch chewitt dvb-fix
git checkout -b dvb-fix
git reset --hard chewitt/dvb-fix
PROJECT=RPi DEVICE=RPi4 ARCH=aarch64 make release

I pushed the required kernel change to https://github.com/chewitt/LibreELEC.tv/commits/dvb-fix so the above ^ commands will fetch the commits from the dvb-fix branch in my repo, checkout a new branch, reset the state of that branch to match my dvb-fix branch, and then build an LE12 nightly image.

If you can confirm it's fixed with that patch I'll push the change to LE12/master branches.

Quote from Reddog

I first tried getedid create with the full train (RPi5 -> AVR -> Samsung 4K TV) without success.

Finally tried a direct RPi5 to TV - this worked

If you can share the EDID files from AVR+TV and TV-direct I'll ask the Pi devs to have a closer look. The intermediate one (RPi + AVR only) is expected to not work since there's no TV to pass EDID from so it'll be incomplete.

Quote from BallerShotCaller

What does that mean? That my Pi5 did fell off a truck?

It means Pi trading are a little behind on documentation, nothing more.

I'd suggest to experiment with creating connections using 'bluetoothctl' over the SSH console. This bypasses our settings add-on completely so if connections work from there, we know it's something in our add-on. If they don't work, then it's something lower level with the BT stack in the OS.

NB: Without the workaround in https://github.com/LibreELEC/LibreELEC.tv/pull/8970 Kodi makes a large number of connections to the MariaDB server (making repeated connections trying to connect) and this may cause MariaDB to stop responding. Even if you update to an LE image with the workaround included, MariaDB may need to be restarted before it will accept connections again.

I've asked one of the ffmpegdirect maintainers if he can decipher the request; because the Tidal2 repo you've linked to only shows how to compile the add-on. It contains no mention of what technical change is required somewhere.