The Pulse Audio binding is being suggested because there is something on your LAN which responds to the mDNS query for the _pulse-server._tcp.local. service.
=> @pleedell so perhaps you can use an app on your phone (e.g. Android ‘mDNS Discovery’ app) to find out (and let us know) more about what that device is?
@Kai / @holgerf … just wondering does the new IP scanner run its scan a) on the OH main thread, b) on the OH core scheduler, or c) on its own separate thread? I am pretty sure that the UPnP scanner and mDNS are running the discovery on separate threads inside the respective JUpnp and JmDNS packages. But maybe the IP scanner is not?
@AndrewFG I’m in doubt that the IP scan could cause a severe delay. Probably the name “IP scan” gives the wrong impression that it tries to connect to thousands of ports…
Currently we send only one single frame on each of the network interfaces.
The scan itself runs in a separate thread, this is the code involved:
Logging could be extended via log:set TRACE org.openhab.core.config.discovery.addon.ip (or without .ip to activate for all finders). And all finders can be deactivated via Settings → Add-on Management → (show advanced) → … Suggestion Finders. Make sure that you wait 1 Minute after saving this setting before you restart.
@tuny could you try and give feedback if it changes something?
To understand the problem a little better I did the update from M4 to M5 again.
From the first start after the update the modbus manger takes several start attempts.
In that time the modbus things are changing their status constantly.
So the log is full of messages.
It takes many minutes till everything is quiet and the startup process is completed.
From then on the problem is no longer reproducible.
I can do reboots and restarts without problem.
So it does not seem to be a problem with the “IP scan” in general.
Maybe it is just my system (odroidC4, see systeminfo) that runs out of memory with the first start…?
It is hard to say.
Thanks for your effort.
Keep in mind that when you do an upgrade the cache gets cleared. When that happens, all the add-ons need to be redownloaded and reinstalled which can take some time. I wouldn’t be surprised if behavior has to do with some resource that Modbus needs or a Modbus Thing needs (e.g. a transformation) isn’t yet installed and available when Modbus comes up that first time. Eventually though all the add-ons get installed and the problem resolves.
Correct me if I’m wrong but Sony TV is not merged into the codebase. It’s marketplace only. As such the addon.xml didnt get updated like the ones merged in do and won’t show up.
I think more precisely that only the core addons are even considered by the suggestion finder. So actually the contents of the xml of market place addons probably makes no difference.
IMHO the Sony Audio binding was NOT incorrectly suggested. This is because there IS a device on your network which DOES advertise itself as a MediaRenderer and manufactured by Sony. So the Sony Audio binding is therefore CORRECTLY suggested.
I’ve just tried RC1 and at the first startup all add-ons are reported to not be installed (despite the fact that they are installed and running) - which also leads to a long suggestion list. It’s not a UI issue, it’s the REST API that reports all of them being not installed. On subsequent startups, this only occurs during startup, but afterwards the installed add-ons are reported correctly. Anybody else seeing this effect?
The second time i started openHAB, I saw this in the openhab.log:
2023-12-21 07:53:42.038 [ERROR] [scovery.addon.AddonSuggestionService] - bundle org.openhab.core.config.discovery.addon:4.1.0.RC1 (167)[org.openhab.core.config.discovery.addon.AddonSuggestionService(127)] : The addAddonFinder method has thrown an exception
java.util.ConcurrentModificationException: null
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1631) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) ~[?:?]
at org.openhab.core.config.discovery.addon.AddonSuggestionService.changed(AddonSuggestionService.java:189) ~[?:?]
at org.openhab.core.config.discovery.addon.AddonSuggestionService.addAddonFinder(AddonSuggestionService.java:177) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
