Morjen,
ich habe jetzt Debug auf 1 gesetzt
es hat aber leider nicht funktioniert.
Guck nochmal
hier. Da siehst Du, dass alle Logzeilen DEBUG enthalten. Keine Ahnung warum das nicht geklappt hat.
Ohne IP oder sonstige Infos kann ich da gar nicht weiter forschen.
Da hast Du recht. Aber mit debug sehen wir genau das. Während normalerweise mit der Logzeile ...handleonce" die Verarbeitung an das Paket perlupnp weitergereicht wird, auf das ich keinen Einfluss habe(begrenzt), wird bei debug die Verarbeitung(read, Prüfung IP, Output des read buffers) im Modul gemacht.
Naja vielleicht setze ich Verbose einfach auf 0 und dann sollte hoffentlich Ruhe sein.
Fänd ich nur die zweitbeste Lösung. Besser ist ja für die SIRDs festzustellen, was da genau geschickt wird, um es dann zu ignorieren oder korrigieren.
wenn ich im Browser einfach eine IP eines der 3 Geräte angebe, dann kommt genau diese Webseite bzw. der HTML Code
Was darauf schließen lässt, dass in LOCATION die presence-URL und nicht die description-URL steht.
Lösch mal Deinen Anhang. Steht ja ne Menge "Persönliches" drin. In der /opt/fhem/FHEM/lib/UPnP/ControlPoint.pm könntest Du die Modifikation auch wieder zurückbauen.
Ich guck jetzt nochmal in Dein Log, denn dort sehen wir auch die Antworten der devices. Allerdings auf dem search-port.....
Grüße
Markus
Edit: Ich glaub ich habs. Guck mal ab Zeile 1227 in Deinem Log. Da melden sich offensichtlich 2 SIRDs mit IP:80/device und eins ohne das Unterverzeichnis als LOCATION. Im Browser eingegeben siehst Du dann die html-Seiten. DANACH erst kommen die korrekten Antworten auf den search-request mit der LOCATION IP:8080/dd.xml. Mit denen werden dann auch die readings im UPNPController und die DLNA-devices angelegt.
Ich guck mal genauer, wie ich die "falschen" Nachrichten sinnvoll ignoriere.
Edit2: Spontan ist der Unterschied, dass die xml's auch mit .xml enden. Aber das muss ja nicht immer so sein(bei jeglichen UPNP Geräten). Über die debug-Ausgabe sehen wir vielleicht noch andere "Merkmale".
