Posts by Wolfpig

It is not really quite assuring to give an "example" with a filename which is usually used on torrent sites to say that it is legitimate content.

I currently have 2 4k Movies (im ripping my dvd/blu ray collection since february...and im still not done...uhd will come last as that will take the most time) with DV (the hdr type while playing is shown as dolby vision in the media info tab) which i ripped from my own discs and converted with handbrake.

So i guess handbrake adds a kodi compatible layer into it. (or better compatible hdr info into the container)

A non re-encoded rip looks fine too.

So maybe you should do that stuff yourself instead of loading it from third party sources?

Thanks guys.

Tried it out and it seems to be working as intended with the extra line.

Quote from popcornmix

I'm not aware of any regression.

If you could identify the exact nightly build where the performance regression started, then the changes there can be investigated.

Edit: We are suspecting https://github.com/LibreELEC/LibreELEC.tv/pull/10258

If it is still needed i can try out the 4 builds between those i saw that happening, but most likely wont be able today, and more over the weekend

Quote from chewitt

The (bad) log shows two videos, one HEVC, one H264. To confirm, the video is choppy with both videos?

As far as i noticed, it is only on the second one, i assume it is the h264 one. (did make pictures, and the first has almost no change in cpu usage)

Not sure as i not tested that, but i think the 1080p videos all ran fine (used the 25th build 1-2

days before i encountered the issue).

Hi.

Im not quite sure if it is a bug, or if some settings in some file got changed so i ask first before try to create logs.

I noticed that with the builds which got released after 20250719-47e72e0 (not sure which as the next one i tried was 20250725-f0482de where i noticed it) the playback of 4k files is choppy as the cpu usage seems to be loaded at around 90-100%, while on the build from the 19 and prior the files get played fluid with only around 20-40% cpu usage.

I did not change anything on the settings

Log from the build where stuff runs fine: https://paste.libreelec.tv/enough-anemone.log

Log from current build (20250731-ee7a2e6.img.gz) : https://paste.libreelec.tv/settling-pipefish.log

If only stuff on the settings changed, where would I need to change it that it runs OK on those files again?

Yes, that is the build.

Installed to test and it seems to work as it should.

Just in case tested 2 4k hdr Demos to see if the connection is stable and on speed and those worked fine too.

So the issue seems to be solved for know.

Quote from Da Flex

The WiFi key was wrong at the first attempt to connect, but at the second attempt it worked:

Code

Oct 08 17:44:37.351915 LibreELEC connmand[631]: Interface wlan0 [ wifi ] state is ready
Oct 08 17:44:37.352030 LibreELEC connmand[631]: Interface wlan0 [ wifi ] is the default

This message only appears once, right before the second attempt:

Code

Oct 08 17:44:31.629219 LibreELEC iwd[1001]: hardware_rekey not supported
Oct 08 17:44:31.629788 LibreELEC iwd[1001]: event: state, old: connecting, new: connected

So I think kszaq is right, and it's a bug at iwd.

As i still have no idea what it is, and as i probably cant change that by myself.....

BTW: As i looked today a bit further

a) the working nightly is connecting correctly with WPA2 (not really a surprise if it does not support wpa3)

b) the non working nightly only sets the Wireless state to ready, it does neither receive the internal ip from the router and does not see the router as the DNS source (the field there is kept blank, which probably also the reason why it sets the connection state or what it was to auto instead dhcp)

c) manually setting the ip, dns etc. makes no difference

As i have no real problems with the running nightly, i will keep that for a bit and see if that problem might get squished out in the near future.

Would i need to report that as a possible bug somewhere?

Quote from Da Flex

This is from the "working" log:

Code

Oct 08 17:44:20.146869 LibreELEC connmand[631]: Interface wlan0 [ wifi ] error "invalid-key"
Oct 08 17:44:20.146905 LibreELEC connmand[631]: Interface wlan0 [ wifi ] state is failure

Seems like you always had a wrong WiFi configuration. Check your keys.

I will check but.....what key are we talking exactly from?

And why is the connection running without issues if there is something "wrong" with it?

Quote from kszaq

One more thing: 56c531c is the first non-working build? If it stopped working in 4b9746e, it would be much easier to blame the iwd update.

Cant tell that for sure, as i usually only update once a week around friday, and the fist build i had that happen was either the one from the 10/25 or 10/29 (deleted it from my NAS, so that i not accidentally revert to an "unstable" build if needed)

But if i understand correctly, the connection issue is mainly because of WPA3.

Will check that too, but im quite sure that i never explicitly set the WPA standard which should be used (router should be set to WPA2/3 as network devices mostly are mixed here) so the kodi/libreelec install had choosen that by itself.

Quote from Da Flex

Wolfpig Sometimes WiFi quality changes,

If it changes from one Libreelc build to the other, making it completely unusable that still would be a not intended behavior.

Log created with the gbm shell on the latest nightly build (2024-11-03) (as no network is available)

Comparison log from the fully working nightly build 2024-10-20

https://paste.libreelec.tv/allowed-gorilla.log

BTW: What i noticed right now while testing, other that it takes the not working build 2-3 times so long to get a connection (even if it still wont believe that a network connection exists), the connection type stays on auto on the non working builds, while it is set (correctly?) to dhcp on the older working build.

Forgot to check if the fixed IP Adress i set in my router for my pi is used on the failure, or of it is using some other random one

I have issues too with the Wireless connection since that build on pi5.

What I noticed.

A) it takes unusually long that the connection (Wlan 5ghz) gets ready and

B) even when it is connected (in the libreelec settings) the system tells me that no connection exists.

Quote from DeShizz

Thanks Da Flex!

Original post with edits follows below:


This puzzled me for some time until I switched the TV's HDMI range to Full. This solved the issue almost immediately and was a night and day difference - suddenly I could see all the detail I had been missing. The problem was, that normal, non-HDR content now appeared brightened and washed out, so one step forward, one step back.

Only quoting that part, as most of the rest is not relevant on that matter.

To keep it simple.

The TV is not creating the same level of brightness/saturation/color on sdr content when that is displayed with hdr as it most likely supports only a low level hdr on sdr content (mostly happens on lcd/led screens, oleds are far better to get a good sdr on hdr picture).

So the problem with the washed out colors is normal and might be lessend by adjusting stuff like brightness when it is displayed (but would also affect hdr as you change it in that mode).

You might search the net if people might have posted settings guides for that TV which you might like to try.

BTW. Switching the color range to full was needed as hdr formats like dolby vision only work with the enhanced color space.

This might not help you, but if you have still trouble, on the current nightly (b5ce01c) the hevc files I have tried (some uhd hdr promo movies) run fine.... the hevc decoder which is used seems to be even using a hardware decoding. (at least the info says so).

What I remember right now, on the pi4 I had the same with certain files, but I think that was more as the persons who made that used some uncommon formats like hevc 8bit or so which made problems with hw decoding.

Dont think I have those files still here, otherwise I would check if those still would make trouble

I can test that.

Probably will have an answer in a few days if it made a difference or not.

What i forgot to mention at the time (and postings seem to not editable).

If that happens i can sometimes switch the hdmi input in the avr to some other port, wait a few seconds, swiotch back and the picture gets shown, other times i need to do a hard reset (probably a reboot would work too if i had some other control at hand which can cause that).

And here is a log.....no idea if it is any help at all, as that got created after a reboot (which i needed to do after a reboot as the Wireless connection was not active after the reboot when the detection problem happend..without debug log active) when that happend, and no idea if it internally always acts the same at that part (not even sure if it is completely a libreelec/kodi problem, as i do not know at which point at boot the hdmi detection kicks in)

https://paste.libreelec.tv/firm-ghoul.log

Hi.

I recently switched to a pi5 (pi in use before) and have a small problem.

Everything runs fine, but for some reason when i power the pi on often it wont display a picture when the corresponding hdmi port gets automatically switched by the connected devices. (sometimes even if everything is already set to the correct ones)

The pi is connected to an AVR and that to the TV....TV & AVR are already turned on

I also already know why it happens.

For some reason the physical hdmi port (which can be set in the cec plugin options) gets switched to a random port number (most of the time 2020, 2200 or something) and sometimes the detected (AVR/TV becomes a playback device or so) device gets switched too. As this has never happend before at any point in the last 5 years with the pi4 (or the pi3 i used a while before that) so im not sure where the problem is.

Things i already tried.

Creating an custom edid through the command shell.

Tried different options in the cec plugin (that is why i know that everything works as intended when the physical port is the same as the set hdmi port....it is port 2 on the AVR btw.)

So my question is, can i fix that behavior in some way?

Or is it an issue with the libreelec software (or the cec plugin) and i need to report it as a bug and hope it gets resolved?