Does anyone know if passthrough has been fixed for intel in general, i.e 11.gen, or only for alder lake? it used to work as far back as 5th gen.
Posts by yamcenutzer
-
-
-
Quick test yesterday evening, I thought I could test display port, I got my DP to HDMI cable and plugged it into the AVR (Denon 4700H) and lo and behold, no more audio dropouts within 15 minutes!? I'll test more this evening and report back! The motherboard is Asus N100I-D-D4 and I'm on 12.0.1, use passthrough and 23,976.
What are you passing thru? truehd,dts-ma ...?
-
IIRc this bug was introduced way back in with graphics switch from le9 to le 10 (or was it 10 to 11), I forgot. That was also the switch that broke hd audio passthru on intel systems (used work ok before that).
If you go look for it, you might find the "we give up on Intel.." mail in the KODI forum around that time...
Which is why I don't believe LE will ever come out of it's "raspi is the only system we really work for " niche. might as well go for it.
-
IIRC intel support has stagnated to a virtual standstill since gen11.
-
Intel N100 processorbased motherboards will play x265 4k HDR and they are really snappy.
I have a https://www.asrock.com/mb/Intel/N100DC-ITX/#Overview
and there are plenty of cheap mini-pc with N100 on amazon.
- has intel regained the capability to pass thru hd-audio ?
- has intel hw regained the capabilty to playback uhd streams from live tv (via tvheadend client)?
-
no , that was too obvious, also, the editor would have shown it, whatever it was, it was it bit more subtle. unfortunately I didn't care to save them, since I wasn't expecting it to work so 'easily'.
-
This can be closed:
I deleted and once more copied over all the xml files from a working box to the raspi boxes, and now it's working.
I suspect I had opened/edited these files via smb and introduced a non visible whitespace char in some alien charspace or something like that...Anyway it is working now. No need to confuse anyone else.
-
I can confirm working again with generic nightly-20240613-18becd8
and raspi 5 nightly-20240614
-
yes, that is what I'm saying : raspi builds seem to not understand the same sources/password as used on generic builds.
The question I have what else do they need if anything and, more importantly, why?
Alternately has the audio passthru issue ever been resolved on intel 11gen? that would allow to switch back to intel nucs
-
So what remains then, since I am using the same config files on both platforms.
the log on raspi fails with errors like this:
2024-06-08 11:18:45.400 T:1306 error <general>: SMBDirectory->GetDirectory: Unable to open directory : 'smb://192.168.1.3/shares/Filme/Das%20Bose%20unter%20der%20Sonne'
unix_err:'16' error : 'Invalid argument'Whereas the intel log just open the file without the escape chars using the actual hostname:
2024-06-08 20:57:40.460 T:981 info <general>: VideoPlayer::OpenFile: smb://mediaserver/shares/Filme/Das Bose unter der Sonne/Das Bose unter der Sonne.mkv
What make raspi use the ip address instead of hostname, or is it only the error message that use that?
name resolution does work on the commandline of course, e.g, ping or tracert
-
I doubt it is the protocol, since smbclient does work. I can of course try setting the min also to smb3.
Also using pathsubstitution in advancedsettings.xml i.e. from smb://xx to /storage/xx works and then using /storage/xx in sources...
But that defeats the purpose of being compatible with kodi on windows and using a sql database for all kodis/les
So smb is working, but not directly from sources/passwords. some intermediate step seems different on raspis from the generic builds. I haven't tried anything else, but I remember it was broken before, then started to work, maybe a year ago, then broke again maybe with the arch change ( I really don't remember the exact timing anymore, since I never really wanted to spend time on these contraptions, but there seems to be no alternatives anymore)
-
smb2/3 works fine with intel builds
In fact, I am using the same smb.conf, sources.xml, password.xml (copying them around) whenever I decide to try a new LE box. Which is why I am flummoxed by the different behaviour of the smb client. Note that I can run the smbclient manually on the raspi and access the shares.
Could this be some weird timing issue?, the raspi is a lot slower than real cpus...
-
I would be grateful if someone could also shed some light on why the raspi builds can't access files (videos, music) on smb:// type urls even when sources.xml contains the right link and password.xml contains the access details for the smb share. Note that to used work some years ago, now only intel builds work this way.
Long ago there also used to be a mediasources.xml which could contain smb://user:passw@usrl , but that has also silently vanished and only contributes to confusion.
Thx for any pointers
-
-
-
-