Everyone with HBR (Atmos/DTS HD MA) passthrough dropout issues please give this build a try, it contains a potential fix for that:
LibreELEC-RPi4.arm-9.80-devel-20201230165554-57eee27.tar
Feedback is highly welcome ![]()
so long,
Hias
Everyone with HBR (Atmos/DTS HD MA) passthrough dropout issues please give this build a try, it contains a potential fix for that:
LibreELEC-RPi4.arm-9.80-devel-20201230165554-57eee27.tar
Feedback is highly welcome ![]()
so long,
Hias
spooker thanks for the heads up, I had a look at the log but unfortunately nothing was logged in the ~30sec where you played the video (which isn't your fault but makes it tricky to find out what's going wrong).
Can you try disabling hardware acceleration in settings->player->video (you may need to change settings level to expert to see this option) and test if audio is played fine?
I have seen audio drop-outs with passthrough in the past when using H264 hardware decoding, but last time I checked was before the recent H264 seek changes. Still it would be good to know if audio with software decode instead of hardware decode is fine.
Edit: ah, and it would be great if you could reproduce the issue with some publicly available sample (and post a link) or upload a short sample file so we can try to reproduce it locally.
so long,
Hias
Firmwares and kernel are up to date in nightly images, the problem is that the bluetooth part in LibreELEC settings is currently broken - this afects all platforms, also x86 etc. No ETA for a fix, it's being looked into.
BTW: The Pi 400 isn't a "RPi4 in a keyboard", it's a bit different in several details - for example it uses a different WIFI/BT chip (which is why you won't get WIFI/BT in LE9.2).
so long,
Hias
The dwc2 driver isn't included in LibreELEC, but with LibreELEC 10 you'll be able to use otg_mode=1 - this is already working in development builds, see here [BUG] Missing configuration parameter for DWC2 at RPI4 · Issue #4722 · LibreELEC/LibreELEC.tv · GitHub
so long,
Hias
RPi4/400 video driver currently supports 1920x1080 max, support for higher resolutions isn't fully implemented yet.
The pixel-wrap is a known issue in the video driver, see here vc4-kms-v3d-pi4 offscreen quad leaks to the left side of the screen buffer · Issue #3667 · raspberrypi/linux · GitHub and here [BUG] Final output image overflows by 1 pixel to the right, pixels wrap around to the left of the screen · Issue #4779 · LibreELEC/LibreELEC.tv · GitHub
ATM we're waiting for fixes for these issues, when they are included in the RPi kernel/video driver we'll add them to LE as well.
so long,
Hias
Please try the latest nighly image and add otg_mode=1 to config.txt instead of the dwc2 dtoverlay. This will give you an XHCI controller instead of the limited dwc2 controller and it's also what recent USB boot is using for the OTG port.
so long,
Hias
RPi 400 uses a different wifi/bt chip which isn't supported in LE 9.2.6. It will be supported in LE 10 (current nightly builds already work).
See also here RE: LibreELEC (Leia) 9.2.5
so long,
Hias
Live TV and especially tvheadend is a different can of worms, better keep discussion about that confined to separate threads, otherwise the worms will creep everywhere ![]()
I can't really comment on Live TV issues as I'm very rarely using it.
The seeking issues I mentioned only affect H264 decoding with HW acceleration (which was previously disabled on RPi4). I didn't have any issues with H265 HW decoding and also am not aware of any issues in that area.
so long,
Hias
Yes, master is still limited to HD. 4k will come later, it's currently not supported in the RPi video driver.
so long,
Hias
Short update:
Kernel 5.10.1 update and a first version to fix seeking with H264 (and MPEG2/4 on RPi2/3) hardware decoding were merged into master yesterday and are now in nightly builds.
CEC on RPi2/3 should work again and H264 hardware decoding is now enabled by default on RPi4.
H264 seeking isn't perfect yet, sometimes it jumps to the beginning of the file (this is being investigated). You may also notice a bunch of ERROR lines in kodi log when seeking, these were (temporarily) added to make debugging seek issues easier - just ignore these if seeking works fine for you.
Video occasionally cutting out on RPi2/3 is still an issue, this is also being looked into.
so long,
Hias
The easiest thing would be to connect the tuner via an externally powered USB hub.
I can't comment on your specific tuner, would guess though that when using the official power supply it should work fine, if it's the only thing you connected to the USB ports (RPis have limit on overall power draw on USB ports).
From my personal experience with a Xbox USB tuner I can say it works fine, but if I also connect a bus-powered HDD it fails miserably - total USB power consumption is too large and that makes the tuner completely drop off the USB bus (USB disconnect messages in dmesg).
so long,
Hias
At this point I'm ready to buy another tuner that's known to work on the PI4 with Libreelec. Are there any tuners out there, single is fine if need be, that absolutely work out of the box with the current version on the Pi4?
If single tuner DVB-T/T2 is fine then have a look at the RPi TV Hat Buy a Raspberry Pi TV HAT – Raspberry Pi
so long,
Hias
See Post #3 in this thread. This feature is included in our latest nightly builds here Index of /, , please use these instead.
so long,
Hias
The changes will be added to master branch (and in nightly builds) when they are ready.
so long,
Hias
I had described the IR and kodi remote processing in the wiki, but it seems this has now been removed with the switch to the new wiki...
Here's the archive of the old wiki page Infrared Remotes [LibreELEC.wiki] , the introduction should contain the info you need - also read through the linked kodi wiki pages for more detais.
so long,
Hias
No, although the device has "LIRC" in it's name it has nothing to do with lirc or the other infrared remotes - it presents itself to the system as a keyboard.
Enable debug logging in kodi, push the button and then post the kodi debug log - this will show which key kodi received and give more hints.
so long,
Hias
I don't have a Harmony remote but AFAIK the selected remote profile is what defines the scancodes to be sent - so dig into that.
My guess is the remote profile sends two different scancodes on left/right to support two (slightly) different DVD players - which might work with the original players but is highly non-standard with anything else.
Check if there are other similar remote profiles if you want to stick to the Pioneer DVD profile or just configure the Harmony to use the Microsoft Media Center remote (not the MCE keyboard!), this will work out-of-the box in LE.
If you plan to use both your original pioneer remote and the Harmony to control LibreELEC you can still do this when the Harmony is configured as MCE: Enable both nec and rc-6 protocols in the keymap and add the key/scancode definitions from rc6_mce to your keymap (we do a similar thing in the default libreelec_multi keymap to support Xbox remotes in addition to MCE).
so long,
Hias