Posts by chewitt
-
-
I'm going to guess that Kodi settings is not in advanced/expert mode so while you enabled PT audio at the top level, you cannot see (and thus have not enabled) PT for individual audio formats like DTS, AC3, etc. so they are being correctly (as configured) sent as PCM audio.
-
Congrats. You spent ages looking at the log file and carefully extracted a segment that shows nothing. In a future post please share the entire debug log so we can understand actual system state and have something useful to look at.
-
Clean install an LE13 nightly and prove the issue exists there first.
-
Even if you can point to something in LE11 or LE12 the next thing we're going to tell you is "update to an LE13 nightly and confirm the issue still exists" .. so better to move forwards with testing than backwards.
-
I've not bothered to read the full contents of your test report. I stopped about 10% into the text; by which point it's obvious that you are a) expecting feature parity with Amlogic vendor kernel images, b) blindly changing settings expecting miracles. Please go read any recent LE release notes (anything from the last couple of years) which contains clear statements on the current state of mainline kernel Amlogic support (nothing has changed much in years). What worries me the most is users with wildly unrealistic expectations for the AMLGX image because they don't read.
NB: You are welcome to continue experimenting with AMLGX, but I don't need bug reports. The issues and current state are all well known (and documented). You are also welcome to continue using the factory Android image, which works, with all features.
-
To be specific, we want to see the system log (not a Kodi log). Run "journalctl | paste" after boot and share the URL.
-
Impossible to answer without seeing a Kodi debug log and system log .. preferrably copied to pastebin as downloading logs from the forum is a pain in the arse.
-
It's not clear to me what you are trying to do .. where do "rules" come from?
For context: not German so not using "radio.de" but Groove Salad is playing fine here using the "SomaFM" addon.
-
1. Yes; except for auto-update of the LE image itself (which you don't want as it doesn't contain the TBS driver).
2. Yes (to all Qs). Just scp the built image to /storage/.update on the box and reboot.
It's worthwhile learning the git basics of committing a change (that adds the patch) to a local topic branch so that you can later git fetch upstream changes (when we publish a maintenance release) and rebase the local topic branch against our upstream changes before rebuilding the image to include the upstream changes.
-
At first it seemed the playthrough was smoother but then the rpi4 started making noises I've never heard before. And I don't even have a fan. Nor heatsink. Just using the official case with the top off.
The boards are designed to run hot but will self-preserve by throttling back. You can't (and shouldn't) run overclocked boards without active or good passive cooling.
-
It's historically very rare to see CEC capabilities on x86_64 hardware so the feature has long been intentionally omitted on Generic derived images (while enabled on ARM SoC devices which almost all have CEC capabilities). As such you can't claim it to be a bug. If there is now a trend of hardware being available; we might need to revise the build confguration. However it's not obvious that this is true, so I would focus on showing/sharing technical evidence of a need.
-
Quote
How do I install the TBS5230 driver that I have built into LE12.0.2?
Even if you align the kernel version magic and manage to build the module on a different distro, it won't be usable on LE unless the LE kernel's module and symbol maps are updated to reference it (else the kernel doesn't know the module exists). The driver .ko and related map files need to be inside the KERNEL file which is decompressed on boot (and is thus read-only and not accessible from inside the OS, the SYSTEM file is the same). The normal and long-term sustainable way to patch drivers into the LE kernel is to compile a custom LE image with the driver changes provided to the buildsystem as diff patches, which are applied to the kernel source before the buildsystem compiles the kernel. The compiled kernel and all required structures are then rolled up into KERNEL which is part of the LE .img.gz or .tar file format we use for updates.
NB: LE used to package Crazycat sources as a driver add-on, but we stopped including them because the Crazycat sources need to be aligned with the LE source version and there were regular periods of months before that happened, which held LE back from making needed kernel bumps. We got fed-up with that and now tell people to vote with their wallet and buy cards supported upstream, but the ability to build the driver add-ons has not been removed from the buildsystem. The kernel versions appear to be aligned right now, so you could also build your custom image with the driver add-on re-enabled and the Crazycat package.mk updated to use the latest version (githash) available. It's still a pile of jumping through hoops in our buildsystem, but might be marginally easier for a novice builder to figure out than extracting driver code from the TBS repo and generating diff patch files to use with our buildsystem.
In case it's not obvious, I'm not volunteering myself to spoon-feed instructions for either option. If you're curious enough there's enough hints above to figure it out, and the LE wiki has basic instructions for self-building images.
NB: These days I think TBS is a reference for "The BS" that customers need to go through to have a card work. Our general advice is to shift the DVB card and e.g. Tvheadend server to a box that runs a conventional distro where you can (re)compile modules for each kernel bump you choose to make (hint: you don't need to do it too often) using whatever instructions or garbage kernel the card vendor dictates: as long as it "works" you don't care. Then use an RPi5 to run pvr.hts as a simple/dumb client-only playback device elsewhere in the network.
-
the GUI is quite usable but the videos, when played, are very "skinny" and have large black bars on eithe side
This is from one of the RPi devs:
"If using dpi, there will only be a single resolution/refresh rate reported. They are configuring the display as 704x240 which will look to Kodi like a wide/short display (2.93:1), so when displaying 16:9 (1.77:1) video on it, you'll have black bars on the sides."
-
elim_garak I'm normally loathe to suggest it, but have you tried overclocking the board?
-
I can't change or adjust the resolution to get 480i.
Kodi only supports progressive output.
-
I have a moderately large media collection; around 2/3 the size of yours. I see occasional 'blank items' due to art being retrieved from the internet, but this is only when the install is relatively fresh. I regularly rotate the main family device among a pool of ARM boards for testing. The configuratin of Kodi and media content doesn't change but the Kodi install is effectively new and it takes a while for caches to populate again. After a week of use there are few 'blank items' and I don't notice caching.
Do you have media on a NAS in the network and a WiFi connection, or is it Ethernet to the NAS, or content is local?. It would be useful to see a Kodi debug log to see timings of actvities and what Kodi is actually doing under-the-hood (what scrapers are being used, etc.). and what errors are reported if any.
-
The Estuary skin is designed for a minimum 720p screen resolution. You might get further with other skins?
There is also a video calibration function in Kodi settings that you can use to adjust the edges of the screen.
