whatamesss
commented
8 months ago ps: if the server mode is enabled in yaacc, it should also send an SSDP advertisement packet at start-up.
Closed whatamesss closed 8 months ago
whatamesss
commented
8 months ago ps: if the server mode is enabled in yaacc, it should also send an SSDP advertisement packet at start-up.
tobexyz
commented
8 months ago Hi @usemore, thank you for your issue. To be honest I have also sometimes problems finding devices. Years ago I added a button for an explicit update, which sometimes works. I never really cared about it because it's only sometimes a problem with my devices. Maybe you find the root cause now, great! I'll have to take take a look how to send such packages...
whatamesss
commented
8 months ago that's encouraging @tobexyz! i'm happy to be of any assistance...just reach out. i like the button, however it doesn't initiate any packets either...i think it only refreshes the list of services if yaacc has already learned of those services through advertisements from the server but isn't yet showing them.. a couple things to keep in mind: i'm not using ipv6 at all. there may (but shouldn't?) be an interplay with igmp here....it seems the only way for me to reliably send discovery packets from my phone is to turn the wifi off, then back on, then launch kodi. works every time. kodi does not send the packets however, if after refreshing the interface i first launch yaacc
tobexyz
commented
8 months ago Hi, if just take a look in the code. If a search is triggered an SSDP discovery package will be send in line
You can see the corresponding log message in log with level verbose:
`22:38:48.996 31483-31513 de.yaacc V M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Content-Length: 0 MAN: "ssdp:discover" MX: 2 ST: urn:schemas-upnp-org:device:MediaServer:1
22:38:49.024 31483-31513 de.yaacc V M-SEARCH * HTTP/1.1 Host: 239.255.255.250:1900 Content-Length: 0 MAN: "ssdp:discover" MX: 2 ST: urn:schemas-upnp-org:device:MediaServer:1`
Maybe there is something wrong with the data in the request or UDP packages are blocked for some reason? Do you have a clue?
tobexyz
commented
8 months ago Another idea about the behaviour: Maybe the app should send the discovery requests more often? But if that's the problem your device would appear, if you manually start the search using the update button...
whatamesss
commented
8 months ago hi tobe....i've been able to confirm from both ends (this time with the pcapdroid app) that the discovery packets are not sent. starting yaacc, or hitting the refresh button does not generate any traffic at all. once the dlna server has been discovered (through the advertise packets from the server) hitting the refresh button generates unicast connections to the SERVICES themselves.....no multicast packets are sent.
BUT THEN....after messing around a bit i was able to see the proper 239.255.255.250:1900 packets coming from yaacc....not sure what the factors are! still looking into it
whatamesss
commented
8 months ago it seems that if i start fresh, kill yaacc (because it hangs around in the background after exiting) then refresh the wifi interface, then launch yaacc.....it generates the correct packets! they are seen by the server, which seems to respond, however the services are not detected by yaacc...even after hitting the refresh button. nothing.
trying this a second time (same procedure) ...no packets are generated....yaacc goes silent. i'm at a loss :-[
ps: not entirely silent...it does send two group request packets which leads me back to an igmp problem?
10.10.10.45 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]
10.10.10.45 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 to_ex { }]i'm further able to confirm that when the packets are generated by yaacc, they are reaching minidlna as intended (using strace -e trace=network) ...but still encountering the same issue where the packets are often not generated. the same issue is now also apparent when using kodi....so strange.
"ip addr add 239.255.255.250/32 dev eth0 autojoin" makes no difference :-[
tobexyz
commented
8 months ago Hi @usemore , maybe we are getting closer:
The search is triggered by this method: https://github.com/tobexyz/yaacc-code/blob/70164d4ad3e651047a65b557b6b94579e0df9934/yaacc/src/main/java/de/yaacc/upnp/UpnpClient.java#L714
Which is called in three cases:
The AndroidUpnpService will be created during initialization of the UpnpClient: https://github.com/tobexyz/yaacc-code/blob/70164d4ad3e651047a65b557b6b94579e0df9934/yaacc/src/main/java/de/yaacc/upnp/UpnpClient.java#L145
That's all, so if yaacc is started a search call should be triggered, but only once! Afterwards the search is only triggered during manual pushing the refresh button.
I think the app should maybe trigger the search periodically.
What I understand so far... I'm still wondering why the server respond is not recognized by yaacc and why you always have to reinitialize your wifi interface...
tobexyz
commented
8 months ago If I stop/start wifi I saw this message in the logs:
22:41:40.856 2554-2554 de.yaacc I Joining multicast group: /239.255.255.250:1900 on network interface: wlan0
Therefore I thing the igmp will be used. The setup code is located here
And an quite interesting comment on this line about lost possibly lost packages https://github.com/tobexyz/yaacc-code/blob/70164d4ad3e651047a65b557b6b94579e0df9934/yaacc/src/main/java/org/fourthline/cling/transport/impl/MulticastReceiverImpl.java#L81
The main receiving loop for multicast packages is located here
In that method there are some log outputs maybe they could help you to figure out why the respond of the server got lost. There is an catch block for ignoring an UnsupportedDataException for example maybe your server sends an respond yaacc is not aware of?
whatamesss
commented
8 months ago Tobe...i do appreciate all of your help in this matter, however, it seems at this point that DLNA is for all(my) intents and purposes sadly just dead. it's not just your app, which is certainly the best offering on f-droid for this purpose, but the entire ecosystem seems broken with no will to fix it. after several years of stuggling with a DLNA home entertainment system, i've finally jumped ship to MPD. Despite the learning curve, in the course of one day, i've pretty much got everything working as i wanted...snapcast is really what i needed all along!
cheers brother and valiant effort!
ildar
commented
8 months ago Hi! I'd agree that DLNA is kinda old and badly supported nowadays. But MPD doesn't show videos, does it? I use Yaacc daily: watching movies on a dumb TV with a dongle (AnyCast family). So DLNA isn't dead yet for me. Thanks Tobe!
(my setup is AnyCast, Rygel on a PC and low- and mid-res videos)
tobexyz
commented
8 months ago Hi guys, thanks for your feedback. It helps improving the app! Form my point of view after a decade working on Yaacc I could say I work on it for different reasons:
So in conclusion I'll go one and maintain Yaacc even if DLNA and UPNP are nearly dead. I'm very happy that Yaacc is used by others. Feedback and help of any kind is always welcome!
According to this issue I think we should give it a try to debug a little bit more. Maybe we will find a solution. I'm using Gerbera without problems. @usemore you use minidlna, right? I could spawn one in my network and take a look what's happened.
It might be useful to start a discuss on this project to collect the tooling which is working well and which makes problems?
tobexyz
commented
8 months ago I tested minidlna in my network and it appeared immediately and was accessible. Therefore I think there is nothing special about the server. I did a little fix, too. Now the app is sending periodically ssdp:discovery packages. You can set the duration using the setting for the alive notification duration. For testing I reused that setting. The server does not need to be enabled.
You can test the fix either using the attached debug version of the app or you can build the branch feat/issue103 on your own.
whatamesss
commented
8 months ago hi guys, i've already shut down my DLNA stuff..and i wasnt using it for video...but here's why i love MPD: -latency control over each endpoint, giving me a working whole-home audio setup. -static server ip configuration (this would help yaacc enormously!!) ..the control points instantly connect to the server. -quiet database!! minidlna was always rebuilding and complaining about errors in the files or tags
..i was using rygel as well to share my pc's audio with other devices...no longer needed as mpd can do this
whatamesss
commented
8 months ago closing issue
Love yaacc when it works, however i've been struggling with it for months now (2 different versions on 2 different android abis) as it does not immediately find the services on my network...sometimes for frustratingly long periods. i've done much debugging to get to the root of the problem.
What i've learned through packet capture is that yaacc never sends SSDP disocvery packets to learn about services on the network.
at launch, the only packets sent are IGMP membership joins, which aren't necessary in my unrouted ipv4 network. what should be sent is an SSDP M-SEARCH discovery packet to 239.255.255.250:1900 but this packet is never sent, instead yaacc is forced to wait for advertisement packets from the running services....which, depending on configurations, can be a long time.
as a control-point, yaacc should immediately find its server.....an example of a working upnp control point is kodi.
i would love to see yaacc fixed, unfortunately i cant submit any code to do so...hope you can figure it out! cheers, j