Posts by chewitt

Quote from w46n3r

like the infamous 12/10 bit issue on N100

Which has been patched in LE13 images for quite a few months now..

It's a moot point. If one person (or LLM) is the analyser of the existing design, writer of the specification, legal reviewer, and clean room implementer the result is almost certainly not clean. See https://en.wikipedia.org/wiki/Clean-room_design

In the v7 submission everything below the first paragraph should have been placed under the --- separator so that it is visible to reviewers but not merged into the codebase along with the description.

I normally place things above --- during development so that testing commentary is easily edited and not forgotten, but then you need to remember to tweak the final patch files before sending to move the --- above it.

Quote from Mayoru

I think that there is a problem with the auto switcht feature. If I set a screen as prefered, It should be used the moment the screen is available. I would say this is a bug.

This was merged in Kodi https://github.com/xbmc/xbmc/pull/28633 .. and you will spot me clearly calling out that this feature is not working as it needs to, but it was merged anyway. Technically this is not a bug because the [bad] code is working as [badly] designed; and that incomplete design will be extended in K23. I predict the fix to be invasive; lots of things need to be touched, so it's unlikely we can backport anything to K22.

Our current plan is to hide the setting in the GUI to stop people using it and then complaining it doesn't work as they expected it to work and how it needs to work.

It all depends on how the implementation has been done. If Astra decided to decompile/reverse Dolby blobs then the outcome is illegal. If it's been done under "clean room" conditions (which arguably might be impossible with AI agents that learn from other users input) then it's probably harder for Dolby to challenge. Either way, the moment source code that works is posted or leaked somewhere things will be interesting.

The latest AMLGX images in my test share should have working pass-through audio for G12A/G12B/SM1 boards; You may need to check/set the audio output device first. The latest images for GXBB/GXL/GXM also have pass-through support, but there are small dropouts on TrueHD/DTS-HD media that I haven't been able to eliminate yet. If you disable both of those (select dts-core for DTS-HD) they will be output as AC3 instead. Normal DTS/DD are working fine.

Quote from edrobal

I got it. Since you don't have any competition, we have to shut our mouths. I do

There are 20+ major distros that have a Kodi package. You are not forced to use LE; whatever works for you work for us.

I did ask you to test the current LE13 image, but you refused. Triage 101: first eliminate all the bugs and issues fixed since the release the user is running by testing the current development release. Nobody has been developing the LE12.2 codebase for 18-months beyond bumping add-ons so even if a problem was identified it will never be fixed in that release.

And nobody told you to shut your mouth, but we are all volunteers working in our often-limited free time. If you can't be arsed to help us with basic testing and information, we can't be arsed either.

Gismeteo comes from the Kodi repo so it's not our problem. The service probably changed something in their API and the add-on needs correcting. Go look at the Kodi forum support thread for the add-on for more info.

I don't see any libretro issues in the Kodi logs but Kodi retro-gaming stuff is still subject to changes upstream. If updates are made available we will pick them up automatically in the coming days.

Quote from olafzen

Is there a way to build new, without a make clean?

Just run PROJECT=RPi DEVICE=RPi4 ARCH=aarch64 make image again. The buildsystem creates a stamp (hash) of each package folder containing build instructions and for the linux package this includes the defconfig files too. On running the build command the buildsystem will walk through all required packages skipping those where where the stamp remains valid and rebuilding any where change is detected; the stamp for linux will not be valid as the conf was edited so the package will rebuild and you'll have a new image. The image 'respin' time depends on what you are (re)building on; for me cross-compiling from on a 32-core x86_64 box a minor kernel change is ~2 mins.

NB: As a general rule you can avoid a full clean rebuild unless certain fundamental packages are changed; glibc is one of them but there are a couple of others I forget the names for. If the respin fails repeatedly or the result is bad a clean build is the best way to ensure stale packages were the cause. Simple rm -rf on the build.LibreELEC folder is faster than make clean.

If the driver doesn't support suspend then it's nVidia's problem because it's their driver, all we did is package their driver into our distro image.

It's not possible to install .deb packages but it is possible to unpack them to see what's inside:

ar x package.deb
mkdir /storage/deb
tar -xf control.tar.xz -C /storage/deb
tar -xf data.tar.xz -C /storage/deb

If the tool(s) are a single binary, inspect it with ldd to see if it's a static binary or linked against shared libraries. Manufacturers tend to compile this type of tool as a static binary to make it self-contained and more portable across a larger group of distros; and if true, you can probably just copy the binary and run it on LE with some supporting scripts and a systemd service.

If the tools are a whole suite of binaries etc. then it's probably a dead end.

I gave support advice. You chose to ignore it. Your problem is not our problem.

This is the alsa conf that LE12.2 uses, it is focussed on HDMI output and the 3.5mm Jack output is unlikely to work:

WIP: add confs for gx-sound-card and axg-sound-card · chewitt/alsa-lib@5b81165

github.com

I am reworking audio support for LE13 to hopefully to get pass-through HDMI audio working. I might play with analogue later, but it's not a priority for LE users so not a priority for me either. I have no interest in trying to support other distros like Debian - which has a forum where you can ask for help from people that understand its packaging and requirements.

LE13 dev images support installation of browsers via flatpak. There are test images here: https://chewitt.libreelec.tv/testing/ although the latest ones posted have some major improvements for video decoding and I have not tested them on S905X3 (SM1) hardware yet. Testing is $free though.

In future posts please use line-breaks in your text instead of posting one huge wall of text.

Test an LE13 image. You will need to cross-grade to Generic as Generic Legacy no longer exists. Clone your Kodi folder before to give a downgrade route. Any addons that depend on OpenGL should be removed first; leave settings and reinstall OpenGLES versions afterwards. There’s no guarantee this improves anything but LE12.2 is no longer being developed so best to test v.next.

Download an appropriate picons set from https://openpicons.com/?dir=full-motor-utf8snp/hardlink to /storage/picons/tvh and then reset the icons in the Tvheadend GUI so they are picked up. I've found that I needed to delete /storage/picons/tvh and then move/rename the unpacked folder to that location.

Done

I found https://discourse.osmc.tv/t/solved-my-rf…di-v17/22118/46 from a Google search on the USB device IDs. I'm not sure it's the same problem, and it would be interesting to see journalctl | paste output from the system before and after the following udev rule is created in /storage/.config/udev.rules.d/51-not-a-joystick-rm.rules .. beware the line-wrapping in the forum, it should be two lines:

# /storage/.config/udev.rules.d/51-not-a-joystick-rm.rules
# based on: https://github.com/denilsonsa/udev-joystick-blacklist

SUBSYSTEM=="input", ATTRS{idVendor}=="25a7", ATTRS{idProduct}=="2402", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="25a7", ATTRS{idProduct}=="2402", KERNEL=="js[0-9]*", RUN+="/usr/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

EDIT: linking https://github.com/raspberrypi/firmware/issues/1189 too; which looks to be a different issue that mentions the same devices ID's, but might somehow be relevant since we use RPi kernel and not mainline kernel sources for RPi images so the change will be present in our kernel.

Disable the internal screen first then so there's a single device, then it will run.