Posts by HiassofT

Sleep (suspend/resume) isn't supported. From what I've read the hardware should be capable to support that so it might get added in the future (but OFC not promises if/when that might happen).

so long,

Hias

RPi5 has one, you just need to buy the (rechargeable) battery for a few bucks.

so long,

Hias

Quote from peno64

I installed LibreELEC-RPi5.arm-11.0-nightly-20231104-300a514 on my new PI 5 with active cooling the fan is connected on the official fan connector.

I note that it seems to turn on at already 49°C and turns off at 46°C

It seems the documentation is wrong, the kernel / device tree trip points match your observations - first trip point is at 50°C with a hysteresis of 5°C (i.e. turn on at 50°C and off at 45°C)

linux/arch/arm/boot/dts/bcm2712-rpi-5-b.dts at rpi-6.1.y · raspberrypi/linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at…

github.com

From a quick glance the trip points can't be configured yet, but this should be doable with some future dtparams or a dtoverlay.

Best ask on the RPi forums about that https://forums.raspberrypi.com/ or open an issue on the RPi kernel github issue page https://github.com/raspberrypi/linux/issues

so long,

Hias

ffmpeg 6.1 added support for the vulkan video decode api which is a different thing than vulkan graphics/3D support (RPis only come with the latter) - so AV1 decoding will still need to be handled by dav1d.

so long,

Hias

yes

so long,

Hias

I'm currently looking into a different approach: let users choose to mount NTFS partitions read-only https://github.com/LibreELEC/LibreELEC.tv/pull/8308 - this would hopefully solve the issue of easy corruption in case of unclean shutdowns.

so long,

Hias

Don't get too excited about ntfsfix, I did a quick test on a corrupted NTFS filesystem, removing the dirty bit, and as expected it didn't help with the errors and the ntfsdriver set the dirty bit again after mounting it because the filesystem had issues.

so long,

Hias

On LE11 this is expected, RPi3 doesn't have enough grunt to decode it. LE 9.2.x and earlier contained optimized HEVC decoder code which was dropped in LE10 as it doesn't work with the new graphics stack (and, no, it won't come back).

TLDR: use LE 9.2.8 on RPi3 if you want to playback HEVC files (or just use H264 files, they work with all LE versions).

so long,

Hias

I don't use the HD Austria addon myself (don't have a subscription for that) but I strongly suspect it's an issue with that specific addon, so best to report it on it's issue tracker.

You can safely ignore the inputstreamhelper messages in the log (they are false-positives, the checks it does don't work on LE) and the inputstream messages may be a result of issues of the HD Austria addon.

We have an inputstream.adaptive update to 20.3.14 in the queue (new addon should be build and available in the next days), you could wait for that and retest once you got the update but the changelog doesn't look like it might help (it seems to fix subtitle stream issues).

It could be due to some bug in inputstream.adaptive but only the HD Austria addon devs are able to narrow it down as we're not familiar with that addon - hence best report it to them and let them figure out what's wrong.

so long,

Hias

Quote from hundrakg

No time to test yet, but will try soon, but before I want to know is there HW support decoding H264 with Rpi3 and LE11 and 12?

yes

so long,

Hias

It's in the system-tools addon

so long,

Hias

If your portable hard drive is formatted with NTFS then hook it up to a windows PC and run chkdsk to fix the filesystem errors (older LE versions were more tolerant about them).

VC1 and MPEG2 hardware decoding are still supported on RPi0-3 if you have the license(s).

so long,

Hias

It's a tough choice.

Yes, RPi5 feels definitely snappier and has a lot more grunt but it also needs more power (esp. with H264 media which needs to be software decoded) so it will get hotter. We still have to see how that works out in practice with people putting the RPi5 in a case. I suspect the fan will kick in quite often.

Availability is another issue in the next couple of months, RPi4 is on stock everywhere but I don't expect the RPi5 to be broadly available until spring next year (eg mouser currently says the'll have about one thousand RPi5 4GB models - which is next to nothing - available end of January).

so long,

Hias

Even the RPi3 can do this. Please test with a current LE version (LE11 or LE12 nightly) on a separate SD card.

RPi0-3 have a hardware limitation so that 192kHz 7.1ch PCM output and TrueHD/DTS-HD passthrough can't work but 96kHz is supported.

