Posts by chewitt

Quote from ApexDE

will this be in LE 12 repo chewitt ?

No because https://github.com/LibreELEC/LibreELEC.tv/pull/9663 remains unmerged (overlooked). Once the correction is pushed to master and the LE12 PR is updated to match I'll merge the PR so the add-on populates to the LE12 repo.

From what I can see with View Mode and Zoom:

Starting from "Normal" mode if you enable "Zoom" mode it starts with "Zoom amount = 1.0" and when you make any change to the amount value the selected mode automatically changes to "Custom" mode. I've zoomed a 4:3/SD letterbox video so the sides are closer to the edge of my 16:9 screen resulting in "Zoom amount = 1.15" and if you toggle between "Normal" and "Custom" modes the zoom value is persistently applied.

However, if I now switch back to "Zoom" the display switches to a mode similar to "Wide zoom" and not the current "Custom" value that I defined. This probably makes sense in the context of not wanting to automatically revert to "Zoom amount = 1.0" when going back to "Zoom" as this would presumably change the "Custom" value automatically too. However, if I now move to change "Zoom amount" the wide zoom mode is shown until the amount value is adjusted; only then the screen switches to the "Custom" amount value. I also note that if I adjust "Zoom amount" back to 1.0 the mode auto-switches back to "Normal" mode again.

This is probably old code and "not a bug" since "code is working as designed" but the design could use improvement. Unless there is some use-case I'm not understanding I think it would be more logical to simply have "Zoom" respect the current "Zoom amount" value defined and eliminate "Custom" mode.

As this is nothing specific to LibreELEC I'd suggest you report this to Kodi developers via their forum or GitHub issues.

Running "getedid create" to capture the EDID data to file will achieve nothing on a system that cannot see the EDID data on the HDMI connection in the first place. You capture <null> to file and force the system to see <null> on every boot.

It's unclear what the issue here is, but given the general lack of user reports about RPi4 boards not seeing EDID, it's unlikely to be a software issue and more likely to be hardware or something specific to this user. Note that RPiOS and LE essentially share the same boot firmware and kernel.

Custom nodes create a new entry point into the Library (using a filter on e.g. source name) but this doesn't change how library views are created from scraped metadata. Kodi has default scrapers for online metadata sources like themoviedb.com, and local sources that provide metadata using a mymoviename.nfo file in the same folder as the mymoviename.mp4 media file.

See: https://kodi.wiki/view/NFO_files for more .nfo info.

NB: If creating .nfo files for all your private movies is a chore, it might be easier to use the "Videos" view instead. This is not library based and allows you to simply browse a filesystem folder tree. Not as fancy, but zero effort.

Quote from osflake

As You Can see HDMI0 and HDMI1 is available.

The image shows "EDID=none" and whatever causes no EDID to be read is the source of your problem as Kodi determines HDMI audio capabilities using EDID data from the HDMI connection at startup. No EDID = No audio.

The config.txt and distroconfig.txt files are full of changes from known-working defaults; although most are #commented out and are legacy items which are no longer supported, there are also other items present which will change behaviour.

In short, this is not the clean install that you were asked to make (it looks like an upgrade from an older LE9 install) and there is so much config mess from you guessing at things that it's not clear what change(s) might be involved. Please go make a true clean install. Unless there is a self-inflicted problem with bad cables or HDMI adaptors (or an Argon case) it should then "just work" like a normal RPi4 install.

https://github.com/xbmc/xbmc/pull/26606 submitted .. if it passes build (it should) I'll merge it tomorrow.

https://github.com/xbmc/xbmc/pull/25700 <= seems to be this issue, which is fixed for K22, but wasn't backported to K21.

The quick fix is to update to a current LE13 nightly image which uses K22. The longer fix is waiting for someone to see if the patch backports onto K21 and then either submit a backport upstream (and then bumping the Kodi version in our LE12 branch) or we can backport the patch direct. I'm not sure there's any plan for another K21 maintenance release. I've been using K22 images for the last year and despite technically being pre-alpha code they've been stable, so I'd probably pick the quick option.

Quote from LoneWolf

I tried a 640 stream and still got the blur for most of the screen (about two third, interestingly the top third works quite well, and below that it blurs).

Please pastebin a Kodi debug log that shows this stream being played.

Quote from LoneWolf

by capture examples you mean screenshots`?

No, a sample of the stream (recording). Something that can be used to replicate the issue.

popcornmix are there hardware iterations of RPi3B+ that need newer firmware than we ship in the LE 9.2.6/8 image?

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

Banned add-ons are installed. No further support.

Quote from LoneWolf

the 3B+ only offers 640x480, 800x600 and the selected 1024x768. I couldn't get it to set higher one, or any in the correct format.

The display pipeline on RPi0/1/2/3 is 1920x1080 maximum and supports a specific set of configurations. The much newer RPi4/5 can handle 4096x2160 max and a wider variety of configurations.

If you can capture/share some examples of the stream we can look deeper.

Quote from marc.bau

Can one of the maintainer recompile the latest TVH 4.3 version available for testing, please???

LE12 has a slightly outdated version. LE13 (nightlies) have 4.3-2375 which is the latest available version.

Quote from fliz

Does the Flirc case impede the wifi signal?

The issue is not the flirc case impeding the signal, it's the generally rubbish WiFi on the board in the first place. It's a compromise for basic functional connectivity not high throughput performance.

Two suggestions:

a) Use an external USB device, the Realtek and Mediatek chipsets used in most of them are now mostly supported in upstream kernels which reduces the lottery of things working or not (still never guaranteed, but things improved a lot).

b) Use a WiFi > Ethernet bridge. I'm often testing devices in locations that aren't near Ethernet so I use some old Apple Airport Express units in bridge mode to get things connected. No drivers needed and they have a decent antenna. Amazon has options for mini/portable bridge units for a similar price as a better external USB WiFi dongle.

Thread renamed and commented to remove the name of the pirate addon. No support for pirates in this forum.

I'm fuzzy on the precise details in some areas ( popcornmix can probably describe things more accurately) but I think this is broadly what's happening:

The H264 hardware decoder supports a maximum 1920x1080 resolution on both boards (RPi4 inherited the same IP block as RPi3) and you are trying to play 2560x1440 resolution media on a 1024x768 monitor. As hardware decoding cannot be used because the resolution is too large the boards fall back to software decoding + resizing to match the output resolution + adjusting from 15fps to 60fps refresh rate (the only easy bit). RPi4 has the CPU grunt for the task so you see output. I'm unsure why RPi3 shows a blank screen where RPi4 shows output, but this is probably due to a capability difference between RPi3 (1080p max) and RPi4 (4K capable) so display pipelines are not equial. Disabling DRMPRIME in Kodi disables hardware decode and changes rendering in the kernel DRM layer; hence you now see something on RPi3 instead of nothing, but I'd guess it's still beyond the capabilities elsewhere in the pipeline so it's not usable output.