I can confirm working again with generic nightly-20240613-18becd8
and raspi 5 nightly-20240614
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
There you go:
Thx,
I have access to UHD streams on ASTRA/HotBird Satellites via a TVHeadend server.
Using the the Hts client I can play all streams except UHD (they do seem to be HLG, but not sure) on my Intel Kodi machine.
I can play the channels on Rpi 4 clients.
I can play a recording of these streams in both Intel and rpi clients, so its not the player that has an issue with the content. Playing back the recording uses HW decoding.
Any idea what's wrong with the Intel hts-client? Sometimes it works if I turn off Hevc VAAPI and/or, when I tell the client to use http streaming.
Thx
A quick, maybe unrelated, the question to someone who knows about Intel drivers:
why can I not playback UHD when watching TV via HTS client on Intel systems?
It seems to work when I turn off HEVC VAAPI.
Funnily, I can playback a recording of the uhd channel.
Sometimes I can play live UHD when I use Hts via http, but not always.
Where is this code located, who to ask? (the hts-client guys?)
nuc11 was abandoned back in 2021 because of this. This question has been asked many times since, noone cares about 11gen nucs anymore. The agreed upon reason seems to be: 'Intel has crappy Linux support' and/or 'Nucs use evil lspcons to get from dp to hdmi', They need native hdmi, then mabe, it'll work. There's a recently opened thread about the new 12gen asus p42 NUCs, maybe it works there. Seeing is believing. here:
Intel Alder Lake 2160p @ 23.976 Hz passthrough HD Audio dropouts (i7-1270p/N100) - Page 3 - Hardware - LibreELEC Forum
And finally: go use a raspi or some other toy, don't spend more than 100$, it's not worth the hassle.
As you can see on this block diagram, NUC11PAxxx does not have a native HDMI port. It is using a DP->HDMI protocol converter (PCON) chip. It is more than likely the source of your audio passthrough issues. So this is not a gen11 issue but an issue specific to that NUC model. There is nothing to fix from LE/Kodi side.
I thought the lspcon issues were solved long ago in 5.x kernels
Also it used to work on my 5thgen with LE 9/10
I am, guessing this is a new issue.
Does anyone know if the hdmi2.1 on the N100/200 are native? Asus doesn't have diagram, and I don't trust the one from asrock.