Posts by chewitt

Quote from johnny depp

I first solved the problem with PVR by going back to the version

That's a "workaround" for the problem not a "fix" so if you never want the issue addressed, do that.

imhotep Please update using https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.2.tar then paste a log URL. If audio is now working? I'll send the fix patch https://github.com/chewitt/linux/…f031886c6e14cc2 to the kernel mailing list. I prefer that you test my image not _emanuel_ dtb files, thanks.

Profiles *should* be a platform neutral capability, but when it comes to saving things you need to interact with the filesystem and that means different platform-specific code paths come into play (Windows filesystems are not the same as Linux ones). It would be useful to test Kodi on another Linux distro and prove it fails the same way.

I won't be suprised if there's a bug in profiles as it's a neglected/unloved and not well maintained part of Kodi's vast codebase. It is known to be imperfect and need work, but until someone volunteers themselves for the task that's how it remains. It's best you post the bug report in Kodi forums as it won't be an LE specific issue and it's not something LE can fix.

Quote from grackle

Question: Will LibreELEC on a pi5 always fall back to HDR10 when playing Dolby Vision / HDR10+ videos?

No, because it depends on how the media was created?

This thread starts off on a different topic but then discusses a bunch of the technical detail related to HDR/HDR10/HDR10+/DV and might help: HDMI Full v Limited Range issues on RPi 5

Please (re)post the PVR issue in the Kodi forum. Provide English text (Deepl) and the original German text to ensure the context is correctly understood (the main developer who needs to read it is German).

Kodi has some changes for speaker placement markings. The presentation will probably correct itself over the next couple of weeks as the bugs are ironed out. Ignore that when posting in the Kodi forum - focus on the main issue.

Quote from VLouis

These machines usually are connected to internet

That's not correct. Most machines are in a home LAN behind a NAT router so unless the user explicitly port-fortwards or configures a VPN which results in the device having a secondary (external) IP address they are not exposed. Only a tiny percentage of our active userbase have devices exposed. I periodically check shodan scan results and the number of exposed systems is small, stable, and has been slowly declining over time.

"You can please some of the people all of the time, and you can please all of the people some of the time, but you can't please all of the people all of the time” ..

popcornmix AFAIK it's hard-coded? .. or is there a way?

Devices need to use passwords when connecting and/or reauthenticating to the network. This happens in normal use. It happens a lot more frequently when signal/connectivity is poor; and RPi boards generally have poor(er) connectivity before we place them into cases that reduce it further. So the short answer is "nobody knows" (could be any and all of the items you've listed) but if the issues reduce when moving boxes closer to the router, it's probably the normal issues seen with RPi boards, and the solution(s) are moving things closer, using an external wifi dongle with better connectivity, using ethernet instead of wifi, etc. etc.

Quote from Mayoru

Why could I not add systemd-journald-remote as addon?

If you're volunteering to code it and submit it to our repo, that's great. Otherwise it doesn't exist.

Changes are merged so should show up in the repo in the next 24h.

EXT4 is considered reliable and Ubuntu defaults will have formatted the drives appropriately for normal use like LE, and while Kodi crashes can corrupt files in the filesystem, esp. databases which Kodi is responsible for managing, they should not cause corruption to the filesystem itself. This means filesystem errors in the system log are more likely to be the result of power issues, i.e. sudden power loss, or issues with the physical disk media.

If you are lucky it's minor corruption and running fsck against unmounted drives will fix things. If you're less lucky the physical drives are okay but the filesystem is properly messed up and needs a total rebuild. If you're properly unlucky there's physical media damage to the drives. These days physical media damage is rare unless some form of physical shock is also involved, but it's not completely impossible. Failures also follow a bell curve: if the drive is going to fail it's more likely to be when the drive is still very new, or years later when it's very old. Failure rates often correlate to the manufacturing batch of the drives too, so the ideal scenario when purchasing a set of disks is to acquire disks from a variety of different batches not all drives from the same batch.

The only way to find out is trying to fsck, or trying to reformat and rebuild. Beware that if formatting, the default quick format done by most tools may not find physical media issues. That kind of thing is normally only found by trying to 'zero' the drive by writing to all sectors (also rather long and boring).

Quote from Mayoru

What should I consider? How should I configure it?

The need is somewhat moot because LE runs the core OS from a virtual filesystem in RAM on all boards with 1GB+ RAM so writing data to the journal is not writing constantly to the SD card like a standard Linux distro.

To configure systemd-journald-remote you'll first need to compile a custom LE image that builds systemd with journald-remote support, and copy the required binaries and service files into the image, as we don't currently do that.

The easier option will be to install the rsyslog add-on from the LE repo and use that to send logs to the NAS. I've never personally played around with it, but it exists and last time we broke it people complained. On that basis I assume it's used and working; else we'd be complained to again.

As the saying goes: "past performance does not guarantee future performance" but I've been running LE13 nightlies for a year or more (albeit on an RPi5 not RPi2) without drama.

Download the relevant nightly file to /storage/.update and reboot. If you want to hedge your bets take a backup first as Kodi only handles upgrades not downgrades.

There's a script to detect upstream changes and bump the add-ons. Sometimes garbear sends us a pull-request. Other times we run it ourselves; but these things get overlooked sometimes.

Ping heitbaum

IR remote details are defined in device-tree and (no surprise) the N2 dtb defines the Odroid remote not the Dreambox one. It can be overriden in a custom IR map file (there's a wiki article on that).

The N2 dtb working proves there's no underlying kernel issue. The issue will be a difference between the actual hardware and how that hardware is currently described in device-tree. As the vendor kernel (which we have a device-tree file for) is rather different to the modern upstream kernel and I've never seen a Dreambox board we're reduced to guesswork and playing "spot the difference" with dtb files that work/don't-work. In this respect the N2 isn't so helpful as it isn't based on the W400 reference design and has a large number of differences.

To narrow the field, please try other "meson-g12b" device-tree files and flag if any have working audio?