should it also work on nuc 11 Pro?
Hardware name: Intel(R) Client Systems NUC11PAHi7/NUC11PABi7, BIOS PATGL357.0037.2021.0106.1527 01/06/2021 is running LibreELEC LE10,
some video improvements will be required... but playback is mostly fine
Posts by heitbaum
-
-
In other news......
Ethernet and WiFi also not working in Libreelec on NUC11PAH. I am using a USB Wifi dongle which needs to be unplugged and plugged back in after a reboot.
update firmware for 5.10.16 by heitbaum · Pull Request #28 · LibreELEC/iwlwifi-firmware · GitHub
These will fix your Ethernet and wifi
-
The issue is more the logs and the why. We have identified why now - deinterlacing settings in the vaapi. Next steps will be to perform some tests and get to an end state.
See the bug an pull request.
-
Hi chewitt - dd’ed the vim3 2020-Dec-19 13:16 image to the SD card and booted it.
Not exactly sure on what is not working, after the boot kernel message, we get some orange on the screen then loose hdmi signal, and led light goes off.
From the rescue SD, was able to install a coreelec.kresq image
Also a little unsure on the required update to the u-boot to SPI/emmc from your repo. I’m running 2020.4 (November) on the unit at the moment. With “kbi bootmode w spi”.
A pointer would be great. -
First impressions:
LibreELEC build fine with only one packages removed on Generic
Specifically: nvidia-legacy (licence taint issue)
It runs Matrix 19b2
2 pulls required to get going.
Update RTL wifi drivers to 5.10 by CGarces · Pull Request #4691 · LibreELEC/LibreELEC.tv · GitHub
-
Checking with ffmpeg it definitely decodes, but I can’t tell if it is using the hwaccel? And why/what the profile it has mapped the .ISO (mpeg2video) to.
Codeffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -i a.iso -pix_fmt yuv420p a.yuv#6668 (MPEG2 decoding failed with FFMPEG-VAAPI) – FFmpeg
Based on the above post - moeg2video HW decoding was suppose to be fixed in Jan 2020 and in the following ffmpeg branches - master n4.4-dev n4.3.1 n4.3
-
I have been chasing the errors in my kodi.log for a while now. As you would know I think I have made all Intel Generic current or head in the build tree.
Code2020-12-06 21:48:28.754 T:5314 ERROR <general>: VAAPI output: Postproc preinit failed 2020-12-06 21:48:28.787 T:5314 ERROR <general>: VAAPI/vpp vaCreateConfig error: the requested VAProfile is not supported (12)This occurs when playing ISOs (DVD) or mpeg2video as the video stream in a MKV.
I have believe that the that Intel chip is suppose to suppose this decoding. As per the details at VAProfile is not supported (12) With MPEG2 playback · Issue #477 · intel/libva · GitHub VAProfileMPEG2Main is supported.
The media details itself are:
CodeStream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg, progressive), 720x576 [SAR 16:15 DAR 4:3], 25 fps, 25 tbr, 90k tbn, 50 tbcThe full ffprobe output of the ISO is at - http://ix.io/2GQe
I added vadumpcaps to my build tree - vadumpcaps: add vadumpcaps to show all capabilities of a VAAPI device… · heitbaum/LibreELEC.tv@821ea50 · GitHub and from that it seems like Kodi/.... is incorrectly mapping the media type to 12 (which is JPEG.) - full output at http://ix.io/2GQl
So by my reading of vadumpcaps - VAProfile should be 1 for this media? Is this right / or am I chasing the wrong thing?
Code{ "profile": 1, "name": "MPEG2Main", "description": "MPEG-2 Main Profile", .... { "profile": 12, "name": "JPEGBaseline", "description": "JPEG", -
Took delivery of my N2+ Yesterday (Sunday) - DHL working all days at the moment....
after a bit of stuffing around and a pointer from tobetter. My notes to install Ubuntu 20.10 with 5.10rc and panfrost on the device - http://ix.io/2G19
In reading your chewitt logs in the mainline, it seems this N2+ is really only just now being supported in mainline without the ARM mali binaries.
Looking forward to running up LE on this.need to get back to coding.
-
I would like to suggest increasing the default log_buf_len to 128K or 256K (not the 16M that I have on my dev unit)
The later 5.x kernels boot logs are no longer complete using the default ring buffer size.
# grep log /flash/syslinux.cfg
APPEND boot=LABEL=System disk=LABEL=Storage log_buf_len=16M quiet
# dmesg | wc
961 8316 65437
# uname -a
Linux LibreELEC 5.9.11 #1 SMP Thu Nov 26 12:54:34 UTC 2020 x86_64 GNU/Linux
Happy to raise a PR either as syslinux or CONFIG_LOG_BUF_SHIFT if this makes sense.
-
-
thanks chewitt - Ill create a PR on le10 master - and have a look at paragon / 5.x too. Still busy getting my head around dbus.
-
Hi Team,
Suggesting we move to Version 2017.3.23AR.x as has been done in some mainline distributions.
E.g. Linked packages : ntfs-3g
Details are available at: NTFS-3G: Changelog for the Advanced Versions
Also noting some changes to behaviours of the caching in the driver (read the change log - NTFS-3G Safe Read/Write NTFS Driver Activity )
Specific patches are:
NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [39384c]
NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [5d6fd5]
If this is an suitable direction to move in, I’ll create a branch and put together a draft pull request.
-
Looks like a false alert. A USB device I had connected was causing the issues and random kernel crashes. Will continue to do further tests.
-
Different Kernel error back on - Linux LibreELEC 5.9.6 #1 SMP Wed Nov 11 06:51:19 UTC 2020 x86_64 GNU/Linux
ext4
-
Hi All,
As FYI only.(I'm rebuilding back to 5.9.6) against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI and will advise. How it goes.
I just rebase lined GitHub - heitbaum/LibreELEC.tv at build_rudi + Kernel 5.9.7 against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI
The compiled 5.9.7 with the rebase lined LibreELEC/Master "82a92d8d21762f2dc442b7794a6e02e3c5b74316" on the NUC6i5SYB is having kernel issues with: Workqueue: events azx_probe_work [snd_hda_intel]
Logs are at: http://ix.io/2DJH
Linux edbf6b369537 5.9.7 #1 SMP Tue Nov 10 13:49:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
-
Hi HiassofT
Some background on why I'm interested in following this through probably in order.
Note: I did laugh at the comment "CEC is pretty much voodoo to me...!" - so true.
I have the following AV equipment:
- Panasonic Viera TH-50PX600A
- Sony STR-DN1040
- Intel® NUC Kit NUC6i5SYH with "Intel NUC HDMI-CEC Adapter" (LibreElec Matrix)
- Apple TV 4K
- Cisco Webex Room Kit (experimenting / WfH)
- BrightSign CV-UHD2 / CV-HD2 (experimenting)
- Elgato 4K60 S+ / HD60 S (experimenting)
- Xbox 360 S (no CEC support)
I have the following home automation: Apple HomeKit, Apple HomePods, Hue Lighting, Homebridge (experimenting with openHAB).
The lighting works well - the rest ..., leave that unsaid.
I have had a love hate affair with the CEC in Kodi and AppleTV.
I was excited to purchase the HDMI-CEC adapter in 2018 (but that was short lived... - as below)
- The AppleTV sends a power on (but the Panasonic ignores it - CEC bug / non standard) - so the TV is always on. The Sony AMP changes itself to the AppleTV HDMI input.
- The Kodi generally misbehaves.
a) (Given my "Panasonic BUG" - that I would like to teach Kodi to send the following codes 80:44:40,80:45) as it already is successful in "power off" the Panasonic - thus I need to find the Panasonic Remote Control .
b) Kodi loves to own the CEC network and when the Sony AMP decides to power off - due to no Audio. Kodi will decide to Turn the AMP back on.
c) On swapping to AppleTV - Kodi does not honour the CEC commands always and switches back to Kodi. We then go and power Kodi off
d) When the remote control menu item <play> is pressed on the iPhone remote - the AMP does not switch on/nor does the input on the AMP change. The Apple TV using the Remote contol does power on the AMP and change the input (think Kodi should too.)
I had a look at: GitHub - joshjowen/script.json-cec: cec control for xbmc/kodi (to put some scripted workarounds in), but it does not allow arbitary CEC codes to be pushed. As Kodi owns the the CEC device entirely, I can't write a script to fix/workaround my issues. If I tell kodi to not enable CEC, then I can use cec-client to fix some of my issues.
The Sony AMP doesn't really automate very well either, though the codebase - GitHub - balert/Sony-STR-DN840-Remote-Python: Control your STR-DN840 receiver via the network interface. does work.
I have worked on a state machine diagram of what I want to happen so that this can be configured in to the home automation. But without the ability to issue CEC commands - I have reached the "unhappy - it does not work state."
Options as I see it:
1 - Use the kernel framework (same as #1 - but with no required code change)
2 - Have passthru access through Kodi to CEC (Changes to Kodi/script.json-cec/libcec)
3 - Disable Kodi CEC and hack with cec-client
4 - Develop functionality (addon) in Kodi - haven't really investigated - relies on #1 in some way
5 - Buy a dedicated CEC device
6 - Buy a new TV (and hope it works right - hi risk - what is works right)
7 - Give up -->
- as I actually like my "pet project"The actual Panasonic BUG - Power On does not work:
Panasonic Viera TH-50PX600A - Power On does not work · Issue #511 · Pulse-Eight/libcec · GitHub (not fixed in libcec - I don't see it being fixed by pulse8 anytime in the near future)
Need to send the following to make it work:
In my case: (Playback 2 —> TV)
80:44:40
80:45
In my enterprise office work environment we toy / flirt with "AV Control Systems" - and most of the time they are broken in their own special way. We have been successful with end-user devices like Cisco Webex hardware mostly with wireless screen sharing. But continue with the usual issues using HDMI extenders and the like. Recently been looking at Wyrestorm, rticorp.com, Cisco Video to simplify AV in the office and standards based AV/IP. I guess - what does this have to do with the /dev/cec0 discussion - I'm looking to have a working Home Automation system and the Kodi CEC configuration as-is doesn't allow for that. Overtime and if I can get my state-machine automation fully correct and working well - it might be that #4 could be done on either the built in CEC or as a addon.
Hope the above helps my case.
I do understand the support issue that you have mentioned though and would not at all propose to move from the userspace integration - it is good to have pulse8 looking after that codebase. My question to this - is that we are already supporting the Kernel interface for the other hardware (note: I don't disagree that linux-console is an additional product though.)
Regardless of the core teams decision to change the way for everyone, I would like to continue down the route of using cec-ctl for the moment, even if I have to maintain a separate branch/autstrat.sh commands. I would appreciate you pointing me in the right direction to add the build of linux-console into my branch though (so that it was buil;t properly.)
**Note: Without implementing my proposed systemd/udev changes - Kodi Generic would continue to use the /dev/ttyACM0 mechanism. The Kernel Framework is only ever activate if the modprobe and inputattach are run.
Thanks for your consideration.
-
Hi Hias,
100% agree with the get the supported approach, for which is the official libcec. As I understand it libcec is now supporting the Linux kernel framework (in passthrough) since April 2020 - RFC: Linux CEC framework adapter by Kwiboo · Pull Request #380 · Pulse-Eight/libcec · GitHub With the kernel driver (5. CEC Kernel Support — The Linux Kernel documentation) integrated with libcec now and allowing Kodi to continuing to exclusively use the libcec api. My proposed patch for which I note that Milhouse had eluded to in a recent Generic image #0717 - LibreELEC Testbuilds for x86_64 (Kodi 19.0) and in the below GIT branch.
The Milhouse branch where the CEC changes are for Generic is: Comparing LibreELEC:master...MilhouseVH:le10_libcec_next-drop-framework · LibreELEC/LibreELEC.tv · GitHub
The patch I'm proposing is:
Comparing LibreELEC:master...heitbaum:master · LibreELEC/LibreELEC.tv · GitHub
pulse8-cec: enable via Linux Framework · LibreELEC/LibreELEC.tv@79fb25d · GitHub
The patch includes all udev and systemd changes to make it work. I have included a binary compile in my patch just for the time being - but would propose incorporating linuxconsoletools-1.7.0.tar.bz2 and compiling the utils/inputattach
This still maintains the normal libcec operation within Kodi - but also integrates the remote control passthrough feature into the kernel’s remote control framework.
Hope this answers all the questions and that it can be incorporated in the mainstream Generic support.
Thanks
Rudi
-
Will recompile and retest.
Code-CONFIG_SERIO_SERPORT=y +CONFIG_SERIO_SERPORT=m -CONFIG_CEC_CORE=y +CONFIG_CEC_CORE=m +CONFIG_CEC_NOTIFIER=y +CONFIG_MEDIA_CEC_SUPPORT=y +CONFIG_USB_PULSE8_CEC=m
