Posts by chewitt

I picked up a "Tanix TX3 mini" S905W box for $22 including shipping in 2018. Even if Covid has doubled the cost since it's still a bargain if it helps to get another rouge driver upstream in the long-term (there's no expectations of rapid fixes).

boot=/dev/sdd1 disk=/dev/sdd2 quiet ssh

^ last roll of the dice, this forces the boot/disk params to use the raw disk (sd) card device. If that doesn't work I'm

UPDATE: I've corrected the ^ above, the card reader is changing the presentation of the block device to look like a USB drive, not an SD card which changes some of the /dev/device numbering.

In LE11 (nightly) images (and maybe LE10 .. I can't guarantee though) allow you to configure persistent journal logs. It's intended for debugging but in your case will simply increase the time range there is data for. You will be able to see boot and can see login/logout activities in the journal, but another issue to contend with on RPi is the lack of RTC which means the clock on boot starts from glibc release date not actual time; until the network is up an ntp corrects. You can solve that by adding an RTC chip.

Another approach would be to configure Syslog export of data and track activity in a logger/SIEM tool. You will still need a solution for RTC issues, but when you see gaps in telemetry the Pi was off, and when it's on you get data.

The systemd journal includes OS information and /storage/.kodi/temp/kodi.log contains activities by Kodi. Activities with the application are not necessariily representative of activities of a user though, so you have to interpret the logs.

The single thing that will make the most difference to a nice experience in LE (and not specific to RPi) is a good remote that doesn't have lag in key presses. I have lots of 'stuttery' cheap remotes from Android TV boxes and a nice BT remote that responds like a keyboard with a nice fluid scrolling experience. RPi4 will be 'faster' with overclocking but it's 'fast enough' in stock configuration.

You're better off posting Q's to the RPi developers directly via their forum. While we work with them and support them with a ton of testing effort, the actual development of RPi drivers/ffmpeg is done by RPi Foundation staff.

nuive if the upstream application has a load of problem hardcoded paths; fix the upstream application

Sometimes the "hard" option is actually the easier and better option.

I'm impressed with what's been achieved. The legacy code was an unholy pile of .... to start from

In LE if you create /storage/.config/firmware/ and place the firmware .bin and .cfg files there, they will be overlaid onto /lib/firmware at boot time. I've done that but it makes no difference to load. Here's dmesg: http://ix.io/3NrC and ssv6051-wifi.cfg content: http://ix.io/3NrD

NB: If having samples of the chipset in other SoCs (e.g. Amlogic) would help with the upstreaming effort LE will be happy to fund them.

EDIT .. I noticed this in dmesg:

TX3:~ # dmesg | grep meson-gx-mmc
[ 0.373380] meson-gx-mmc d0072000.mmc: Got CD GPIO
[ 0.376230] meson-gx-mmc d0074000.mmc: allocated mmc-pwrseq
[ 1.164926] meson-gx-mmc d0070000.mmc: allocated mmc-pwrseq
[ 11.361455] meson-gx-mmc d0070000.mmc: DMA addr 0x000080001218b430+8 overflow (mask ffffffff, bus limit 0).
[ 11.364105] meson-gx-mmc d0070000.mmc: dma_map_sg failed

Have a look at the recent history of changes to drivers/mmc/host/meson-gx-mmc.c in the kernel .. I suspect the issue has to do with memory use and alignment.

Quote from frakkin64

I also rebuilt the kernel all the way back to 5.10 and MPEG has been broken since 5.10 (December 2020)

Did you bisect to a breaking commit? .. just that's how far back you've looked? - MPEG2 was the first codec upstreamed (H264 and VP9 were added later) so while it's had less focus it should also work. If 'we' can find the breaking commit it would be a good lead for investigating why the codec is currently broken.

Removing content from "vdec_platform.c" is the correct/easiest way to disable it.

--- a/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
+++ b/xbmc/windowing/gbm/WinSystemGbmGLESContext.cpp
@@ -145,7 +145,7 @@ void CWinSystemGbmGLESContext::PresentRender(bool rendered, bool videoLayer)
   }
   else
   {
-    KODI::TIME::Sleep(10);
+    KODI::TIME::Sleep(40);
   }
 }

^ If someone is compiling their own images and understands how to track CPU usage, that might be of interest.

Interesting. One of the contributors is ilmich and the other is known(ish) to me via Armbian. I was able to compile the driver and trigger probing on a Tanix TX3-mini with a small device-tree tweak to the SDIO node but the driver didn't load: http://ix.io/3Noj - it probably needs some firmware/config stuff adding - it's not clear what though.

NB: Existence of the driver is one thing. LE would want to see it being upstreamed to the kernel before we'd consider picking/backporting the upstream submitted patches to images. Community images are something different.

Here's an example of another panel device listed in that yaml file being added to a device-tree:

arm64: meson: khadas-vim3l: add DSI panel · superna9999/linux@77a9a24

github.com

How well that transcribes to your (different) panel .. I can't say. I'd be asking the vendor/manufacturer for examples. The RPi forms are also probably a better source for help on that kind of thing than here - our expertise rather stops at "connect HDMI cable"

Have a look at how inputstream.adaptive depends upon widevine CDM files being installed to the OS in a known location. If the files are not present, the add-on initiates a download of a ChromeOS update file which contains them, and then the update file is unpacked and the needed files are moved to a consistent location where inputstream.adaptive can find them. This keeps the core add-on size small (and avoids the legal issues involved with pre-bundling the widevine files).

In your case you can detect distro by looking in /etc/os-release and if LE, initiate a download of the needed (bulky) files to a cache location under /storage/.kodi or somewhere else on /storage, and if not LE, check for the package being installed in the known location. Then set the media file paths to either the cache location or the /usr location as needed. On other distros you'll need to gracefully handle the dependency on the app binaries being installed anyway.

Things that use the Amlogic vendor kernel (and suitably hacked versions of Kodi) support HDR > SDR tonemapping - on Linux or on Android using devices. Otherwise you are waiting for Kodi to support it, and drivers to be written for other ARM hardware that has hardware modules that can do it. Or you need to re-rip original media without HDR (which would have made sense since you don't have an HDR capable TV) .. or use a TV that supports HDR.

I pushed the revised dts to my repo. I didn't change anything else with usb, but do you have that change?

deltasjimmy there's lots of prior art for overlays with the RPi boot files. Look in the Pi foundation kernel repo.

LE settings add-on > Updates > Firmware .. if any bootloader eeprom or USB firmware updates are needed they will be visible here and you can enable the update (it will then be done on next reboot).

Kodi can only output progressive, so to handle interlaced media you *must* be using 'doubled' modes for playback, e.g. PAL 25Hz must use a 50Hz mode from the TV. In other words, a 1080p whitelist would be 60/59.94/50/24/23.976 .. deliberately no 25/29.97/30 modes. If you also find one of the pre-10.0.2 testing images from HiassofT these have deinterlace support, it will be in the next 10.0.x release (soon, we hope).

I'm using TVH from a server 4,700 Km away and it's pretty usable