-
-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New version 3.0.0 of JUPnP library is breaking at least Sonos binding when several interfaces are up #4140
Comments
I can confirm that audio and voice stuff is working well in OH 4.1.1. |
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-2-milestone-discussion/154316/36 |
Taking a quick look, I think this line in #4116 is incorrect:
It should be:
I don't know if that could be the problem. |
I've also reviewed #3960 and I don't think I have broken this with it. The only one I think can affect these is the change in the AudioStream::equal method but I think it's ok and I don't see any other thing suspicious. |
@openhab/core-maintainers : am I alone to not be able to use OH 4.2 due to this critical issue ? How can we progress ? Do you need I enable some logs ? |
Hello @lolodomo |
The Sonos audio sink and more generally the Sonos binding was not changed in 4.2. I will try the WEB audio sink. |
Audio and voice is working when using the WEB audio sink. So that means something was changed in the core framework breaking only certain audio sinks. |
I got these strange DEBUG logs from the Sonos audio sink !
|
The Sonos binding seems to be broken in 4.2, I do not receive anymore some of the important messages from UPnP subscriptions. Channels are no more updated. @wborn : OH 4.2 is packaged with a new version of JUPnP for which you made a lot of changes. It could be the origin of the problem. Does one of your changes in JUPnP require a change in the bindings ?
|
In OH 4.1.1, JUPnP library is in version 2.7.1.OH1 and the Sonos binding is working well. I am now convinced that the problem is not the audio stuff in general (sorry to ping you @GiviMAD ) but the new version of the JUPnP library that broke the Sonos binding (and probably other bindings) . |
I could try to install the old version of JUPnP library in OH 4.2M1 to confirm what I suspect but I am not yet sure how I can retrieve this old version (or build it). Edit: ok, I can simply find the jar at this place |
No worries, happy to help! |
Not that I know of but there were many changes so there could also be regressions. The changes were mostly cleanup, upgrades and switching the build from tycho to bnd. |
Unfortunately; if I install the 2.7.1 version of the JUPnP bundle in OH 4.2M1, bundles including the Sonos binding are no more running. So I cannot prove that the problem is the new version of JUPnP but I am almost certain that it is. |
I don't know how to proceed now ? |
What is happening is that events from Sonos devices are no more arriving to the binding even if I see in logs that subscriptions to UPnP services are mentioned as succeeded. |
The addon/core bundles will now have 3.0.0 as lowerbound in the jUPnP compatible version range so bundles will not properly resolve unless you recompile them or change the manifest manually. |
You mean I should update manually the bundle version to 3.0.0 in the manifest of the old jupnp jar file ? |
Yes that may be a quick way to find out if it is due to the upgrade. |
I tried.
If I restart OH, in a very first time, I can catch that
but when the startup process ends, finally my jupnp bundle is automatically replaced by the official one having version 3.0.0.
Why my bundle is overwritten at startup ? |
I found something interesting in the logs at startup with the packaged JUPnP library (3.0.0), several lines of this kind:
This IP is the Wifi IP of my RPI, not the LAN IP. In OH settings, I can see these two IP in the network settings but I selected the LAN IP as main network interface, not the Wifi interface. I assume "f.transport.servlet.ServletController" is a class from JUPnP ? Why is my Wifi IP used ? |
Making slow progress with installation of the old JUPnP library. |
Even with version "3.0.1", I still have problems:
Let's make a last try using 3.0.0 as version. |
For reference: jupnp/jupnp@c988925 (I also went looking for it 😉) |
What could make a difference between 4.2 and 4.1.1 is if @wborn : I am not enough expert in OSGi to understand where in the code |
Is it also null in OH 4.1.1 if you restart the jupnp bundle after everything is started? If not it maybe timing related. |
I can't verify, I don't think I can build the old JUPnP library. Is it possible ?
Maybe. Does the |
The difference in code when the HTTP service is there or not seems to be mainly the computation of the listen port. Maybe all this block could be ignored but I am not yet sure at all:
to finally run that
|
JUPnP main bundle is referencing the HttpService bundle but apparently the HttpService can be started after and in this case the code seems to restart JUPnP: So the block I was talking about in my previous message is necessary. In fact, two cases are supported, when an HttpService bundle is started and it is not. It probably allows JUPnP to work even without an HttpService bundle ? |
Yes the HttpService only exists when using OSGi and JUPnP also supports OSGi-less Java stacks and Android Apps. |
@wborn: I have a doubt about required/mandatory OSGi reference. In our case, we have:
Are references to If it was a mandatory reference, I don't understand the comment "Only need to restart jupnp after/if HttpService appears". What is sure is that there is no reference defined between |
Maybe an attribute |
The default would be OPTIONAL (to be confirmed by someone who knows well OSGi). |
On my RPI with snapshot 4012 and a patched version of JUPnP, here is the order at startup:
The sequence is as if the policy was REQUIRED ? |
Looking more attentively at the first lines, it seems to be rather optional:
That would mean the loading order could be different and my dependencies could be not yet injected when the component is activated ? |
In addition to the fact that I would expect required OSGi dependencies to avoid potential re-init of all stuff in the bundle, I also see no valid reason to release the OSGi HttpService. The idea was maybe to trigger the unset method in the main bundle and then restart all the stuff but this time without using the HttpService. In addition to the fact that it apparently does not work well, my question is what is the interest of doing that (because this is ok to use the HttpService) ? |
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Move OSGi dependency to HttpService from UpnpServiceImpl to OSGiUpnpServiceConfiguration. Fix openhab/openhab-core#4140 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
Issue has to be reopened until OH switchs to JUPnP 3.0.1. |
I already thought that might happen based on the "Fix ..." text in your PR. 😉 |
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-2-milestone-discussion/154316/103 |
say in DSL rule is doing nothing.
In console, voice:say or audio:play are not working. The console commands I tried:
I am using Sonos as audio sink and VoiceRSS as TTS.
The only DEBUG logs I can find are:
If I check the audio and voice bundles:
@GiviMAD : as you are the one that updated this part recently, I am very afraid you broke it.
I am going to switch back to OH 4.1.1 to check if audio/voice stuff is working again.
The text was updated successfully, but these errors were encountered: