The fix is not done "in GBM" .. the fix is done in the RPi video driver, and the Intel driver, and the AMD driver, and the Amlogic driver, and the Rockchip driver, and the Allwinner driver. That's rather a lot of very complicated low-level driver work and the reason why it hasn't already been done and isn't likely to happen. The possibility of an RPi4 only fix is marginally higher, because at least one of the RPi Foundation devs has a personal interest in 3D support. However, progress probably requires him to have lots of rainy-days with low workload in the office or a long convalesence at home with too much free time and an itch to scratch; neither scenario is that likely.
Posts by chewitt
-
-
Source too slow means a lack of bandwidth in the network or the NAS/Server device hosting files being unable to stream the file fast enough. I see this occasionally with very large ISO rips that I've made (70-80GB size) but it clears after 5-10 seconds. It can also show up if the server is trying to transcode content on the fly and not quite keeping up .. which I occasionally see when using Plex as the back-end server (with the Plex client add-on in Kodi).
The "hdmi_enable_4kp60" option is rarely needed and causes much higher current draw on the PSU and will need an HDMI cable certified for 4K60. Cheap(er) cables will often give blank screens. Under-spec PSUs can do the same. Practically all media is [email protected] or 4K30, only GoPro files and content people have deliberately encoded in 4K60 requires it. Most users do not need it (which is why it's forced as a default).
I don't use DLNA and have never used Jellyfin, but I occasionally use Plex and it works fine. If you are using WiFi .. that's probably the cause of all playback issues. Connect a cable and test again. WiFi is rubbish for streaming media and that's a near-universal rule and nothing specific to RPi4, although RPi4 having no external antenna and being often installed in a nice shiny metal case doesn't help.
-
On paper RPi4 is missing some hardware codecs and has less CPU grunt in comparison to the Intel device. In practice the upstream support for older Intel GPUs has some rough edges and the initial HDR support available in LE 11.0 is less complete than RPi4 currently has, and the missing codecs are often non-criticial, e.g. no VP9 just means YouTube uses H264 instead. I'm not sure a 5-year old 7th Gen Intel device would tempt me too much. I'm also a believer in "if it works, don't fix it" so unless there's a really compelling argument I'd stick with the RPi4.
-
I'm asking because I'd hate to export the database, transfer file to a new disk, reload everything and loose the adjustments.
As long as you aren't changing the 'sources' configuration (so paths remain the same) you can simply copy/move the latest DB files to the new install. There's no need to export and reimport the DB, and this preserves all settings saved to the DB.
-
The LE installer installs syslinux as the bootloader and creates two EXT4 partitions in a GPT scheme (1= 512MB and 2 = remaining space). Once in a while we see BIOS that wants to see an MBR scheme with a FAT first partition, or that doesn't like syslinux but works fine with grub (which is what Ubuntu uses) and I'd make an educated guess it's the latter scenario. So boot into Ubuntu on a LiveUSB stick, create the partitions on the emmc storage, install grub and create the required boot/menu entry, and copy the SYSTEM/KERNEL files over to the first partition. That's all our installer does. NB: There are some grub files on our installer USB to crib the menu entry from, as we use grub for systems that need to have a 32-bit boot environment. It seems yours is 64-bit though, and we use syslinux for that.
-
Your WiFi passphrase is a passphrase not a key so entering it over and over won't achieve anything. This is probably something related to crypto in the kernel and the change to IWD. At the moment "it's a known problem" but how to triage/diagnose the issue is not known and there is no solution. To be continued..
-
It probably requires the RTL8189 WiFi driver which is not available in the upstream kernel and LE will not be adding the vendor driver to the core image; we have a long-standing policy of not adding more downstream drivers that typically break with every kernel bump. That said, the driver is currently included in my own fork: https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar
I make no promises that the driver will remain in my images. If (as is normally the case) a kernel bump breaks it I will probably drop it.
-
I'm not aware that RK hardware supports 10-bit output at the moment.
-
It's the first time I read a report of "greenish diagonal stripes" so hard to comment. It sounds like the TV falsely advertising colour modes that don't really exist or bad HDMI cables. In the past some colour issues have been resolved by installing to emmc which uses upstream u-boot not the Amlogic vendor one. That issue wasn't on WP2, but could conceivably be similar. No real idea though
There are no drivers for the internal DVB tuners. It's quite simple to compile the tuner/demod drivers, but that's only 2/3 of the puzzle. There is no V4L2 demux to link everything together, and that's something non-trivial to create.
-
[RFE] Include dm-mod.ko by default. · Issue #5905 · LibreELEC/LibreELEC.tvDescribe This is actually a feature request. With Ventoy we can just copy the LibreELEC.img to the USB drive and directly boot it. It's very convenient for…github.com
Ventoy depends on something we don't include and have deliberately avoided adding for the last decade. From our side; they broke support that we don't use or need or rely upon, and it's their responsibility to un-break it.
-
Addind the driver package.mk is not enough to build the driver. You also need to mod the project or device 'options' file to build the driver package. You may also need to add/pick firmware from linux-firmware.
-
We don't do anything unusual with SD card creation/formatting .. so
-
You are in the wrong forum for assistance with pirate download tools. Goodbye.
-
Not possible because VNC requires a Windowing system and in the GBM/V4L2 world we run directly on the DRM framebuffer without any kind of Windowing environment. You can crossgrade to the Generic-Legacy image which still uses Xorg, but no HDR there (if using kit that can support that). This is not technically a bug (everything working as designed) and it will be non-trivial to 'fix' so I wouldn't expect to see any progress anytime soon.
-
Use the code in this repo at this commit: https://github.com/chewitt/ssv605…d6bc33c6ce33b1f - newer commits will break the driver. The driver is crap so if it compiles you're lucky. It will not run on anything newer than Amlogic 3.14 or maybe 4.9 vendor kernels. Don't even think about asking for support!
-
thanks for great release, only thing I miss now is non-crazy white subtitles for hdr on rpi4, any progress on that?
No progress. It's not something simple to fix so won't be a quick one.
-
"getedid create" not "get edit create" .. try again
-
Just use the "box" image and run from SD card.