Am I doing something wrong? I've got expert mode turned on.
The wiki article that mentions the PQ setting links to two GitHub pull requests; one for Windows, one for Android. TL/DR: the setting is not currently supported on Linux.
Posts by chewitt
-
-
It's always cheaper to acquire something locally from Amazon than have people ship something to the UAE, and we have funds for that kind of thing .. so it's not an issue. Time is a greater factor.
-
You are using the Q201 device tree file which is created from:
linux/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi at master · torvalds/linuxLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.github.comlinux/arch/arm64/boot/dts/amlogic/meson-gxm-q201.dts at master · torvalds/linuxLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.github.comNeither of them describes the &uart_A connection required for BT to work, e.g.
linux/arch/arm64/boot/dts/amlogic/meson-gxm-gt1-ultimate.dts at master · torvalds/linuxLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.github.comIt's probably easiest to experiment with some other GXM device-tree files as GXM hardware is all pretty similar and other files will probably give you a working (or working okay enough) system.
-
It's interesting that N150 might also be impacted with that issue, I'd previously believed it was limited to N100.
I probably need to order a box to do some testing and experimentation with, although the current queue of stuff on my desk is getting long and I'm probably lying to myself about available free time.
-
Would you say this is acceptable or is there another model you'd recommend?
We avoid recommendations on wireless kit as the advert almost never tells you which chipset is inside the device, and that's the one piece of information needed to assess whether it will work OOB or not. That specific specific advert explicitly states that device does not work on LE, but that's probably based on outdated info .. so who knows.
-
Modern SD cards are only marginally slower than eMMC storage chips from 2014. You should also experiment and see if the AMLGX image, which is not as fully-featured as older vendor kernel images, works for you. For a good number of people it does, but it's not for everyone.
-
H.264 hardware decoding failure on Raspberry Pi 5
RPi5 will never hardware decode H264 media (as it has no H264 hardware decoder) .. so that's incorrect.
Hard to blind guess what the reason for software decoding to fail is. The log snippet is irrelevant, and the full log is not a debug log so we can't see any of the useful media negotiation info. Go create a a proper debug log.
-
CatchupTV is not on the banned list. Other items are though.
Here's the list: https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
-
Doesn't R40 supposed to support VP9 decoding? Why isn't hardware decoder used?
Hardware supporting it and someone coding drivers to implement that support are different things .. is probably the reason.
-
Read: https://wiki.libreelec.tv/hardware/amlogic#installtointernal
TL/DR: You either stick with the old install on eMMC, or boot something newer from an SD card.
-
-
LE 12.0 to LE 12.2 does not require a clean install. The core OS is updated, but it's the same Kodi version in both images.
I've no idea what the problem could be, but if you see the splash screen the OS has booted and should be running. However Kodi has not started and thus nothing gets rendered over the splash screen. If you add "ssh" to kernel boot params in cmdline.txt the SSH daemon is forced on and you can probably SSH in to capture the log from the device. Or the Logfiles SMB share might be accessible over the network.
-
The log isn't a debug log and the catchup plugin you are using hides all the useful ffmpeg information on the media. Then I noticed banned add-ons installed, and found something else to do.
-
It's unclear what the actual issue is (debug logs demonstrating the problem would help) but disabling DRMPRIME is a workaround and not a fix. You will probably/eventually find that other media will play badly because you've disabled the optimised decoding path and are forcing media to be less efficiently handled.
-
Any idea?
LE 9.0 uses the legacy vendor kernel and amcodec in Kodi. LE 10.0 onwards uses the upstream kernel which reimplements hardware decoding (but the implementation is incomplete) and Kodi dropped support for amcodec in 2017 as part of an intentional purge of prioprietary codecs and refocus on standards.
TL/DR: the codebases are completely different and while most media plays reasonably well on a C2 it is not pefect and will not work with all media for all users. The upstream codebase is mature and stable for practically everything except media capabilities, where work stalled years ago and has never resumed. You may find that some media is badly encoded and re-ripping from the original sources or re-encoding makes things more playable.
NB: mkv is a container not a format so it's hard to comment further without knowing what the actual format was (although HEVC is the most likely answer).
-
-
You'll need to share a full debug log for anyone to comment, log snippets are pointless.
Once we see the full log it'll probably reveal that you're trying to play a 4K 10-bit HEVC file and that will fail because there is no HEVC hardware decoding support on S905X3 (SM1) devices and the CPU is too weak for software decoding.
-
Changes will be reset on HDMI hotplug events, and that includes reboot.
