Posts by chewitt

Set the Kodi SMB client to min/max SMBv1 and restart Kodi and the NAS shares should be visible. There is no change in this since v9.2.6.

I wouldn't say dead, but I'm on hiatus for a while now since I don't have much free time for kerenel fiddling (busy in the real-world) and vdec development has been stalled for two years, so from a Kodi perspective there are no improvements to be excited about. There is still ongoing work on the Amlogic SOC platform overall.. the core OS is solid and increasingly used by industrial use, desktop and some of the retro gaming distros; but all of those have primary use-cases that do not depend on multimedia capabilities in the same way LE/Kodi does.

Until you read something about profile crashing being fixed, you can assume it is not fixed and you can stop posting "it's not fixed" comments to this thread. We know it is not resolved and the comments are not motivational.

Quote from morfik

But still I think the e2fsprogs package should be present in the default image as LibreELEC supports EXT4 filesystem. It's just 1,5M uncompressed (615K compressed).

This is the first time I have any memory of someone demanding (let along actually needing) defrag tools in LE and I've been hanging around the project and its forerunner for nearly a decade. On that basis alone I'm confident defrag tools are not a must-have thing for our users. You also fundementally mistunderstand how the team thinks about adding unnecessary cruft into our images. Adding 200Kb of new files causes huge debate. Adding 1.5MB for something withiout large-scale user demand .. isn't going to happen. Even if it was needed the approach we'd follow would be to bundle up a collection of things into a "disk-tools" add-on that the minority who need them could install (see the current btrfs-tools add-on as an example).

Quote from 0ldn3rd

I read in a news, that with Kodi19 and LE10 it will be possibel to get HDR....

On RPi4 and some other ARM devices which now support it. The x86 world is still a bit behind..

Pi Foundation folks are currently focussed on finishing the 10/12-bit video and 4K60 work. This will firm up the kernel/DRM side of the puzzle and allow some ffmpeg cleanup, which needs to happen before more complication (with deinterlace) is added. It's vacation season so all of the above is running about 3/4 speed right now. IMHO the current software deinterlace capability is quite usable (not perfect, but usable).

Content status tracking is done in Library based views (Movies/TV Shows) using content scraped into the Library. Or are you using the non-Library "Videos" view?

Quote from Niceguy

So this is Version is 9.97.1 Beta and not 10.0 Stable ?

RC = Release Candidate. More stable than a beta, but not the 10.0.0 release either (hence not called beta, or stable). Generic is pretty stable though. The remaining WIP bits are related to other platforms (mostly RPi4).

Run "journalctl | paste" and "pastekodi" after booting (and doing whatever is needed with network config) and share the two URLs that are generated. Then reboot and repeat the process, share the URLs again.

Nothing has been explicitly done to fix it, so I doubt it.

Wrappers aren't the right approach because the level of optimisation required for functional 4K pipelines on ARM hardware is high and you'll always end up needing to write efficient native drivers. You can bodge 1080p, but RAM speed and bandwidth become big factors with 4K. The tertiary challenge with V4L2 is that it's all super new and still in a lot of flux; we're still some way from making a serious effort to upstream our current working code to ffmpeg because lots of things are still being experimented on.

Quote from dhymi

Eu gostaria de saber também, no meu caso quero modificar o libreelec pra no lugar de rodar o kodi, rodar outro apk na hora que ligar, isso é possível?

Not possible. Não é possivel.

Practically all 4K content is HEVC (or VP9) encoded and nVidia never added support for either to their Linux drivers, hence the CPU is working overtime to play back 4K content. AMD and Intel have both invested time/effort in their drivers (and both use Kodi as a reference media app) so support is generally good and the main Linux challenge is new chips needing bleeding edge kernels that take a while to stabilise. nVidia continues to be a Linux pariah and future use in LE once we drop X11 support (sooner than later) is not guaranteed. Stats show the number of nVidia users continues to decline and most of them have older cards. These days most people have moved from homebrew boxes to NUC-like devices with a server/NAS for media in the network. Most of those devices are fanless (or quiet enough) and the client/server setup makes it easier and cheaper to upgrade the client device as media tastes evolve over time. Perhaps convert the current box to a server and partner it with an RPi4?

Please retest with a current LE10 nightly. Aside from minor tinkering with widevine support LE9.2 is no longer in development.

Clean install the current nightly from Index of / with no 4K60 configuration and prove things work normally and the RPi4 can see 4K (up to 30) modes - right now it is only seeing 1080p. That suggests bad or inadequate/uncertified HDMI cables (or broken EDID from the TV) or using the wrong HDMI port on the TV. Note that LE defaults to 1080@60 GUI even if the TV supports 4K playback. Rendering the GUI is about CPU performance, it is not hardware accelerated like 4K video, so the GUI will be noticeably slower if you force it to run at 4K. You can still whitelist 4K modes for playback and Kodi will switch to 4K when required. Also note that practically all 4K media is [email protected]/25/30 so in most cases, users do not require 4K60 to be forced.

If vendor boot firmware is present on emmc the box will always boot from it, so to freely experiment with other boot firmware(s) from an SD card or USB stick you will need to completely erase emmc. If the goal is to run the dtech image you should focus on finding a replcement "vendor" u-boot. NB: the u-boot.bin.sd.bin files in my share (in case that's what you found) are mainline u-boot variants and might boot the box but will not greatly help in any mission involving 3.14 vendor kernels. Start by sharing the "strange characters and letters/numbers" seen via UART via pastebin so people can understand what the current boot-state of the device is.

I'm not sure what the issue is (no logs are provided which might give clues) but using autostart.sh should never be preferred over system.d, as the later provides better control over when things are executed.