In post #1 you state that crossfade works. In post #3 you state crossfade doesn't work.
I'll let someone else take up support from here.
![]()
In post #1 you state that crossfade works. In post #3 you state crossfade doesn't work.
I'll let someone else take up support from here.
![]()
inputstream.adaptive installs inputstreamhelper (widevinehelper?) which handles downloading the chromeos image we have to extract libwidevine from the first time an add-on that requires it is used. I'm using IA on an RPi5; which uses exactly the same IA addon as RPi4 (same files/repo). I'm using it on an LE13 image, not LE12.2, but that shouldn't make any difference as the add-on versions are kept in sync.
If something is failing there will be info in kodi.log.
As 99%+ of users will use the Generic album scraper to scrape their albums, it makes sense to include it in the embedded filesystem instead of incurring bandwidth and the inconvenience of having to download/install it. As Mr Spock says .. "the needs of the many outweight the needs of the few".
If you want to remove it you need to compile your own custom LE image that omits it as a default installed item. You are welcome to do that (all the sources are public and GPLv2) but staff aren't going to be too interested in spoon-feeding instructions, you will need to figure out how on your own. The easier option is to ignore it and/or don't use the generic scraper.
Soundcloud is an online audio source and not an album in the local music database; which is where Kodi stores knowledge of an album and album volume preferences. If you want to set a persistent volume level for all soundcloud objects, or soundcloud album objects, you need to make a feature request to the add-on maintainer via the Soundcloud addon support thread in the Kodi forum; and then wait patiently until someone investigates, and if possible and you are lucky, implements the feature.
Some users desire complicated lives ![]()
Although they are add-ons, they are 'core' Kodi capabilities and Kodi expects them to be present, hence they are pre-installed and reside inside the squashfs SYSTEM file which is expanded into a virtual filesystem on each boot. You cannot delete something that exists inside a read-only file.
LE distro packaging is not like a normal distro and we require TWO partitions; one used for boot files (KERNEL/SYSTEM, 512MB to 1GB in size, can be VFAT or EXT4) and one for a persistent /storage area (4GB+ and must support Linux permissions, e.g. EXT4). If you understand what you are doing it shouldn't be hard to reconfig free space to create the required TWO partitions, copy boot files over to the boot= partition, then create the config. LE normally uses syslinux (legacy) or grub2 (EFI) bootloaders so there are two configs (syslinux.cfg and grub.cfg) that describe the boot= (boot files) and disk= (storage) using either UUID (default) or disk label or /dev/device. I have no experience of rEFInd so have no idea what EFI configs it requires, but all bootloaders are similar so you can use the grub/syslinux configs for prior-art.
NB: This is an unsupported configuration; meaning if it goes wrong it is not our problem to solve. There is no interest in trying to implement support for installing to a single partition because users with this config have multiple bootloader options to choose from and the risk of touching partitions and trashing someone's existing Windows/Linux/etc. install that contains pics of their kids/pets/dead-relatives etc. is high. Simply not supporting it and forcing users to install LE to an entire disk is simple, long-proven, and avoids the risk and irate user support issues that follow when things inevitably fcuk up.
kapqa RK3588/RK3576 use a newer variant of the DesignWare HDMI hardware. It's probably not that hard to add pass-through support, but I'm not aware of anyone working on it at the moment. I'm sure it will happen, but not immediately.
There are lots of simple ways to copy/paste (SMB or SFTP) or upload (File-Browser add-on) or copy from USB (Kodi file manager) to move content to the local /storage of an SBC board.
I'm not aware of any add-ons that source media content from the Internet Archive (Games, but not media). If you are seeking other sources of free media, there's a load of non-pirate video add-ons for Kodi in the Kodi repo. If you're hinting towards the pirate kind then you are asking the wrong audience as that kind of discussion is not at all welcome in this forum.
It's the first I hear of it, but unless there's a core packaging issue (our problem to fix) we normally deflect widevine discussion into the Kodi forums as that's where inputstream.adaptive and all the add-ons dependent on IA and widevine have support threads for their issues.
But is it correct?
I know my instructions were correct; it's entirely up to you to follow them. I couldn't give a fcuk whether some CrapGPT tool also agrees with them and I'm not interested in reading walls of AI generated text. Experimenting is free. Go experiment.
The "normal" problem with projectors is limited-range vs full-range colourspace, but the "flashed in rainbow-like colour" description doesn't fit the normal comment of colours looking a bit washed out. So assuming you have removed and reseated cables, to triage anything you need to provide some pictures and tell us what the projector indicates is being sent on the HDMI connection, e.g. the resolution, bi-depth, colourspace, etc. - and put Kodi into debug mode with a current LE13 nightly image and run "pastekodi" then share the log URL. The log probably won't tell us anything useful (same as the mode output you shared) but you never know.
If the current HDMI cables and/or internal firmware (most NUC like devices use an internal DP to HDMI adapter and this has some firmware) have issues with 4K60 but the Kodi GUI (desktop) defaults to 4K60 and "adjust refresh" is not used and/or 1080p modes are not whitelisted, Kodi will upscale everything to 4K60 to compound the problem. It's also possible to have bandwidth issues with uncertified HDMI cables. Have a read of https://wiki.libreelec.tv/configuration/4k-hdr for explanations of recommended config.
To force 1080p desktop, run tail /sys/class/drm/*/status to understand what connector type/number is in active use. Assuming HDMI-A-1, then add video=HDMI-A-1:1920x1080M@60D to kernel boot params; which will be either the syslinux.cfg file in the root folder of the USB (legacy boot) or EFI/BOOT/grub.cfg on the USB (EFI boot). If the active connector is not HDMI-A-1 adjust the video= command accordingly. This forces the initial kernel DRM state to 1080p@60 and not 4K where it probably defaults to 4K60.
NB: Some users solve 4K60 issues by using an external DP to HDMI adaptor instead of the HDMI ports on the box. This is not always a guarantee of success as most adaptors are cheap and can also have rubbish firmware; but unlike the internal one soldered to the motherboard, you can order a bunch from Amazon and experiment until you find one that plays nice.
The written style of your posts is hard to follow; too much "conversation" and not enough facts, and lots of broken text and missing punctuation. NB: We are used to reading Google translated copy/pasted text. You are welcome to post the original German text to your posts (in addition to the English translation). If you want to post only in German perhaps post in the kodinerds forum.
I'll keep an eye on the progress of Rockchip and the TV boxes based on that chip.
There are currently no device-tree files for modern-ish Rockchip based Android set-top boxes in the upstream kernel, and after years of slog attempting support for Android boxes on Amlogic hardware the project staff have no real interest or plans to repeat that experience on Rockchip hardware. In short, even if support for current/recent Rockchip SoC(s) becomes brilliant, you should have low expectations of finding an LE image for the box.
I'm a firm believer in "if it works, don't fix it" so if all is good there is no burning need to update frequently. That said, with a nightly build things like add-ons are in a development repo, so at some future point when Kodi moves from Alpha to Beta to release that dev repo will initially stop being updated, and later will be nuked to free up disk space; so once things move to release it's probably a good idea to bump. Other users have OCD about running the latest nightly, but while we are generally pretty good at avoiding any bugs and problems, these are nightlies so everyone runs them at their own risk.