I'm curious how to use widevine with pure aarch64 kernel and system.
Google ships 64-bit versions of Widevine for x86_64, and 32-bit versions for ARM. There are no known sources for 64-bit ARM libs.
I'm curious how to use widevine with pure aarch64 kernel and system.
Google ships 64-bit versions of Widevine for x86_64, and 32-bit versions for ARM. There are no known sources for 64-bit ARM libs.
Comparisons with another Linux OS (Ubuntu, Fedora, etc.) are relevant - if it works fine there, there's some level of proof that the hardware and firmware combo can play nice with Linux. Proof that it runs great under Windows isn't particularly insightful since a) You'd expect a product built to run Windows to play nice with Windows, b) The Windows power architecture is completely different to Linux.
Issues with Shutdown/Restart are normally related to BIOS/firwmare versions (supporting ACPI states correctly) and power/config settings in the BIOS/firmware (what's needed for Windows isn't necessarily what's needed for Linux). And some hardware is just broken and there's not much we can do about it. You might want to start by telling us what hardware you have?
The OVA image we spawn from Generic images is designed for vmware to make booting in a Desktop environment simple, and with the sole purpose of supporting development of project GUI items like the settings add-on. Any other kind of platform or use-case is deliberately "not officially supported" to keep project maintenance simple. Over time the number of other environments it might work in has probably grown, but we do not test that image much, have no intention to start testing it much, so anything that happens to work is accidental.
In all cases LE needs to boot with a supported GPU, which is either real hardware mapped for our use, or one of the working virtual GPUs in the kernel. The Generic kernel defconfig is probably missing drivers for whatever GPU that proxmox uses; or the GPU that is there doesn't support the OpenGL video pipeline that Kodi requires.
Glad that you got it working
If you're only going to be playing SD media I'd suggest that you disable hardware decoding in Kodi playback settings. The upstream decoding drivers are fine with H264 but aren't perfect with older codecs or HEVC. However the S905X chip never runs particularly hot and small filesize media isn't too challenging to software decode, which will avoid hardware decoding glitches.
Suggestion:
Connect directly to the (working) TV, dump the EDID and set this for use, reconnect to the AVR, than hope it all still works.
info <general>: Found resolution 1280x720 with 1280x720 @ 50.000000 Hz
debug <general>: CGBMUtils::CreateSurface - created surface with size 1280x720
Kodi is started and apart from there being only a single resolution ^ available (720p@50) everything looks normal. I guess the head-unit is expecting some other resolution as input? - so you may need to force the CVBS output to something else using kernel boot params.
e.g. something like "video=TV-1:1920x1080M@60" added to params in /flash/extlinux/extlinux.conf
NB: I'm not 100% sure of the connector name (TV-1) or what resolutions are possible.
Hardware decoding on a modern kernel codebase requires patched kernel + patched ffmpeg. LE sources are currently as good as it gets:
The manjaro folks are tracking patches fairly well to result in a useable 'current' distro. Performance and feature completeness on the vendor kernel (used by CE) is better, but compatibility between old vendor kernels and the rest of a modern distro codebase can be a challenge.
The main negative I've seen in the LE/AMLGX image with LePotato is 100-BaseT Ethernet (common to all S905X boards). If trying to play large ISO rips Kodi often warns about slow sources etc. - S912 devices are normally better since most have Gigabit NICs.
NB: CE is run as a separate project so report any issue to their forums, we don't track their images at all.
Two suggestions:
a) Drop the kernel.img and SYSTEM files from dtech images into /storage/.update/ and reboot to udpate to 9.2.8 which might behave better than Ye Olde 9.0.2 image now.
b) Have a play with https://chewitt.libreelec.tv/testing/LibreE…lepotato.img.gz which is using K20rc1 and modern uboot and Linux. Hardware decoding isn't perfect and there are some features on the long-term to-do list still, but as long as your media requirements aren't too challenging it's quite usable.
echo "<advancedsettings version=\"1.0\">" > /storage/.kodi/userdata/advancedsettings.xml
echo " <loglevel hide=\"false\">1</loglevel>" >> /storage/.kodi/userdata/advancedsettings.xml
echo "</advancedsettings>" >> /storage/.kodi/userdata/advancedsettings.xml
reboot
cat /storage/.kodi/temp/kodi.log | paste
^ The advancedsettings.xml file content puts Kodi into debug mode. Then share the URL so we can see what DRM properties Kodi can see?
I restored win11 on the same PC and it sleeps and wakes normally so it's not the hardware/bios.
Comparison to another Linux distro would be relevant. Comparisons to Windows are not insightful (sadly)..
You will need to look on the device to discover the device MAC address. If it's a half-decent device it should be on a sticker somewhere. Worst case you might need to pair it with a phone or other desktop computer and then look at the connection details to find it out before unpairing and then using the info to pair in LE.
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Input #0, mpegts, from 'bluray://udf%3a%2f%2fsmb%253a%252f%252f10.220.0.41%252fFilme_LW_11%252fThe%2520355%2520(2022)%252fThe%2520355%2520(2022)%2520%255b2160p%2520TrueHD%2520Atmos%2520%255d.iso%2f/BDMV/PLAYLIST/00002.mpls':
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Duration: N/A, start: 600.000000, bitrate: N/A
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Program 1
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:0[0x1011]: Video: hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:1[0x1015]: Video: hevc (Main 10) (HDMV / 0x564D4448), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:2[0x1100]: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 7.1, s32 (24 bit)
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:3[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 640 kb/s
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:4[0x1101]: Audio: truehd (AC-3 / 0x332D4341), 48000 Hz, 7.1, s32 (24 bit)
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:5[0x1101]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 640 kb/s
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:6[0x12a0]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:7[0x12a1]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:8[0x12a2]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)
2022-12-29 23:22:16.609 T:800 info <general>: ffmpeg[0x65acc20]: Stream #0:9[0x12a3]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090)
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 0
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream - discarding Dolby Vision stream
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 2
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream - discarding duplicated bluray stream (truehd ac3 core)
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 4
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream - discarding duplicated bluray stream (truehd ac3 core)
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 6
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 7
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 8
2022-12-29 23:22:16.609 T:800 debug <general>: CDVDDemuxFFmpeg::AddStream ID: 9
2022-12-29 23:22:16.609 T:800 info <general>: Opening stream: 0 source: 256
Display More
^ According to this, there are two streams: #0 which is 4K, and #1 which is 1080p. The next lines are confusing as they appear to show stream 0 being discarded (as it contains Dolby Vision) and then the last line shows it opening stream 0. Regardless, the root issue here is no support for Dolby Vision. This is a known restriction; there is no open-source implementation for Dolby Vision. Kodi can play DV media on Android devices that have DV licensed support built-in to their software, and on a small number of Linux devices that use (Android oriented) ARM vendor kernel/ffmpeg sources have have DV support. Nothing exists for Intel so there is no playable video stream; hence what you see.
2022-12-29 11:28:54.444 T:758 info <general>: Device 3
2022-12-29 11:28:54.445 T:758 info <general>: m_deviceName : hdmi:CARD=PCH,DEV=0
2022-12-29 11:28:54.445 T:758 info <general>: m_displayName : HDA Intel PCH
2022-12-29 11:28:54.445 T:758 info <general>: m_displayNameExtra: SAM SAMSUNG on DisplayPort #0
2022-12-29 11:28:54.445 T:758 info <general>: m_deviceType : AE_DEVTYPE_HDMI
2022-12-29 11:28:54.445 T:758 info <general>: m_channels : FL, FR, LFE, FC, BL, BR, BC, BLOC, BROC
2022-12-29 11:28:54.445 T:758 info <general>: m_sampleRates : 32000,44100,48000,88200,96000,176400,192000
2022-12-29 11:28:54.445 T:758 info <general>: m_dataFormats : AE_FMT_RAW,AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_RAW
2022-12-29 11:28:54.445 T:758 info <general>: m_streamTypes : STREAM_TYPE_AC3,STREAM_TYPE_DTSHD,STREAM_TYPE_DTSHD_MA,STREAM_TYPE_DTSHD_CORE,STREAM_TYPE_DTS_1024,STREAM_TYPE_DTS_2048,STREAM_TYPE_DTS_512,STREAM_TYPE_EAC3,STREAM_TYPE_TRUEHD
^ This shows the TV (or presumably the AVR passing through the TVs EDID) connected to "hdmi:CARD=PCH,DEV=0" .. while:
2022-12-29 11:29:35.322 T:759 info <general>: CActiveAESink::OpenSink - initialize sink
2022-12-29 11:29:35.322 T:759 debug <general>: CActiveAESink::OpenSink - trying to open device ALSA:hdmi:CARD=PCH,DEV=1
2022-12-29 11:29:35.322 T:759 info <general>: CAESinkALSA::Initialize - Attempting to open device "hdmi:CARD=PCH,DEV=1"
2022-12-29 11:29:35.331 T:759 info <general>: CAESinkALSA::Initialize - Opened device "hdmi:CARD=PCH,DEV=1,AES0=0x04,AES1=0x82,AES2=0x00,AES3=0x00"
2022-12-29 11:29:35.331 T:759 info <general>: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
2022-12-29 11:29:35.331 T:759 info <general>: CAESinkALSA::InitializeHW - Using data format AE_FMT_S32NE
2022-12-29 11:29:35.331 T:759 debug <general>: CAESinkALSA::InitializeHW - Request: periodSize 2205, bufferSize 8820
2022-12-29 11:29:35.342 T:759 debug <general>: CAESinkALSA::InitializeHW - Got: periodSize 2205, bufferSize 8820
2022-12-29 11:29:35.342 T:759 debug <general>: CAESinkALSA::InitializeHW - Setting timeout to 200 ms
2022-12-29 11:29:35.342 T:759 debug <general>: CAESinkALSA::GetChannelLayout - Input Channel Count: 2 Output Channel Count: 2
2022-12-29 11:29:35.342 T:759 debug <general>: CAESinkALSA::GetChannelLayout - Requested Layout: FL, FR
2022-12-29 11:29:35.342 T:759 debug <general>: CAESinkALSA::GetChannelLayout - Got Layout: UNKNOWN1, UNKNOWN1 (ALSA: UNKNOWN UNKNOWN)
Display More
^ This shows the Kodi output device is "hdmi:CARD=PCH,DEV=1" which is not connected to anything that provides EDID info to define what the output is capable of, so Kodi falls back to 2-channel audio. TL/DR; select the DP output in the GUI (should have 'SAMSUNG' in the name) and you should get multi-channel audio.
LE images using GBM don't support screenshots due to changes in the video pipeline; this is known and not a bug.
It shows the drive being detected.. can you do "journalctl | paste" and share the URL as this will show more about systemd (which runs the service units that do sharing).
The config.txt file passes instructions to the boot firmware of a Raspberry Pi board. It doesn't exist on other hardware platforms.
Run "journalctl | paste" and share the URL please.