CiNcH Posted November 26, 2015 Share Posted November 26, 2015 Ich hatte ja sowas ähnliches mit dem UPnP Controller... - RS und lokaler DVBViewer RTSP Client auf einem PC im WLAN - Notebook im WLAN, das medientechnisch eigentlich nur ab und zu für Tests herhalten muss (mit in Windows 7 deaktiviertem Media Sharing/UPnP) Wenn nun beide liefen und ich dann das Notebook abschaltete, hing der RS, bzw. ließ sich das Web-If nicht mehr wirklich bedienen. Antworten vom RS dauerten ewig. Abdrehen ließ er sich auch nicht mehr wirklich, bzw. dauerte auch das ewig. Ich habe dann einfach den UPnP Controller wieder deaktiviert. Ich denke, das könnte ich wieder reproduzieren. Ob die Probleme miteinander verwandt sind, weiß ich nicht. UPnP Controller ist in den RS Settings ja sowieso als "experimentell" deklariert und standardmäßig deaktiviert... Ich hatte es bemerkt, weil in KODI ein Locking-Bug drin war, der bei langen Web-If Antwortzeiten vom RS auch den Stream unterbrochen hat. Aber auch, weil die iOS App nicht mehr bedienbar war. Ich fürchte ja, wenn man so die UPnP Geschichte im Forum verfolgt hat, dass da noch einige Leichen im Keller begraben liegen... Link to comment
Griga Posted November 26, 2015 Share Posted November 26, 2015 Ich hatte ja sowas ähnliches mit dem UPnP Controller... Der ist es. Bei mir war er aktiv, und ich kann es reproduzieren. Der RS will sich beim Beenden abmelden (Unsubscribe), und wenn die Gegenseite nicht mehr vorhanden ist, versucht er es vergeblich mit einem längeren Timeout. Was man zweckmäßigerweise an welcher Stelle dagegen unternimmt, ist mir noch nicht klar. Die Spur führt über mehrere Aufrufebenen in eine der Netzwerkbibliotheken. Eigentlich müsste ja auch der UPnP Server am anderen Ende Bescheid sagen, bevor er unerreichbar wird... Link to comment
CiNcH Posted November 26, 2015 Share Posted November 26, 2015 Interessant auch die Frage, wieso der RS auch im Betrieb so träge wird, wenn die Gegenseite nicht mehr vorhanden ist. Jedenfalls war das bei mir so. Problem war nicht nur das Beenden... Link to comment
Griga Posted November 29, 2015 Share Posted November 29, 2015 Interessant auch die Frage, wieso der RS auch im Betrieb so träge wird, wenn die Gegenseite nicht mehr vorhanden ist. Das konnte ich bislang nicht nachvollziehen. Das Hängen beim Beenden entsteht durch zwei von UPnP Controller-Objekten via HTTP an den verschwundenen Server-RS gesendeten "Unsubscribe"-Botschaften. In beiden Fällen wird das Standard-Connection Timeout der (System-)Socket-Implementation verwendet. Da der Vorgang ca. 40 Sekunden hängt, dürfte dieses Timeout bei mir 20 Sekunden betragen. Abhilfe ist möglich, indem ich das Timeout beim Beenden auf eine halbe Sekunde beschränke. Damit kuriere ich jedoch nur ein Symptom, nicht die eigentlich Ursache. Der UPnP Server sollte sich nämlich zuvor mit einem Bye Bye Multicast abgemeldet haben, und dann unterbleibt auch das Unsubscribe. Das Bye Bye kommt jedoch nicht an - ob das an der UPnP Client- oder Server-Implementation liegt, weiß ich noch nicht. Fazit: Wer ihn nicht unbedingt braucht, sollte den experimentellen UPnP Controller im RS deaktiviert lassen. Link to comment
t5b6_de Posted December 27, 2015 Author Share Posted December 27, 2015 Kleine Rückmeldung zu Version 1.32, bisherige Probleme wurden alle behoben. Auch bestimmte Probleme beim ansprechen einiger Plugins wurden behoben. Link to comment
Recommended Posts