Posts by HiassofT

Meh, decoding seems to be fine again

Please try to catch output where you get a "key_up" event as suggested in my last post RE: [Intel] Nightly build...problem with mce remote

so long,

Hias

Hint: it might be better if you test with kodi and eventlircd stopped, then you'll also see the key events. If you see a "key_up" line in the middle of the output you'll know that things have failed - and ir-keytable/ir-ctl outputs should contain something useful for me.

so long,

Hias

Thanks again for testing. The stray signals could be harmless (and I also have no explanation why earlier builds would behave differently), but they looked a bit too frequent for my taste.

Unfortunately the scancode output is fine again... Could you test it again, this time press a button for 5 seconds (that'll give a higher chance we catch the issue).

so long,

Hias

Unfortunately there didn't seem to be any scancode decode errors in the nightly test. Could you repeat that one?

I've noticed though that the IR receiver seems to be picking up quite some noise (the "+100 timeout # ..." lines from ir-ctl -r). Noise / stray signals from fluorescent lights etc can also harm IR decoding. Please also try running "ir-ctl -r" (without output redirect) and check if covering the IR sensor, turning off lights, closing the curtain etc reduce the amount of those lines.

so long,

Hias

Thanks a lot for testing! It looks like sometimes scancodes aren't properly decoded. Usually IR signals / scancodes repeat in about 100ms intervals, if no scancode is received within that time it's interpreted as button release.

Can you please do another test, both with milhouse and nightly builds:

Open two shells, in one shell run "ir-keytable -t" in the other one "ir-ctl -r > ir.txt", then press a button for about 2 seconds. After that stop "ir-ctl" with ctrl-c, it should have created an ir.txt file with a large bunch of numbers. Please post both that file and the output you got from ir-keytable -t

I'm suspecting a recent kernel change (switching from ns to us timing values) might be responsible but I can't reproduce that locally with my IR hardware - it might be specific to the nuvoton cir. The ir-ctl raw signal values should hopefully give some more hints.

so long,

Hias

Can you redo the tests and push the button a bit longer, one second or so? Would be good to see more "lirc scancode" lines (at least 5, better 10).

so long,

Hias

Please post the outputs of ir-keytable -t with kodi and eventlircd stopped. Push a button for about half a second, do that both on the milhouse and the latest nightly build.

so long,

Hias

Quote from marantz

hello! ive installed nightly with date 2020-12-30 and skipping works great, however I get weird artifacts on the side of my tv (Sony 55" A85 4K UHD OLED Smart TV KD55A85), it appears both in menu and while playing video.

This is a known issue in the video driver, see eg here RE: LibreELEC display rolled around by one pixel

so long,

Hias

Yes, nightly builds have up-to-date firmwares.

so long,

Hias

beitarj can you please check if you get the same issues with hardware decoding disabled?

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.

See also [BUG] Missing configuration parameter for DWC2 at RPI4 · Issue #4722 · LibreELEC/LibreELEC.tv · GitHub

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