Posts by chewitt

Quote from barturblits

Well it seems my artifacts were an artifact. Cannot reproduce them anymore. I restored the backup I made of Nexus so it is just as I left it last time. But now, no artifacts anywhere, not even the files I tried last time.

Maybe chatGPT-4 can solve the HEVC seeking problem

Then again, it might soon rewrite the entire video driver.

I'm confident there are memory useage/buffering issues in the current HEVC codec, and ultimately there are closed-source firmware blobs involved that can layer their own issues too.

ChatGP is quite interesting but linux media drivers are rather complicated. As Douglas Adams fans will appreciate; the challenge is about asking the right question

Quote from phyrros1

Why does Kodi "Leia" have no problems with HEVC seeking ? What is different to Nexus ?

LE11 uses the upstream Linux kernel that has no code in-common with the LE9 and older vendor kernel. As written in release-notes; AMLGX is not perfect and will not be for all users. I'd love to see improvements to HEVC seek, but I don't write driver code, and there's been a multi-year gap in anyone taking an interest. I'm currently attempting to get the (abandoned but cleaned-up a little) HEVC driver merged upstream in the hope putting the code somewhere public attracts some community contribution.

There's no such thing as "too powerful"

Either the configuration expects files to be in a standard location and you've put them somewhere else, or you configure the location in the add-on (which I don't use or have any experience with) but some kind of unhandled issue with paths or formatting or permissions prevents the files from being read. As generic advice; don't use paths with spaces, ensure the text files have unix line endings (not Windows) and ensure the certs have 600 perms not 644/755/777.

S905L is an S905X without VP9 support, 10/100 Ethernet, no BT, and faked 2GHz CPU (all GXL boards are 1.5GHz). There is no direct support in the upstream kernel but differences from S905X are minor so creating a custom device-tree shouldn't be hard; I started to look at changes for the Venz V10 - though that user disappeared so progress stalled. NB: The current hardware decode drivers assume all GXL boards support VP9 so attempting VP9 media playback will result in blank screens in Kodi.

P201 is a GXBB (S905) device-tree; hence it will not boot a GXL (S905X) derived device. SSV6200 is a newer variant of the SSV6051 chip and also not supported. The SSV vendor drivers are horrific quality (achieving new depths of bad) and do not compile against an upstream kernel, only the vendor kernels. No support means no support.

If you can provide me with the Android dtb file and dmesg boot log, and a working remote control config, I can look at adding support.

The second partition on the SD card is designed to self-resize on first-boot so there is no need to "fix" this non-problem. Just create an SD from the box image and set the dtb name in uEnv.ini .. and that's all to do. As per the Amlogic page in the wiki; do not rename dtb files to dtb.img; do not change the location of files.

Quote from phyrros1

When DRM Prime is enabled I can't skip the video for more than 10sec without the picture freezing. Sometimes pressing the ESC button brings back the menu but it also happens that I have to reboot. When DRM prime is disabled skipping is no problem but the video is kinda choppy - not really smooth.

I assume the codec used is HEVC and thus the clearly written statements about the imperfect state of HEVC seeking that are in release notes are accurate. If the codec is H264 seeking works well (at least in my own testing). One of the upstream kernel static analysis tools recently flagged a memory leak in the HEVC codec and a fix for this will be in LE 11.0.1. That might help prevent resource starvation in some scenarios (stop/escape back to the GUI is more likely to work) but HEVC seeking itself needs development effort, and there are currently no volunteers for the task so you shouldn't expect progress anytime soon. If you disable DRMPRIME content is software decoded, but most 1080p HEVC is a little beyond the CPU capabilities of an S905 board. The Pi Foundation devs are currently working on some changes that might result in a more efficient software decode path that might improve that, but fixing the hardware decoder (needing volunteers) would be preferred.

Just make a backup of the 10.x install in-case you want/need to revert, and then update the existing install. No need to wipe it unless you have a good reason to.

Download the update to /storate/.update and rename /storage/.kodi out of the way then reboot to update. You'll end up with a clean install but can easily copy/move things back to where they need to be. Or if that sounds like gibberish, start over with a proper clean install.

LE is very-much using in-tree (upstream kernel) drivers and not out-of-tree (vendor) drivers.

Use an HDMI audio break-out box to extract stereo audio for RCA outputs; or perhaps S/PDIF if the Amp has a digital input.

Enable "adjust refresh" (start/stop) and "refresh rate doubling" then configure the whitelist for 1080p @ 60/59.94/50/24/23.976 modes.

Quote from taree

i tried these both repo in android side kodi20 and they are working.

but in this le11 build giving error.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

I think it's brilliant when pirate shitware doesn't run on our OS. No further support.

2023-03-16 15:31:48.335 T:140209459025664 WARNING: Attempt to use invalid handle 535
2023-03-16 15:31:50.581 T:140208469178112 WARNING: Attempt to use invalid handle 541
2023-03-16 15:31:52.427 T:140209459025664 WARNING: Attempt to use invalid handle 545
2023-03-16 15:31:59.165 T:140208469178112 WARNING: Attempt to use invalid handle 558
2023-03-16 15:32:04.821 T:140209459025664 WARNING: Attempt to use invalid handle 571
2023-03-16 15:32:06.693 T:140209467418368   ERROR: GetDirectory - Error getting
2023-03-16 15:32:06.693 T:140209459025664 WARNING: Attempt to use invalid handle 576

^ this is in the Kodi log.

Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): error count since last fsck: 1
Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): initial error at time 1676930944: ext4_check_bdev_write_error:217
Mar 16 15:32:07 LibreELECmini kernel: EXT4-fs (sda1): last error at time 1676930944: ext4_check_bdev_write_error:217

^ this is in the kernel log. In my experience this sort of error message points to disk corruption, and with SSDs the main reason for that is cell errors (integrity problems in the memory chips) from a drive that's starting to fail.

Do we have to blindly guess at the problem, or are you giong to provide a full debug logfile?

The pass file probably needs "chmod 600" perms to skip that warning (but it's only a warning not an error). The other errors are fatal and it clearly doesn't see the files or there's something like a space in the filename or path.