Posts by Reddog

Quote from popcornmix

Pretty sure this doesn't come from Kodi. It is likely coming from projector, AVR or splitter.

It depends exactly on how these are connected. Giving a list of hdmi cables connected from device A to device B may help me understand that.

Personally I'd start from the simplest setup (pi connected to projector) and check if that works (without the "Notice") and add the splitter then AVR back in one at a time and see at which point it appears.

Sorry about the false alarm regarding me believing the notice was something coming from Kodi.

You are correct popcornmix, the notice was coming from my AVR for some reason (it's a 4K AVR with all the correct cables). I didn't spot it at first since I have all of my remotes (TV, projector, AVR, RPi5 etc) mapped to a Harmony 525 (an oldie but goodie) and had misplaced the AVR remote - when I found it and pressed the Ok button the notice disappeared and I can watch in 3D.

A problem for me to solve is why a relatively new 4K AVR (with HDMI 2.0 cables) doesn't correctly recognise a 3D signal to pass through from the Pi (fyi: it's Pi to AVR to powered splitter to 2D TV + 3D projector) but I'll try doing as you suggest in your last paragraph.

I know I'm late to the party but this is amazing - many thanks to popcornmix (and Claude) for all of this.

If I think back to the original 3D on a RPi3, I don't believe it did an automatic detection of the 3D signal and I would have to manually change the projector settings for SBS, TAB and FP.

This new incantation will automatically change to the correct 3D format, with one issue that I am 99.9% certain is down to my setup.
I have a splitter that is connected to my AVR and then onto a 2D TV and a 3D projector so I think there is probably some confusion with the EDID from each display?

Even though the projector is showing the correct 3D format I get an error on the screen:

Notice
This TV is not 3D capable.
Please change to 2D signal on your source.

OK

I don't mind having this notice due to my setup but I am unable to remove it. I'm assuming this is coming from le since pressing the projector remote ok button doesn't work but also pressing ok on my le remote doesn't work either. The "Ok" in the notice doesn't look like an ordinary button as well - I can provide a photo if necessary.

Other than my possibly unique issue I once again thank popcornmix for resurrecting 3D - you never know it might catch on this time.

Quote from quickstang

I’ve got nothing. Keep updating to each nightly and still the same issue. Either my media starts then stutters, or it spins like it wants to start then kind of times out. Again, nothing after the nightly build on the 8th works. Revert back and 0 issues.

This is exactly my experience of the issue.

Just a shot in the dark, but can anyone who is having the problem confirm if their NAS nfs server is running NFSv3, which is my case, and that the libnfs update is somehow "favouring" NFSv4?

I appreciate all your responses - it's "good" to see I'm not the only one with the issue.

plingplong I used the systemd mount method a few years ago when the internal NFS method wasn't working for me but I have, up to now, had success with it since then and would have to change my library paths again if I were to move back to systemd. If I find the time I'll do a test with the mount method but I would hope that since a few others were having the same issue then the developers may have a look into it?

Wolfpig I too thought it was something to do with moving ffmpeg from 8.x to 9.0 but a ffmpeg 9.0 build works fine from a local drive.

Hi,

I'm having an issue with playback (blank screen and no audio) from my DNS-323 NAS using NFS on a RPi5.

I've tried the following latest le13 nightly builds:

1) LibreELEC-RPi5.aarch64-13.0-nightly-20260808-7e66d59
2) LibreELEC-RPi5.aarch64-13.0-nightly-20260810-393623d
3) LibreELEC-RPi5.aarch64-13.0-nightly-20260810-46d0580
4) LibreELEC-RPi5.aarch64-13.0-nightly-20260816-9a6f9e3

1) plays as previous builds but there is a problem with dhcp versus manual ip setting *
2) will not play
3) will not play + when updated (copied file to the update folder) some settings reset (regional, whitelist etc.)
4) will not play

* this is a strange one - I have 2 drives in my NAS but one of them reports a network error when I have a manual ip address but works when I set a dhcp ip address. The other drive works with both dhcp and manual ip setting.

wrt my NFS playback issue, this seems to coincide with the libnfs: update to 7.0.0 between builds 1) and 2).

I accept that my NAS is very old (I have had it for over 15 years) but are there any settings I can change to make it compatible with the libnfs update?

Quote from boragthung

What is the current situation using the TVHat with rpi5? There have been problems but I am not sure if they are now resolved or still troublesome.

I'm not sure if you are having the same problems as me but I have noticed the tv picture quality has degraded quite badly recently.

I've been using the Raspberry Pi TV HAT on a Rpi5 for about a year and it had been great - sharing live tv and recordings over 3 tvs.