Other than that of course your AVR must support 96kHz audio and there are some limitations on software decoding audio (eg the object based audio formats like Atmos are not supported).

so long,

Hias

LE 9.2 on RPi4 was a stop gap, using 32bit kernel and a franken-kodi which cross-breeded the old MMAL codec with the new GBM graphics stack. No one should be using that today

The reason we went for that was simply because the old graphics stack didn't support RPi4 and the new v4l2 decoders weren't ready yet. So we had to find some interim hack (which we knew would be throw-away) to get some release out.

64bit kernel in LE10 and now finally 64bit userspace as well in LE12 were the incremental steps we had to do to keep everything going (64bit userspace was held up because there wasn't a 64bit widevine library - which some people need for DRM stuff - available until recently).

so long,

Hias

The DTS HD MA files I had here all were only 48kHz but with the lossless DTS-HD HRA kodi showed it was being output at 96kHz

2023-10-23 15:39:54.141 T:1005     info <general>: ffmpeg[0x2eb57130]: Input #0, matroska,webm, from 'smb://lebuild.lan/samples/thedigitaltheater/dts_sfx_short_lossless_1080p-thedigitaltheater.mkv':
2023-10-23 15:39:54.141 T:1005     info <general>: ffmpeg[0x2eb57130]:   Metadata:
2023-10-23 15:39:54.142 T:1005     info <general>: ffmpeg[0x2eb57130]:     encoder         : libebml v1.3.0 + libmatroska v1.4.1
2023-10-23 15:39:54.142 T:1005     info <general>: ffmpeg[0x2eb57130]:     creation_time   : 2015-04-06T12:06:20.000000Z
2023-10-23 15:39:54.142 T:1005     info <general>: ffmpeg[0x2eb57130]:   Duration: 00:00:16.25, start: 0.000000, bitrate: 12175 kb/s
2023-10-23 15:39:54.142 T:1005     info <general>: ffmpeg[0x2eb57130]:   Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn (default)
2023-10-23 15:39:54.142 T:1005     info <general>: ffmpeg[0x2eb57130]:   Stream #0:1(eng): Audio: dts (DTS-HD HRA), 96000 Hz, 7.1, fltp (default)
...
2023-10-23 15:39:54.743 T:875     debug <general>: CActiveAESink::OpenSink - ALSA Initialized:
2023-10-23 15:39:54.743 T:875     debug <general>:   Output Device : vc4-hdmi-0 (vc4hdmi0)
2023-10-23 15:39:54.743 T:875     debug <general>:   Sample Rate   : 96000
2023-10-23 15:39:54.743 T:875     debug <general>:   Sample Format : AE_FMT_S24NE3
2023-10-23 15:39:54.743 T:875     debug <general>:   Channel Count : 8
2023-10-23 15:39:54.743 T:875     debug <general>:   Channel Layout: FL, FR, LFE, FC, BL, BR, BC, UNKNOWN1
2023-10-23 15:39:54.743 T:875     debug <general>:   Frames        : 4800
2023-10-23 15:39:54.743 T:875     debug <general>:   Frame Size    : 24

Note that in general it's recommended to use passthrough. Use PCM output only if your AVR doesn't support the format, but note that software decoding and converesion to PCM is quite limited (eg none of the object formats will work).

so long,

Hias

Quick test on RPi5 with DTS HD HRA says yes, both decoding to PCM 7.1 and passthrough work fine (same goes for RPi4 BTW).

so long,

Hias

Quick heads up: I've just updated the rpi-tools addon and if builds go well it should be available from the repo in the next few days.

rpi-tools: update addon and build for aarch64 as well by HiassofT · Pull Request #8230 · LibreELEC/LibreELEC.tv

update gpiozero to 2.0 and switch from RPI.GPIO to the libgpiod-based lg-gpio, like RPiOS did in it's bookworm release Also drop the ancient adafruit libraries…

github.com

It updates gpiozero to the current 2.0 version and RPI.GPIO is now gone for good (being replaced by the libgpiod based lg-gpio), aligning with current RPiOS bookworm packages.

Any out-of-tree addons and scripts that are still using RPI.GPIO should switch to gpiozero, otherwise they won't work on LE12.

so long,

Hias