Hinzugefügter Lautsprecher bricht Wiedergabe ab

Hallo @Ezeqeel,

erst einmal herzlich Willkommen in der Community.

Kannst du hier, wenn der Fehler aufgetreten ist, eine Diagnose erstellen und dich dann mit der Bestätigungsnummer im Support melden.

Viele Grüße

Sven

Hallo,

ich wollte vorhin den Fehler nachstellen für die Diagnose. Dabei war es nicht einmal mehr möglich einen Lautsprecher dem Master hinzuzufügen.

Der Support meinte, ich soll mein Netzwerk reduzieren und dann nochmal testen.

Ich habe die Netzwerkkommunikation mit Wireshark mitgeschnitten. Folgender Ablauf zeigt sich:

Wenn ich einen Lautsprecher hinzufügen will schickt der Master an den Slave:

Hypertext Transfer Protocol
    POST /MediaRenderer/AVTransport/Control HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST /MediaRenderer/AVTransport/Control HTTP/1.1\r\n]
            [POST /MediaRenderer/AVTransport/Control HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: /MediaRenderer/AVTransport/Control
        Request Version: HTTP/1.1
    CONNECTION: close\r\n
    ACCEPT-ENCODING: gzip\r\n
    HOST: 192.168.13.43:1400\r\n
    USER-AGENT: Linux UPnP/1.0 Sonos/70.4-36090 (ZPS14)\r\n
    X-Sonos-Corr-Id: ed298918-362b-4faf-8587-4a7bed18c548\r\n
    CONTENT-LENGTH: 375\r\n
        [Content length: 375]
    CONTENT-TYPE: text/xml; charset="utf-8"\r\n
    X-SONOS-TARGET-UDN: uuid:RINCON_B8E937546E0C01400\r\n
    SOAPACTION: "urn:schemas-upnp-org:service:AVTransport:1#SetAVTransportURI"\r\n
    \r\n
    [Full request URI: http://192.168.13.43:1400/MediaRenderer/AVTransport/Control]
    [HTTP request 1/1]
    [Response in frame: 61389]
    File Data: 375 bytes
eXtensible Markup Language
    <s:Envelope
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body>
            <u:SetAVTransportURI
                xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
                <InstanceID>
                    0
                    </InstanceID>
                <CurrentURI>
                    x-rincon:RINCON_48A6B832EC6E01400
                    </CurrentURI>
                <CurrentURIMetaData>
                    </CurrentURIMetaData>
                </u:SetAVTransportURI>
            </s:Body>
        </s:Envelope>

Der Slave antwortet:

Hypertext Transfer Protocol
    POST /GroupManagement/Control HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST /GroupManagement/Control HTTP/1.1\r\n]
            [POST /GroupManagement/Control HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: /GroupManagement/Control
        Request Version: HTTP/1.1
    CONNECTION: close\r\n
    ACCEPT-ENCODING: gzip\r\n
    HOST: 192.168.13.41:1400\r\n
    USER-AGENT: Linux UPnP/1.0 Sonos/70.4-36090 (ZPS1)\r\n
    X-Sonos-Corr-Id: 2c1447b4-e9d8-42b3-804e-55f035a68aa1\r\n
    CONTENT-LENGTH: 305\r\n
        [Content length: 305]
    CONTENT-TYPE: text/xml; charset="utf-8"\r\n
    X-SONOS-TARGET-UDN: uuid:RINCON_48A6B832EC6E01400\r\n
    SOAPACTION: "urn:schemas-upnp-org:service:GroupManagement:1#AddMember"\r\n
    \r\n
    [Full request URI: http://192.168.13.41:1400/GroupManagement/Control]
    [HTTP request 1/1]
    [Response in frame: 61384]
    File Data: 305 bytes
eXtensible Markup Language
    <s:Envelope
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body>
            <u:AddMember
                xmlns:u="urn:schemas-upnp-org:service:GroupManagement:1">
                <MemberID>
                    RINCON_B8E937546E0C01400
                    </MemberID>
                <BootSeq>
                    109
                    </BootSeq>
                </u:AddMember>
            </s:Body>
        </s:Envelope>

Darauf antwortet der Master mit einem UPNP Error 803:

Hypertext Transfer Protocol
    HTTP/1.1 500 Internal Server Error\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 500 Internal Server Error\r\n]
            [HTTP/1.1 500 Internal Server Error\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 500
        [Status Code Description: Internal Server Error]
        Response Phrase: Internal Server Error
    CONTENT-LENGTH: 347\r\n
        [Content length: 347]
    CONTENT-TYPE: text/xml; charset="utf-8"\r\n
    EXT: \r\n
    Server: Linux UPnP/1.0 Sonos/70.4-36090 (ZPS14)\r\n
    Connection: close\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.001091000 seconds]
    [Request in frame: 61382]
    [Request URI: http://192.168.13.41:1400/GroupManagement/Control]
    File Data: 347 bytes
eXtensible Markup Language
    <s:Envelope
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body>
            <s:Fault>
                <faultcode>
                    s:Client
                    </faultcode>
                <faultstring>
                    UPnPError
                    </faultstring>
                <detail>
                    <UPnPError
                        xmlns="urn:schemas-upnp-org:control-1-0">
                        <errorCode>
                            803
                            </errorCode>
                        </UPnPError>
                    </detail>
                </s:Fault>
            </s:Body>
        </s:Envelope>

Das beantwortet der Slave mit einem UPNP Error 501:

Hypertext Transfer Protocol
    HTTP/1.1 500 Internal Server Error\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 500 Internal Server Error\r\n]
            [HTTP/1.1 500 Internal Server Error\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 500
        [Status Code Description: Internal Server Error]
        Response Phrase: Internal Server Error
    CONTENT-LENGTH: 347\r\n
        [Content length: 347]
    CONTENT-TYPE: text/xml; charset="utf-8"\r\n
    EXT: \r\n
    Server: Linux UPnP/1.0 Sonos/70.4-36090 (ZPS1)\r\n
    Connection: close\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.132368000 seconds]
    [Request in frame: 61377]
    [Request URI: http://192.168.13.43:1400/MediaRenderer/AVTransport/Control]
    File Data: 347 bytes
eXtensible Markup Language
    <s:Envelope
        xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body>
            <s:Fault>
                <faultcode>
                    s:Client
                    </faultcode>
                <faultstring>
                    UPnPError
                    </faultstring>
                <detail>
                    <UPnPError
                        xmlns="urn:schemas-upnp-org:control-1-0">
                        <errorCode>
                            501
                            </errorCode>
                        </UPnPError>
                    </detail>
                </s:Fault>
            </s:Body>
        </s:Envelope>

Beide versuchen die Gruppierung dann nochmal mit genau dem gleichen Ablauf. Danach schicken sie sich einen /notify, wahrscheinlich um sich noch einmal ihre Gerätedaten zu schicken, das wird auch brav bestätigt. Danach ist Schluss.

Leider findet man nichts zu dem UPNP Error 803 im Netz.

Um meine Infrastruktur auszuschließen, habe ich eben einen One via SonosNet mit der Beam verbunden. Auch hier treten beide Fehler auf. Entweder der One wird gar nicht der Gruppe hinzugefügt, oder nach kurzer Zeit spielt er aber nicht mehr.

@Ezeqeel, wenn ich es recht verstehe, haben Sie (mit Ausnahme eines One) einen reinen LAN-Betrieb.

• Tritt dieses Verhalten nur bei der Gruppenwiedergabe auf? Die Komponente / das Stereopaar von dem aus man eine Gruppe zusammenstellt, fungiert als Gruppenkoordinator, der die “Arbeitslast” in der Gruppe trägt. Wenn es zu Aussetzern/Ausfällen kommt, die Gruppe auflösen und von einem anderen Speaker ausgehend neu zusammenstellen
• Unter welchen Umständen kommt es dazu? Bei bestimmten Quellen wie TV, ein bestimmter Radiosender, ein bestimmter Dienst, Sprachsteuerung, Airplay 2 etc.? 
• Was verstehen Sie unter Multicasting?
• Ist der Cisco-Switch richtig konfiguriert?

Hallo @Hedy L. ,

ja genau, bis auf einen One sind schon immer alle Lautsprecher per LAN Kabel angebunden, und WIFI ist deaktiviert.

Die Einstellungen des Cisco Switches habe ich eben noch einmal überprüft. Die sind wie in der Anleitung beschrieben. Der Switch agiert auch als IGMP Querier, ich sehe also die Multicast Gruppe für SSDP, über die sich die Lautsprecher austauschen. Auch die mDNS Kommunikation sehe ich.

Der Fehler tritt bei Verwendung unterschiedlichster Quellen auf. Spotify, Deezer und TuneIn Radio habe ich in den letzten Tagen getestet. Überall das gleiche Verhalten.

Jeder Lautsprecher einzeln betrieben funktioniert wunderbar über Stunden. Deshalb würde ich auch die Internetverbindung oder die grundlegende Netzwerkverbindung der Lautsprecher ausschließen. Wenn ich aber einen oder mehrere Lautsprecher zu einer Gruppe zusammenfüge, kommt die Gruppe schon gar nicht zustande, oder die Lautsprecher fallen nach wenigen Minuten wieder aus der Gruppe heraus. Dabei hören sie zuerst auf zu spielen, werden in der App aber noch als in der Gruppe angezeigt.

Die oben erwähnte Kommunikation zwischen den beiden Lautsprechern ist in der Tat kein Multicast, sondern Unicast Verkehr. Sorry! Die beiden Lautsprecher sprechen also direkt miteinander über das Netzwerk um die Gruppe aufzubauen.

Über die Seite /status/zp der Lautsprecher konnte ich eben noch herausfinden, dass das letzte Update am 09.12.2022 installiert wurde. Das passt sehr genau zu meinem Eindruck, dass der Fehler seit Anfang Dezember auftritt.

Für mich sieht es so aus, als könnte der Gruppenkoordinator die Gruppe nicht erstellen. Er antwortet ja sogar mit einer Fehlermeldung “HTTP 500 Internal Server Error” und dem wahrscheinlich etwas spezifischeren “UPNP Error 803”.

Ich wüsste aber nicht, was da schief gehen soll. Alle Lautsprecher sind im selben VLAN, eine Firewall oder ähnliches kann da also nichts blockieren. Bei der Verbindung über das SonosNet ist der Weg ja noch kürzer zwischen den Lautsprechern.

Danke!

@Ezeqeel, betreiben Sie das System auf S1 oder S2?

Das sind häufig Fehler, die bei falscher Konfiguration des Routers oder Switches auftreten. Ist ein Defekt einer der beteiligten Netzwerkkomponenten ausgeschlossen? Haben Sie schon die Ethernetkabel getauscht?

Das tritt eigentlich nur im WLAN-Betrieb auf. LAN/Ethernet ist die stabilste Verbindung überhaupt, weshalb ich auf die beteiligten Netzwerkkomponenten tippe.

Sie schreiben oben, dass IP-Konflikte ausgeschlossen seien. Zuerst die beteiligten Netzwerkkomponenten, gefolgt von allen Sonoskomponenten, neu zu starten, schadet dennoch nicht.

So viel ich mitbekommen habe, arbeitet die Entwicklung fortwährend an der Stabilität des Systems im WLAN-Betrieb. Ein Programmfehler ist demnach nicht gänzlich ausgeschlossen, aber a) hätten wir in dem Falle das Forum voll mit aufgeregten Kunden, b) betreiben Sie Ihr System über LAN, fallen somit eigentlich aus der “gefährdeten” Gruppe raus.

Ich wüsste aber nicht, was da schief gehen soll. Alle Lautsprecher sind im selben VLAN, eine Firewall oder ähnliches kann da also nichts blockieren. Bei der Verbindung über das SonosNet ist der Weg ja noch kürzer zwischen den Lautsprechern.

Unter Konfiguriere deine Firewall für die Verwendung mit Sonos finden Sie alle für den Betrieb von Sonos essenziellen Ports, gehen Sie die Supportseite einmal durch.

Ansonsten kann ich bloß noch auf den Beitrag von @Sven T. verweisen: Wenn die Gruppe das nächste Mal ausfällt/auseinanderbricht, setzen Sie bitte innerhalb von 15 Minuten eine Diagnose ab, notieren sich die Bestätigungsnummer und telefonieren mit dem Support, sobald Sie einmal zwei Stunden Zeit haben -- sollte eine Fernwartung notwendig sein.

genau, und danach müsste der Gruppen-Master/Koordinator eigentlich beginnen den Stream an eine MC-Gruppenadresse zu senden, welche dann wiederum von den Gruppen-Member(n) abonniert wird.

Ich denke genau bei diesem letzten Schritt hast Du irgend ein Problem in Deinem VLAN !?

Könnte es sein dass Dein Switch solche Pakete an MC-Gruppenadresse einfach dropped oder das IGMP-Snooping nicht korrekt funktioniert ?!

Hallo,

jetzt komme ich endlich dazu eine Antwort zu schreiben.

Nachdem diverses Neustarten nicht funktioniert hat, hab ich alle Sonos ausgeschaltet, und das IGMP auf dem Cisco Switch rauskonfiguriert.

Dann das IGMP wieder konfiguriert. Ist bei mir nur das hier, manches ist eh schon default:

ip igmp snooping

ip igmp snooping querier

ip igmp snooping querier version 2

no ip igmp filter

Danach alle Sonos wieder eingeschaltet, und siehe da, es funktioniert wieder.

Auf dem Cisco Switch sieht man per 
show ip igmp snooping groups

welche Multicast Adressen von welchen Geräten (an den Switchports) verwendet werden.
Die Adresse 239.255.255.250 ist das für Sonos Geräte.

Was letztendlich das Problem war, weiß ich nicht. Ich tippe aber mal auf das IGMP snooping im Switch. Um genau zu sein muss der Switch als querier agieren. Das Snooping ist per default eh aktiv, glaube ich.

Danke auf jeden Fall für die Hilfe und Tipps!