Yes, tested it yday and it's solved,ty!
The screenshot in your first post is showing that your PiHole received a DNS A (address) request for "synologynas" and responded with NXDOMAIN (no address) - so your PiHole doesn't know anything about a "synologynas" host in your LAN.
You may want to add your local domain name (eg ".lan") to the source hostname (eg "synologynas.lan") and make sure PiHole resolves the name to the IP correctly.
It looks like you are right.
I added it in pihole and don't see those massive requests again. I'm still at work so can't test a lot but will do when I get back.
However it's still strange for me because I never used this feature and hardly make use of .local/lan domains.
synologynas is likely a local hostname to be resolved.
Unfortunately resolving host names via nmblookup was dropped from kodi 20, now DNS lookups are finally used.
You can try to enable WS-Discovery via Settings->Services->SMB Client.
Yes, it's local hostname of my NAS.
I do see that the 'mediasources.xml' is usingCode
Along with passwords.xmlCode
<sources> <programs> <default pathversion="1"/> </programs> <video> <default pathversion="1"/> <source> <name>Videos</name> <path pathversion="1">/storage/videos/</path> <allowsharing>true</allowsharing> </source> <source> <name>TV Shows</name> <path pathversion="1">smb://SynologyNAS/SynologyNAS/Tv-Shows/</path> <allowsharing>true</allowsharing> </source> <source> <name>Movies</name> <path pathversion="1">smb://SynologyNAS/SynologyNAS/Movies/</path> <allowsharing>true</allowsharing> </source> </video> <music> <default pathversion="1"/> <source> <name>Music</name> <path pathversion="1">/storage/music/</path> <allowsharing>true</allowsharing> </source> </music> <pictures> <default pathversion="1"/> <source> <name>Pictures</name> <path pathversion="1">/storage/pictures/</path> <allowsharing>true</allowsharing> </source> </pictures> <files> <default pathversion="1"/> <source> <name>SynologyNAS</name> <path pathversion="1">smb://SynologyNAS/SynologyNAS/</path> <allowsharing>true</allowsharing> </source> <source> <name>storage</name> <path pathversion="1">/storage/</path> <allowsharing>true</allowsharing> </source> </files> <games> <default pathversion="1"/> </games> </sources>
I tried to enable WS-Discovery but didn't make any difference.
LE is using the default libc resolver and this caches records according to their TTL values so I doubt caching is the issue. I'd make an educated guess that Kodi makes some form of discovery request which is being denied or sinkholed by Pi Hole and so the request is being repeated (ad infinitum) hoping to get a response (which never comes). There is probably something in Kodi that could have better failure logic. In the same breath Pi Hole improvement to not break the world's most popular mediacentre app would be a good thing too. The decision to use Pi Hole also makes it a self-inflicted problem, sort of, so both sets of developers will probably point fingers at the other.
More verbose logging from Pi Hole and/or perhaps a PCAP of the traffic to look at would be useful.
I made a pcap and verbose logging file. Is there any place where I can upload it safely (especially the pcap, not sure if sensitive data is in it and the file is almost 100mb big as well)
Since the upgrade to the latest newest version of LE I noticed that my network requests went through the roof. I can see that in Pi-hole otherwise I wouldn't even have noticed it. I have no problems though.
I use sql library which is stored on my Nas
As you can see it made 22 requests within the same second.
I 'think' its mostly when it updates the library but not everything.
When I run kodi on my windows pc and do a lirbrary update I don't see this kind of spam.
But nvm I give up...
Tried to explain several times there is not a problem with my network or LE client or Nas. When I turn this feature off I don't see that message at all. Also movies start playing INSTANTLY and when I stop them at the end it's also INSTANTLY. Something is of with the WoL feature in this release because before upgrading I didn't had any issues at all and was probable on for 2-3 major releases ago. Also multiple clients experienced it with.
But there is no problem with the server
The NAS is online and as I said when I turn that feature off the video play instantly. And prior to this release I also never had any issues with it.
Also (said before) I watch movie from begin to end without any problems when the movie is finished and I press 'stop' it takes a long time before going back to the GUI. (if I can watch a movie from begin to end it rules out that I have connection problems). Turn that feature off and my videos instantly play or stop.
I've no idea how the feature works, but programattically, how do you expect Kodi to know that the remote device is already turned on?
I have no clue.
The only thing I can say and confirm before 10.95.0 releases (including older LE version) it worked fine. As in, if my NAS was turned off it would sent a WoL package when LE turns on, if it was already turned on I had no issues with starting or stopping the movies (instant start and stop).
But now when it's turned I get that message and with a timeout bar. When the video has ended it stays for a long time on the last frame of the video (like it freezes) and eventually goes back to the GUI.
Turning WoL off in the settings and everything is fine again.
RPI4s with LE 10.95.0 11.0
SQL shared library
I think there is a problem with the Wake on Lan feature in LE.
I recently upgraded my Libreelec clients to the the 10.95.0 version. Database was migrated successfully and was able to start/stop movies. However I started to notice when I watched a movie or tv-show and it ended it took a very long time to get back to the Kodi GUI. Also when I started a movie/tv I noticed a popup window showing up with the text 'Connecting to network' with a progression bar. After ~10-15secs the movie/tv show finally started to play and I could watch it from start to end without problems. This behavior started since the upgrade and older versions never showed this behavior
I turned off the WoL feature and every movie/tv show plays immediately and when stopping it goes straight back to the main menu.
It seems that the WoL feature is being triggered all the time even when my NAS is already turned on.
If I where you I would look into that shared library suggestion.
1 Centralized library and doesn't matter on which client you update or clean library. When 1 does update/clean it's active for all clients.
because LE10 still uses ye olde Xorg for the Generic image and all these patches are aimed at the GBM/V4L2 pipeline we are not (yet) using. Until we make the switch, community created images are the well-proven approach to testing things.
Thanks for your explanation.
So basically all x86 hardware doesn't support HDR until LE10.2 or probably L11/K20. So it's either use the Windows version or these community builds or Rpi4
But if those patches dont make it in LE10 then bit sad as we have to rely on smp which aint great for him haha or build our own.
Why won't it make it to the LE10 builds? I'm happy to test but in the end I prefer to go back to the original releases and follow their update cycle instead of relying on SMP. Would be a shame to consider replacing this NUC (7i5) if if it has the ability to work but not with the official build.
I remember that if you need to set the options for the DTS, Dolby Digital, etc you need to turn on Advanced View. Perhaps you're still using Basic settings and then they are not visible
You are right.
Apologies! I've been upgrading several clients and forgot to turn it back on this machine.
That's good news. You are the first one who reported a working HDR on older LSPCON hardware. It looks like that NUC has MegaChips MCDP2800BC LSPCON.
I uploaded an updated image.
- Linux kernel 5.12-rc4
- Kodi e04f7d6
Everything else is identical to a build from post #494.
Just tested it and HDR still works
However 'allow passthrough' doesn't seem to work with this build. I can turn it on but but missing all the options like DTS, Dolby etc to turn it on/off. Didn't had an issue with the 1st build I tested. And when I restore my backup which I made from the first build it does work again. And I'm still on the same build version (*32b3089). I take it it shouldn't be an issue to restore my backup, right?
btw thanks for you help again.
Yes, that one is working.
Haven't tested it properly yet though but I did saw the HDR icon show up on my tv.
But for future reference/updates which version of this should I be on the lookout. Because there are several builds in this topic?
Updated build with HDR:
Current Kodi master (83387b9)
Linux kernel 5.11.7
Full-feature Intel media-driver with fixed VAAPI DI
HDR patches from Commits · lrusak/xbmc · GitHub
Thanks, I just tested and ran the live/run version on USB.
However I don't get any HDR output on my tv.
When I run Kodi in Windows my tv does recognized the HDR input so I would assume there is nothing wrong my connection setup (nuc -> onkyo -> tv)
I have a Nuc i5 (NUC7i5BNB)
HDR isn't supported on x86 devices at this time.
There is a thread on here with some WIP builds to support HDR but your mileage may vary.
ow really? now i feel stupid lol
I just assumed it was seeing the rpi4 builds had it
Maybe a silly question but how can I check if HDR is working correctly? Or let me rephrase I suspect it's not working in my case.
Because when I check my TV settings I usually can see if a HDR source is detected. However when I uselibreelec I don't see the HDR icon on my TV. But the screen looks ok prior to this version HDR content usually looked like it had too much white in it but I can't see any of that.
When I use Kodi install via Windows I can play the same HDR content without any issues. And in this scenario my TV does detect the HDR source (because it shows a hdr icon). I also see in the kodi settings under video a toggle to turn off/on hdr which I don't see in the Libreelec version.
I tested with a NUC dual boot libreelec beta and windows 10 / kodi install.
Onky TX-NR676E receiver
Samsung Q90 tv
I was going to try that but am waiting for the final release since Kodi is now final. Should be any day I guess.
However I do find it strange that this worked fine before during beta's it stopped working since the latest 2 SP's