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
how's it going? Does Intel even remember what an iGPU is/does?
don't hold your breath. There are hardly any uhd programs anyway and Intel HW is too complicated to be dealt with as a hobby and/or part-time project. LE is mainly raspi focussed.
will do, thanks,
although i do only have an i3, so probably no xe gpu
Whatever you did, would that also somehow effect the 11gen intel cpus` (rocket lake, e.g. on a nuc11pahi3) ?
if I record the stream I can playback the recording wit hevc hw being used.
Maybe I should do a log of that use case for comparison
There you go:
Thx,
btw._ I tried asking about this on the pvr-hts github But they just closed the issue, because it was asked before and noone could resolve it.
It really seems that intel is gradually losing its OSS base. What a pity.
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.
