[SOLVED] Moode 8.3.0 RPi 1B+ - UPnP-Renderer doesnt show up

[psychofaktory]

Could be...but  it seems a better audience would be   the gurus who hang out on the Raspberry Pi Forum (I'd go there first) or the counterpart github repo (I'd go there only if I had a pretty clear idea of the source of the incompatibilities, but that's just me).

If you had a USB-Ethernet adapter (or USB-WiF adapter for that matter) lying around, you could bypass the Ethernet aspect of the LAN9514 as a test of your hypothesis.

The difficulty with such problems is to find out where exactly the error lies.
Only then it is possible to say to which place it is best to turn to get help.

In any case, I am extremely grateful for your helpful tips and the time you take!

I had an Ugreen USB-to-Ethernet adapter (AX88179A chip) here that I had just tested to be able to exclude the LAN9514 chip as the cause of the error.

But also with this adapter I get the same error.

After I had dismantled everything again, I have undertaken another test.
I have activated the DLNA server in addition to the UPnP renderer.
The network technology used is basically the same. Multicast packets are sent here as well.

Curiously, the DLNA server from Moode can be displayed at the UPnP control points and at the BubbleUPnP server. However, the UPnP renderer from Moode on the same device does not.
What can be deduced from this?

I just tested with my Pi-1B both Ethernet and WIFi and no issues whatsoever. I set Server type to "OpenHome" in UPnP Config and "Moode UPNP" renderer showed up in Linn Kazoo after a bit.

This indicates no hardware incompatibility between Pi-1B and UPnP stack.

This makes the whole thing seem even stranger.

What makes your setup different from mine?
Is there a particular setting I made that doesn't exist in your setup that could cause complications here?
I already posted my system information in the first post.

[Tim Curtis]

I just tested with my Pi-1B both Ethernet and WIFi and no issues whatsoever. I set Server type to "OpenHome" in UPnP Config and "Moode UPNP" renderer showed up in Linn Kazoo after a bit.

This indicates no hardware incompatibility between Pi-1B and UPnP stack.

This makes the whole thing seem even stranger.

What makes your setup different from mine?
Is there a particular setting I made that doesn't exist in your setup that could cause complications here?
I already posted my system information in the first post.

There is only the one setting in UPnP Config otherwise I just used a stock 32-bit 8.3.0 image. My network is a single ASUS WiFi Router with 4 x Ethernet ports.

Based on my experience your symptoms suggest something external to moOde software or Pi hardware for example some sort of network configuration issue.

[the_bertrum]

Has the old standard of re-flashing/different SD been tried on this problem yet? It has been known to work wonders in the past.

[psychofaktory]

There is only the one setting in UPnP Config otherwise I just used a stock 32-bit 8.3.0 image. My network is a single ASUS WiFi Router with 4 x Ethernet ports.

Based on my experience your symptoms suggest something external to moOde software or Pi hardware for example some sort of network configuration issue.

OK, thats all kind of strange.

I did exactly the same as you now:

• Flash stock 32-bit 8.3.0 image
  
• Set nothing else than the UPnP-renderer
  

And voilà, the UPnP-renderer is displayed on the network.
After that I made all other settings as before and checked after each setting or UPnP renderer is still displayed on the network.
But even after all the settings were then at the same level as when the installation didn't work, the renderer still showed up. Even after a restart.
The only difference from the previous installation was that the order in the configuration was different.

Then I realized that I forgot to change the Service Type from UPnP-A/V to Openhome in the UPnP Settings.
As soon as I changed this setting, the UPnP renderer disappeared from the network.

To make sure that no other setting was involved, I rebooted the system another time. This time I made the switch from UPnP-A/V to Openhome right at the beginning. Again, the UPnP renderer disappeared from the switch to Openhome.

So it seems to be a software problem after all, where the Raspberry Pi 1B under Raspian Bullseye does not deal with the Openhome standard.

Has the old standard of re-flashing/different SD been tried on this problem yet?  It has been known to work wonders in the past.

Yes, did that two times before, with the same result of UPnP-renderer keeping not showing up on network

[the_bertrum]

I'm using OpenHome on my Pi Zero W with out issues though...
Swapping between A/V and OpenHome is one case where I find the "cache clearance routine" is essential to get the control points to see the renderer however.

[Tim Curtis]

There is only the one setting in UPnP Config otherwise I just used a stock 32-bit 8.3.0 image. My network is a single ASUS WiFi Router with 4 x Ethernet ports.

Based on my experience your symptoms suggest something external to moOde software or Pi hardware for example some sort of network configuration issue.

OK, thats all kind of strange.

I did exactly the same as you now:

• Flash stock 32-bit 8.3.0 image
  
• Set nothing else than the UPnP-renderer
  

And voilà, the UPnP-renderer is displayed on the network.
After that I made all other settings as before and checked after each setting or UPnP renderer is still displayed on the network.
But even after all the settings were then at the same level as when the installation didn't work, the renderer still showed up. Even after a restart.
The only difference from the previous installation was that the order in the configuration was different.

Then I realized that I forgot to change the Service Type from UPnP-A/V to Openhome in the UPnP Settings.
As soon as I changed this setting, the UPnP renderer disappeared from the network.

To make sure that no other setting was involved, I rebooted the system another time. This time I made the switch from UPnP-A/V to Openhome right at the beginning. Again, the UPnP renderer disappeared from the switch to Openhome.

So it seems to be a software problem after all, where the Raspberry Pi 1B under Raspian Bullseye does not deal with the Openhome standard.

Has the old standard of re-flashing/different SD been tried on this problem yet?  It has been known to work wonders in the past.

Yes, did that two times before, with the same result of UPnP-renderer keeping not showing up on network

In my test the Service type was set to "OpenHome"
.

[TheOldPresbyope]

There is only the one setting in UPnP Config otherwise I just used a stock 32-bit 8.3.0 image. My network is a single ASUS WiFi Router with 4 x Ethernet ports.

Based on my experience your symptoms suggest something external to moOde software or Pi hardware for example some sort of network configuration issue.

OK, thats all kind of strange.

I did....

So it seems to be a software problem after all, where the Raspberry Pi 1B under Raspian Bullseye does not deal with the Openhome standard.

Has the old standard of re-flashing/different SD been tried on this problem yet?  It has been known to work wonders in the past.

Yes, did that two times before, with the same result of UPnP-renderer keeping not showing up on network

Two things: you need to stop saying the renderer doesn't show up on the network---because you have established only that your particular control point doesn't list it under the conditions you have described---and you need to stop saying the Pi 1B on Raspberry Pi OS doesn't deal with the OpenHome standard ---because what you've done hasn't established that yet.

The UPnP-A/V (with DLNA constraints) and OpenHome specs are related in that they both describe UPnP stacks but the services they offer are incompatible. Some control points and renderers understand both, some understand only one or the other, and as the_bertrum has repeatedly said, some get confused when caches get stale.

Since you are using an Android phone to run BubbleUPnP [1], check your Play Store for an app named "UPnP Tool for Developer" by TJ App. If you find it, install it.

Now, configure the moOde UPnP renderer for service type UPnP - A/V, let the renderer restart, then check the Device List in UPnP Tool. You should see your moOde player show up in the Device List with whatever name you gave the renderer. Click on it. You should see a list of services with urns like:

Code:

urn:schemas-upnp-org:service:AVTrsansport:1

etc.

Next, configure the moOde UPnP renderer for service type OpenHome, let the renderer restart, and again check the Device List in UPnP Tool. You should see a new entry for your moOde player. Click on it. You should see a list of services with urns like:

Code:

urn:av-openhome-org:service:Time:1

etc.

In my case at least, the Device List now shows both instances of the renderer---an example of caching.

The UPnP Tool app is doing the UPnP discovery work itself so it's a test of both UPnP devices and the interconnecting network.

There are similar diagnostic tools available for Android and for  other O/Ses (like gssdp-discover in LInux)  but I found this particular Android app to be easy to install and easy to interpret.

Regards,
Kent

[1] as an aside, there is the BubbleUPnP for DLNA/Chromecast app and there is the BubbleDS for Linn DS/OpenHome app. Both from Bubblesoft.

[psychofaktory]

Thank you for your tests and clarifications!

Thus, my conclusions were unfortunately not correct in all points.

To check whether the UPnP renderer works, I had used the BubbleUPnP app on my Android smartphone on the one hand, and the BubbleUPnP server on the other, to be able to exclude that the problems are related to the Wifi connection.

However, the BubbleUPnP server seems to be designed to only show UPnP A/V renderers so that they can be proxied as OpenHome renderers if needed.
Thus, the server is probably not suitable to check whether an OpenHome renderer is actually accessible.

The "UPnP Tool for Developer", on the other hand, recognized all variants on my Android smartphone. Both the Moode UPnP-A/V renderer, as well as the Moode Openhome renderer. The Openhome proxy of the UPnP-A/V renderer created via the BubbleUPnP server was also found.

So it can be said that on the part of the Raspberry Pi 1B and Moode also in version 8.3.0 the UPnP renderer for mpd works.

The BubbleUPnP app now seems to be the component that shows a strange behavior.
There is neither the UPnP A/V, nor the Openhome variant displayed. Only the proxy created via the BubbleUPnP server is listed.
Other UPnP renderers (both Openhome and non-openhome) are displayed.
And I'm also sure that with Moode 6.4.1, Moode's openhome renderer could still be displayed in the app, and in the BubbleUPnP server too.

I had used the procedure to bypass the cache issue in each case.
In the meantime, I had even completely rebuilt the BubbleUPnP server and completely deleted and reinstalled the BubbleUPnP app.
In the case of the BubbleUPnP app, however, I found that it was sufficient to close the app completely once and then start it again.


Network-wise, on the other hand, everything seems to be fine.
In the upmpdcli repo was confirmed to me by the maintainers that there is purely network-technically no difference between UPnP-A/V and Openhome. Only the service description downloaded from the control point would differ.

It was also stated there that the version of upmpdcli used in Moode is quite outdated.
I had then performed an update of upmpdcli as described here.
This did not improve my problem, but there were no negative consequences.




I really appreciate the patience you guys have with me.

[the_bertrum]

How have I managed without that tool @TheOldPresbyope ?
Thanks!

[psychofaktory]

The maintainers of upmpdcli gave me the tip, that there is beside the upmpcli log also a log for the upnp communication. With this log I could find and fix the error.

My smartphone was connected to Wifi and to Wireguard-VPN. Wifi was the same subnet as the UPnP renderer. VPN was another subnet from which accesses are routed to the first subnet. By default, accesses to the UPnP renderer were always from the VPN subnet. So you were 100% correct with your assumption that the requests came from another subnet.

I have now excluded the BubbleUPnP app from the wireguard connection and was able to access the Openhome renderer directly.


So Moode and also the UPnP renderer work perfectly fine. Also on a Raspberry Pi 1B.

According to the upmpdcli maintainers, the fact that the behavior under Moode 6.4.1 in the same constellation was different for both the BubbleUPnP server and the BubbleUPnP app is due to a change in the upmpdcli code in the meantime.

The chain of circumstances had caused me to look for the error in a completely wrong place.

In the end, however, all the questions that came up could be solved and I really learned a lot in the process.

Thanks a lot for your support to find my error!!!