However over the last month or so (? since I haven't been using it much over the summer) I cannot get a watchable signal on any channel. All connections have remained the same for a year and currently running Tvheadend Server 4.3 version 12.80.3.3 + Tvheadend HTSP Client version 22.7.1.1.
Tvheadend browser shows a SNR of 28dB and signal strength of -58dBm for a typical channel - I don't know what these values were when the picture was good so I'm unsure if they are now too low for an acceptable picture.
As a comparison, my main tv that runs off the same coax from the aerial (via a "Y" connector - I know this is not the best arrangement but it's the same as when the picture was good) shows a signal strength of 90% and signal quality of 100%. I've tried running the aerial coax straight to the TV HAT but the SNR remains the same and signal strength changes by about 1dBm

Any idea to fix this would be appreciated.

p.s. running LE13 latest nightly on the Rpi5

Quote from popcornmix

LE 13 only.

Thanks.

I've been putting off upgrading to le13 because le12 is so stable - hope le13 is the same.

Quote from popcornmix

With latest nightly, you can enable NUMA to get better performance. See numa thread.

Make sure bootloader is updated to latest and set:

SDRAM_BANKLOW=1 (for pi5)

SDRAM_BANKLOW=3 (for pi4)

using using rpi-eeprom-config.

I'm always up for an increase in performance, especially when it's for free!

Does this apply to the latest le12 nightly (LibreELEC-RPi5.aarch64-12.0-nightly-20241114-f000f3c.img.gz) or is it just the latest le13 nightly?

Thanks.

Quote from ian_j

I currently have a Pi 3b running Pi-hole and a Pi 4 running LibreELEC both working fine.

I fancy having a play with a new device and feel like setting up a PVR.

Do I get a Pi 5 and use that for PVR or move everything around?

Plus which USB device(s) would be the best for UK Freeview? Multiple if needed so that I can record more than one program simultaneously.

Why not go for a TV HAT rather than a usb one.

I recently bought the Raspberry Pi TV HAT from Amazon just because it was so cheap at £6.99.

I set up a tvheadend server on the RPi5 in the living room (where the best tv signal strength is) and installed the tvheadend client on a RPi4 in the bedroom and a RPi2 in the kitchen.

All works great.

Of course this would only give you the ability to record one channel at time - or buy 2 since that would still be cheaper than a usb twin tuner.

Quote from chewitt

The most likely explanation is a difference in the performance of the SD cards. I'm using an NVME drive on the RPi5 and it's 25-30 seconds from typing "reboot" to looking at an updated Kodi home screen.

I had assumed the usb sticks I am using to boot le were a similar speed going by the "headline" read/write speeds but now that I've done an actual speed test with "hdparm -t /dev/sda" it appears the usb stick in the RPi4 (Samsung Fit 32gb) is getting towards 2x faster than the one in the RPi5 (Sandisk Ultra Fit 64gb) - 195MB/sec vs. 115MB/sec. As a comparison, the 4tb NVME drive in the RPi5, which is used purely for storage, is 550MB/sec

But would still have assumed the RPi5 should be much faster at decompressing the update file.

Sorry for the time-wasting.

This question may be better asked on the Raspberry Pi forum but I'll try here first.

I generally update my RPi4/2gb & RPi5/4gb every time a new le12 nightly comes out and a while ago observed there was a noticeable difference in the time taken for them to update.

Finally got round to using a stopwatch to check (these are times from when the "Decompressing image file..." message first appears):

RPi4: time to decompress = 27 secs; total time up to the "System reboots now..." message = 40 secs
RPi5: time to decompress = 54 secs; total time up to the "System reboots now..." message = 78 secs

So double the time for a much more powerful cpu - unless I'm missing something glaringly obvious. Double the ram shouldn’t make any difference should it?

I'm not really bothered about waiting for it to update, more curious as to why a RPI5 is so much slower.

p.s. le running on a usb 3.0 stick in both cases (similar read/write times).

Quote from chewitt

If you can share the EDID files from AVR+TV and TV-direct I'll ask the Pi devs to have a closer look. The intermediate one (RPi + AVR only) is expected to not work since there's no TV to pass EDID from so it'll be incomplete.

chewitt Sorry about the delay in replying.

I thought I had saved the edid.bin files for each permutation but I can only find the equivalent .txt files that I stored after doing a edid-decode on each of the .bin files.

Anyway, I have attached the 2 .txt files with the EDID TV-wo AVR.txt being the working one and EDID TV+AVR.txt non-working to see if this is of any help.

EDID TV-wo AVR.txt  EDID TV+AVR.txt

Quote from noggin

Can you play HD Audio (i.e. Dolby True HD, DTS HD MA/HRA) with this set-up (I'm wondering if the TV-only EDID you are using doesn't have flags for the AVR-supported audio that the TV doesn't support ? Or it could be that with modern TVs they do flag support for this because eARC lets them pass it through?)

noggin I have checked all my audio test files and the AVR shows correct output according to the test files (DD, DD TrueHD, DTS, DTSMA) so I believe the TV must flag all the audio options for passthrough.

BallerShotCaller: FYI, I had a similar problem playing some videos through my Onkyo TX-L50 4K AVR with a RPi5/le12.

I was finding that HEVC videos at all resolutions with 24fps would only play audio (surprisingly 4K/60 HDR test videos played fine).

Long, long story short, I first tried getedid create with the full train (RPi5 -> AVR -> Samsung 4K TV) without success.

Next tried removing the TV so only RPi to AVR and did another getedid create. Put back TV but still no good.

Finally tried a direct RPi5 to TV - this worked so did a getedid create, put back the AVR into the train and low and behold I now have all HEVC videos at all resolutions (including 4K with HDR) playing faultlessly.

(off course when doing the getedid thing I rebooted, tried test, did getedid delete, reboot etc.)

It would be interesting for someone in the know to compare the AVR+TV edid vs. AVR only edid vs. TV only edid (i.e. working edid) as I have the files available.

Quote from popcornmix

Okay so that matches:

2024-03-31 (726b493): #8780 kodi-binary-addons: update to latest version

which I believe you are reporting as broken, and the previous build you are reporting as working:

2024-03-30 (ae242cb): #8778 linux (Dragonboard): drop EXT2_FS to match other targets

It looks like there was only one commit between those two builds: https://github.com/LibreELEC/LibreELEC.tv/pull/8780

and that only affects binary addons. Is your issue with local files, or using an addon?

Display More

So sorry about this - in order to prove to myself that I wasn't being crazy I reloaded the 726b493 build. Turns out that I must be!

All my HEVC files (they are all local by way of a new 4tb nvme drive - love the new Pi5 having this feature) now play flawlessly.

Only thing I didn't try when it wasn't working yesterday was the old IT Crowd catch phrase "Have you tried turning it off and on again".

Once again, sorry to have wasted your time.

Quote from Wolfpig

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

All working now - it was just a simple PBKAC.

Quote from popcornmix

I'm not seeing a 1st April nightly here: https://test.libreelec.tv/12.0/RPi/RPi5/

I do see 3rd April had an unwanted kodi bump that was bumped back on 4th April.

Does 4th April nightly also have the issue?

This is the 1st April nightly I'm referring to:

LibreELEC-RPi5.aarch64-12.0-nightly-20240401-726b493.img.gz

I'll try the latest (LibreELEC-RPi5.aarch64-12.0-nightly-20240405-b5ce01c.img.gz) when I have a bit more time.

Thanks for responding.

Could be just me since I haven't seen any similar posts but something changed between the 31st March and the 1st April nightly - i.e. with 31st March le12 nightly I have video + audio but with 1st April nightly it is only audio (my Samsung tv reports mode/resolution not supported).

From what I have observed it is only happening with HEVC videos (720p/1080p/2160p) - by turning off DRM Prime fixes the problem and the video is shown along with audio.

As I said it could be something in my settings but I don't recall changing anything that would have this effect and simply reverting back to the previous nightly build fixes the issue then I believe that it may be more widespread.

Quote from Jocke.Sve

Could You please post a link to where one can find more info about this.

Couldn't find anything obvious about this on Kodi web of in their form.

Thanks!

Kodi wiki link:

Video versions - Official Kodi Wiki

I'm not sure which Kodi sub-forum covers this - please let me know if you find it!

Quote from chewitt

"Versions" is the gift that keeps on giving .. the initial merge looked simple but then the 101x unconsidered corner-cases where it had unexpected impact started to show and it's been a complete pain in the rear to fix things; most of the original code has now been reverted and reworked to avoid or better resolve problems. If you report stuff in Kodi forums please be mindful that the devs who read of more issues will be "delighted" to know there's more

As mentioned above, I don't know which sub-forum covers this so I think I'll hold off and give it a few weeks for the coding to settle down. Just take a look at the videoversiontype table of MyVideos131.db where lines 24 to 387 are blank and then it shows "4K" and "3D" at the end - of course that might have been generated due to me specifically setting the versions as 4K & 3D.

As a side issue, you wouldn't happen to know which table is used for the field="filename" rule when used in a .xsp file?

Quote from chewitt

Versions is a new feature that's had a challenging introduction (lots of rework needed since initial merge) so the best place to ask for help with it is the Kodi forum; as that's where the developers who've done (and are still doing) that rework, hang out.

Thanks, I'll do that.

I guess I was potentially trying to emphasise the issue in order for it to be considered in that rework.