Posts by chewitt

I can highly recommend a "Flirc" USB dongle.

If the server is using some random port and not listening on 51820 how do you expect client and server to connect?

NB: ConnMan will create the connection and wg0 interface regardless of what you put in the files (as long as the content is syntactically valid) but the ends need to have basic connectivity else the data doesn't flow.

RPi4 1GB = For an LE only setup with 1080p but not 4K media. RPi4 2GB = For 1080p/4K in an LE only configuration. RPi4 4GB/8GB = For people that want to run additional services, i.e. Docker containers in the background, or perhaps want to swap SD cards and boot a full Linux desktop OS that benefits from more RAM on the board.

I'd expect Sony to do a half-competent job of supporting ATV9 on hardware that will be technically equivalent or superior to an RPi4 so the playback performance on the TV (using Kodi) shouldn't be bad and the TV likely supports more codecs etc. - and doesn't require another box purchase so I'd always recommend you explore the limits of that before adding something more. That said, all 'smart' TVs want to monitor your media consumption habits to provide an advertising opportunity or additional revenue stream for Sony. LE offers a potentially more private way to consume the same media through Kodi. If that appeals, or you invitably reach the point where Sony stopped supporting the OS and providing updates, running an RPi4 (or maybe RPi5 by then) via LE will be an attractive idea. Again, I doubt the RPi4 can beat the TV on playback quality unless Sony dropped the ball on Android.

Quote from exboyracer

The problem started when I tried to install Seren on one of them, which failed due to a failure to install dependencies.

If you're expecting sympathy or support, you're in the wrong forum. Have a nice day.

Official:Forum rules/Banned add-ons - Official Kodi Wiki

No description of the hardware used. No debug logs to corroborate anything you've said. No pics to illustrate what you're talking about when it's unlcear. Summary:

https://github.com/LibreELEC/LibreELEC.tv/pull/7122 <= if this gets merged it should be in LE11 nightlies and future releases

Any Realtek vendor driver will NOT be accepted into our codebase (this one has already been submitted and refused). Once the upstream patches I've flagged are accepted into the kernel we will happily backport the driver onto whatever kerrnel we're working with at the time (if technically possible) .. but not before.

Run "journalctl | paste" a couple of minutes after a slow boot/online experience, and then repeat after a quick boot/online experience, and then share the URLs so we can maybe spot what the difference is and where the delay comes from.

Quote from PhoenixBG

Any progress on my problem? Did you manage to look?

I looked quickly and didn't see anything. I'm very short on time at the moment to look seriously..

Kernel modules are compiled for a specific kernel version, and unless you are running exactly that version the 'version magic' doesn't align and the module will not load. If you are using 10.0.3 we've bumped the kernel since I built it, and it won't work. If you're using 10.0.2 (which was latest when I built it) it will probably work. I have no plan/interest in building it again (before people ask/demand).

Linux error codes are standardised and -5 means EIO (Error I/O). I'm not sure knowing that will advance your situation though. If the issue is consistent over multiple distros it could be indicating a hardware issue; or everyone has the same incompatible firmware. Have you tried to contact MyGiga support?

Quote from dootsie5times

Coreelec has a file rtl8822bu-aml which works with this adapter. Why does Coreelec have it and Libreelec does not?

Because CE has a kernel that never changes version (as it's the only one they can use) so they hack the driver to work once, and then never have to touch it again. In LE we bump the kernel constantly, and that means all these shitty out-of-tree Realtek drivers break, constantly. Over time we gave up on them and now simply refuse to add more. Fortunately in recent times Realtek has gotten better at submitting their drivers to the kernel, but they breed new chipsets faster than the process of submitting support to the kernel.

Quote from noggin

Assuming you're looking 19.2E Astra 1 then

1) and 2) are h.264 (aka 'MPEG4') compression - with 1. being 720p50 "progressive' and 2. being 1080i25 (aka 1080/50i) "interlaced"

3) is 576i25 (aka 576/50i) "interlaced" using MPEG2 compression.

So it sounds like there are issues with both deinterlacing and MPEG2 decoding?

The upstream Amlogic VDEC currently has no support for hardware interlacing (we force software yadif) and you need to have 50/59.94/60 Hz modes enabled in the whitelist and 25/29.97/30 Hz modes disabled; this combination allows Kodi to render each interlaced half-frame as a whole progressive frame. There is no support for hardware MPEG2 decoding but Kodi will software decode.

I'd guess that it doesn't reset the card voltage correctly during reboot, which means the card isn't detected and thus you see the "cannot find something to boot" text on the screen. Can you do some experiments with other SD cards? - ideally something old/cheap/slow that doesn't need the voltage switch.

NB: This is also a reason to test the image installed on eMMC storage; there's no voltage switch there.

Yes, change the servers associated with a specific connection profile using "connmanctl" .. Google for documentation.

Artefacts aren't something we can do much about. Handling them better is mostly a combination of the codecs, which can surely be improved but we struggle to find anyone to do the work, and the firmware which is sadly closed source.

Intel were the source of the initial HDR support in the kernel, and Team Kodi helped them to get code merged. Over time lots of ARM SoC devices then added support for the required DRM/KMS plumbing too. Substantial Allwinner support and a moderate amount of Rockchip support for media codecs and DRM has been developed or refined by our staff developers, or in collaboration (behind the scenes) with professional developers working on Linux media support (folks from Collabora, etc.). Over time we've accumulated many of the main V4L2 'name' developers into our Slack instance; we support a broad range of V4L2 using hardware and we have a staff with lots of test devices, test media, and experience of spotting and intelligently reporting quirks in media performance and playback - so we gain from their efforts, and they gain from our testing and inputs. RPi Foundation has an excellent team of in-house staff working on firmware and kernel drivers, and both LE and Team Kodi have a long history of working closely with them to ensure RPi has great media support. Their support to us is the A1++ benchmark that other vendors are measured against (none come close). The RPi foundation's approach to RPi4 has been different to older devices; mainly as lots has been learned since 2012, but LE/Kodi have been instrumental in forcing them to drop proprietary codecs and embrace the GBM/V4L2 world and push everything "upstream" to benefit more distros and the wider Linux community. It's taken time to get things into decent shape, and while RPi4 is not perfect (not all codecs supported, etc.) it's still the best performing device for the average LE user to play with. Enjoy