Fehlermeldung beim Umschalten auf Unicast-Sender mit FRITZBox

Sooo… ich glaub wir haben einen einen kleinen Durchbruch mit Blues Unicast Problem :slight_smile:

In seinen Traces konnte man sehen, dass im Fehlerfall im SETUP Request ein anderer Client-Port genannt war, als in der Antwort des Servers. Und damit kommt der 401er wohl nicht klar, jedenfalls schickt er dann nicht die benötigten NAT-Pakete los, damit der Server ihm Daten schicken kann und fordert das PLAY auch nicht an.

Spannend ist dann aber der Blick auf den Trace im WAN, denn dort sind die Ports die gleichen. Oder anders ausgedrückt, der Router schreibt den SETUP Request offenbar um. Das macht er aber nur dann, wenn der genannte Port bereits bei ihm belegt ist und das ist der Fall, wenn der andere Receiver zufällig den gleichen Port benutzt. Und das ist gar nicht sooo unwahrscheinlich, da die Receiver scheinbar nach dem Einschalten immer mit Port 3160 beginnen und dann hochzählen. Wenn man beide Receiver also gleichzeitig einschaltet und einigermaßen gleichhäufig auf Unicast-Kanäle schaltet, sind die immer im gleichen Port-Bereich unterwegs. Und das ist auch der Grund, warum wir das bisher wahrscheinlich noch nicht hatten, weil zumindest ich immer den Zweitreceiver nur zum Test eingeschaltet hatte und der Hauptreceiver schon länger lief. Ausserdem ist das höchstwahrscheinlich auch ein fritzbox Thema, das muss ich bei Gelegenheit aber noch mal mit einem Speedport gegentesten.

Vielleicht noch ein Beispiel zur Verdeutlichung:
LAN, Receiver 1 frisch nach dem Einschalten, Wechsel auf Unicast

SETUP rtsp://87.141.220.115:554/url RTSP/1.0
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160 

RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160;source=87.141.220.115;server_port=32154-32155;ssrc=2604190
x-NAT:on

Wie man sieht sagt der Client client_port 3160 und vom Server bekommt er den gleichen Port wieder genannt.
LAN, Receiver 2 frisch gestartet, schaltet auf einen Unicast Kanal

SETUP rtsp://87.141.220.115:554/url
...
Transport: MP2T/RTP/UDP;unicast;client_port=3160

RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203

So, wie man sieht will der 2. Receiver auch den Port 3160 nutzen, vom Server kommt dann aber client_port=61002 zurück.
Zuerst dachte ich: ist der Server dumm oder was, warum ändert der den Client Port, damit hat er doch nichts zu tun. Des Rätsels Lösung findet sich aber, wenn man sich die gleichen Pakete nicht im LAN, sondern WAN anschaut:

SETUP rtsp://87.141.220.115:554/url RTSP/1.0
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002

RTSP/1.0 200 OK
...
Transport: MP2T/RTP/UDP;unicast;client_port=61002;source=87.141.220.115;server_port=32214-32215;ssrc=2604203

Hier sieht man nämlich, dass das Paket, das zum Server geht, plötzlich den Port 61002 nennt. Sprich die Fritzbox hat den client_port einfach geändert, macht das aber nicht bei der Antwort des Servers. Denn eigentlich müsste beim Server das Paket wieder mit client_port=3160 ankommen.

So und damit kommen wir zum Fazit:
Die Fritzbox erkennt, dass der Port bereits belegt ist und ändert ihn ab, allerdings nur beim Request, nicht bei der Antwort. Daher kann man dem MR eigentlich keinen Vorwurf machen. Der wird vermutlich eine Verbindung mit dem Port suchen, aber nicht finden und den Stream deshalb nicht mehr finden.
Nichtsdestotrotz sind natürlich mehrere Dinge denkbar, denn damit kommen wir zum Thema, warum der 400er das nicht hatte. Leider hab ich auch gerade keinen 400er da, das muss ich noch nachholen, es ergeben sich aber mehrere Varianten damit umzugehen:

  • evtl beginnen die 400/200er nicht mit dem gleichen Startport sondern wählen diesen zufällig, das senkt das Risiko erheblich, löst das Problem aber auch nicht zu 100%
  • evtl ist den 400/200ern der Client-Port, den ihnen der Server nennt schlicht egal. Wenn ich eigene TCP Verbindungen pro Kanal mache, kann ich auch anhand des Sockets über den die Antwort reinkommt, die Antwort der Anfrage zuordnen.

Und das wären dann wohl auch die beiden “Workarounds”, die beim 401er denkbar wären. Das eigentliche Problem ist imho aber die Fritzbox, die in der einen Richtung ein NAT macht, in der anderen aber nicht.

4 „Gefällt mir“

Das heißt, jeder der ne Fritzbox hat, könnte das nachstellen und auch die Probleme haben?

Kann es dann eben doch die Ursache sein, daß er zwei 401er hat und nicht einen 401 und einen 201?

Ob es jede Fritzbox bzw. jede Software Version betrifft weiss ich nicht. Aber ich mit meiner 7490 konnte es jedenfalls nachstellen und damit haben wir neben der 7590 schonmal 2 Modelle :slight_smile:

Wer will, noch mal wie es geht:
Beide Receiver ausschalten - per Netzschalter. Vorzugsweise auf einen Non-Unicast Kanal oder wenn man nen Trace machen will am besten auf „Meine Aufnahmen“. Beide einschalten. Dann Receiver 1 auf nen Unicast Kanal schalten, z.B. 126 BBC SD - das funktioniert. Dann den 2. Receiver auf nen Unicast Kanal schalten, z.B. 128 CNN - dann kommt kein Bild, die Fehlermeldung und nach einigen Sekunden (wenn der MR es ein weiteres Mal probiert und den nächsthöheren Port benutzt) kommt das Bild dann.

Ich hab zwar auch mit 2x 401ern getestet, aber würde mich wundern, wenn sich ein 201 anders verhält. Kann ich aber auch noch mal ausprobieren.

2 „Gefällt mir“

Also… ich habe auch zwei MR401 und eine Fritz!Box 7590, ich habe diese Probleme nicht.

Ooops, ungenau ausgedrückt… mir sind bisher noch keine Probleme aufgefallen, ich werde nachher mal den von Grinch beschriebenen Test machen.

1 „Gefällt mir“

Soviel Einsatz fürs Forum und das bei diesem Wetter, das ist „weltmeisterlich" :+1:

2 „Gefällt mir“

Die Frage wäre nun was man machen kann, damit dieser Fehler nicht mehr auftritt.

So wie das klingt glaube empfiehlt dir Grinch mal einen anderen Router zu TESTEN

Wenn ich AVM anschreibe ist die Frage, ob die damit was anfangen können.

Update:
Also ich kann es jetzt bestätigen. Auf dem 1. Receiver Kanal 126, dann auf dem 2. MR auf 128 geschaltet… Bild bleibt einige Sekunden stehen, danach kommt die Fehlermeldung, dass der Inhalt nicht abgespielt werden kann und kurz danach kommt dann doch das Bild.

Ist mir noch nie aufgefallen, ich schaue wohl so gut wie keine Unicast Sender.

1 „Gefällt mir“

Oder testweise einen 401er durch einen 201er ersetzen.

Es passiert auch oft, dass das Bild kurz doch kommt, aber dann nach ein paar Sekunden einfriert und oben „Wiedergabe nicht möglich“ steht.

Ehrlich gesagt bin ich froh darüber, dass nun mehrere Leute das ganze reproduzieren können.

Stellt sich nun die Frage ob es mit einem Smart oder so immer noch so ist. Mein Smart usw. ist bei der Verwandschaft und wird da genutzt :frowning:

Oder welche Firmware nutzt ihr denn auf der Fritzbox? Bestimmt die letzte Final oder?

Ehrlich gesagt will ich keinen Speedport. :confused: Und hab 2 MR 401, weil es die 201er nicht in weiß gibt.

Und ja. Die letzte Final.

1 „Gefällt mir“

Ok, mit der letzten Inhaus ist es auch so. Nun stellt sich halt nur die Frage. Ist das nur bei Fritzbox so oder auch bei anderen Routern?

Ich habe gerade nur den Zweitreceiver laufen und hatte das Problem wieder. Obwohl der Hauptreceiver aus ist und keine Aufnahme programmiert war. Eventuell tritt der Fehler auch teilweise auf, wenn man von Unicast auf Unicast schaltet

Ich weiß nicht wie es bei 2 MR 401 ist, aber bei Wiedergabe auf 201 nimmt der MR 401 für Timeshift ja den Sender auf, also ist der Hauptreceiver in dem Sinne nicht aus?

Bzw der Hauptreceiver ist im Standby wollte ich damit sagen. Die Nutzung zweier 401er dürfte genauso sein wie mit 401 und 201.

1 „Gefällt mir“

Ich meinte damit nur, dass es eigentlich genauso ist, als würden beide laufen, zumindest bis 30 Sek. nach dem Umschalten. Aber kann @Grinch mit Sicherheit besser klären.

Stimmt genau. Wenn der Hauptreceiver im Standby ist und genug Bandbreite frei ist, dann folgt der Hauptreceiver den anderen Receivern und speichert das im Timeshift Buffer. So kann man auf den anderen Receivern auch jederzeit Timeshift zurück bis zum Umschalten (-30 sek) nutzen.
Mir wäre auch kein Unterschied zwischen 2x401 und 401+201 bekannt. Bei Mediaroom wurde wenn vorhanden die Platte für lokalen Timeshift genutzt, bei 400 und 401 ist das nicht so. Und um es noch komplizierter zu machen, die 400/200er machen das mit dem Timeshift auch anders. Da folgt der Hauptreceiver nicht sondern der Zweitreceiver lädt den Stream zusätzlich auf den Hauptreceiver hoch.
Die Details dazu hab ich mal hier beschrieben: https://iptv.blog/artikel/entferntes-abspielen/