[satip] Bug in curl und andere Merkwürdigkeiten

Seit ein paar Monaten habe ich einen "EyeTV Netstream 4Sat" SatIP Receiver mit 4 Empfängern und wollte den mit einem neu aufgesetzen VDR der auf einem odroid-c4 läuft nutzen.

Zuerst hab' ich das SatIP-Plugin probiert, aber das hat nicht wirklich auf Anhieb funktioniert. Da mich das etwas genervt hat hab' ich tiefer gegraben und sogleich einen Bug in curl entdeckt - wenigstens in der Version die ich verwende und die bis jetzt aktuell ist:

https://github.com/curl/curl/issues/12414

Der Bug führt dazu das Rückmeldungen vom SatIP-Receiver nicht vom SatIP-Plugin mit diesen Anweisungen gelesen werden können:

SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_WRITEFUNCTION, NULL);
SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_WRITEDATA, NULL);

Das führte (bei mir) dann zu vielen "Detected invalid status code" Logzeilen. Das hat mich etwas verunsichert ob ich da nicht einen Schrott SatIP Receiver habe der sich gar nicht an die Spezifikation hält. Also hab' ich mir noch die Mühe gemacht die SatIP-Spezifikation anzuschauen und siehe da, die zurückgemeldeten Stati sind ganz und gar nicht invalid

Zudem werden Rückmeldungen zwar ausgewertet im weiteren Programmverlauf aber einfach ignoriert. Mein SatIP-Server sendet wenn eine Verbindung ohne TEARDOWN beendet wurde eine Rückmeldung 503 auf SETUP mit Body "no more sessions". Wegen dem Curl-Bug ist diese nicht ersichtlich dennoch könnte ein "stumpfes" warten von 65 Sekunden dazu führen das die SatIP-Server Resource wieder frei ist.

Auch sonst bin ich auf komische Sachen gestoßen wie z.B.:

SATIP_CURL_EASY_SETOPT(handleM, CURLOPT_RTSP_REQUEST, (long)CURL_RTSPREQ_OPTIONS); // FIXME: this really should be CURL_RTSPREQ_RECEIVE, but getting timeout errors

Das sendet gefühlt wie wild OPTION-Requests.. Wenn ich da wieder CURL_RTSPREQ_RECEIVE eintrage funktioniert das bei mir ganz ohne timeout errors?? Und sendet dann erheblich weniger Requests. Das wäre IMHO als Quirk an- und abschaltbar sehr fein..

Auch wird der Reception Status über DESCRIBE geholt, gleichzeitig das RTCP Announcment ausgewertet:

// Read reception statistics via DESCRIBE and RTCP

Das hätte ich wiederrum auch gern als Quirk an- und abschaltbar. Beziehungsweise ob DESCRIBEs geschickt werden oder nicht oder ob DESCRIBE und/oder RTCP Announcments ausgewertet werden... hab' auf jeden Fall jede Menge Requests im Wireshark gefunden...

Daneben solche Sachen, die habe ich bei mir einfach einkommentiert (und sendet dann auch weniger Requests):

if (!strcmp(*streamParamM, *lastParamM) && hasLockM) {
debug1("%s Identical parameters [device %d]", __PRETTY_FUNCTION__, deviceIdM);
//return true; // fall through because detection does not work reliably
}

Am schlimmsten ist aber die standardmäßige SETUP -> PLAY -> TEARDOWN Schleife bei jedem Kanalwechsel die es (zumindest mit meiner) SatIP-Box nicht braucht .. Das habe ich auch noch extra mit DVBViewer und VLC im Wireshark geprüft, beide verwenden eine wie in der Spezifikation vorgegebene Arbeitsweise (Seite 24, 3.5.1): SETUP -> PLAY -> PLAY [...] und für Keepalive alle 50 Sekunden eine OPTIONS... und nur beim Beenden der Programme oder einem Timeout ein TEARDOWN

Bei Tests mit Aufnahmen wurden bei mir beim Umschalten auf einen Kanal des gleichen Transponders die Aufnahme beschädigt.

[Edit] Ui, gerade gefunden: [Octopus NET Pro und Sat>IP] Aufnahmefehler bei gleichzeitiger Nutzung eines anderen Senders auf dem aufnehmenden Transponder

Desweiteren gab es eine Situation da wurde die SatIP-Box mit Anfragen geflutet weil die zwar 503 zurückgab das SatIP-Plugin aber ständig "draufhämmerte"...

Da mir das Umbauen/Abändern vom Plugin zu anstrengend ist/war habe ich mich mal nach was anderem umgeschaut -> vtuner

Uh, mein Bug-Report in curl wurde geschlossen:

https://github.com/curl/curl/comm…c91d035b41e8bd2

Die Unzulänglichkeit wurde nun dokumentiert und das wars

Mein Aufwand mit extra Fake-Server und -Client Programm zu schreiben um curl-"Gott" bagder davon zu überzeugen das das IMHO ein Bug ist war für den Arsch Da komme ich mir vor wie bei Software von Siemens... ist aber eine andere Baustelle...

Offiziell unterstützt curl eben nur RTSP nach RFC xyz und nicht Sat>IP ... was bedeutet das Fehlerrückmeldungen nun nie vom satip-plugin ausgewertet werden können bis jemand curl dort rausschmeisst... naja.. egal

Quote from SHF

Irgendwie wäre es einfach zu einfach

Ich denke mal das ist so einfach (also in Zeile 265 TRUE auf FALSE setzen), damit wird nur ein optionaler Body gelesen und zurückgeliefert. Frage mich überhaupt warum das explizit unterdrückt werden muss? Es schadet nicht und hat IMHO bei reinen RTSP-Servern keine negative Auswirkung.

Überhaupt gibt es bei keinem SAT>IP-Befehl außer DESCRIBE einen Body, dafür bei den Fehlern 400, 403 und 503 die bei allen SAT>IP-Befehlen außer DESCRIBE auftreten können..

Das ist aber dann nur der Anfang des Problems im satip-Plugin. Dort wird z.B. der von mir erwähnte 503 mit Body "No-more: sessions" zwar ausgewertet:

 if (strstr(r, "No-More:")) {
           char *tmp = NULL;
           if (sscanf(r, "No-More:%m[^;]", &tmp) == 1) {
              errorNoMoreM = skipspace(tmp);
              debug3("%s No-More: %s [device %d]", __PRETTY_FUNCTION__, *errorNoMoreM, tunerM.GetId());
              }
           FREE_POINTER(tmp);
           }

Bei funktionierender CURL-Lib würde es sogar eine Fehlermeldung geben (anstatt dem total irreleitenden invalid status code)

   case 503:
            // SETUP PLAY
            // The message body of the response may contain the "No-More:" parameter followed
            // by a space-separated list of the missing ressources: “sessions” "frontends" "pids
            if (!isempty(*errorNoMoreM)) {
               SATIP_CURL_EASY_GETINFO(handleM, CURLINFO_EFFECTIVE_URL, &url);
               error("No more: %s (error code %ld: %s) [device %d]", *errorNoMoreM, rc, url, tunerM.GetId());
               break;
               }
       default:
            SATIP_CURL_EASY_GETINFO(handleM, CURLINFO_EFFECTIVE_URL, &url);
            error("Detected invalid status code %ld: %s [device %d]", rc, url, tunerM.GetId());
            break;
       }

Leider leider führt das aber nicht dazu das der Tuner-Thread irgendwie damit umgeht:

void cSatipTuner::Action(void)
{
  debug1("%s Entering [device %d]", __PRETTY_FUNCTION__, deviceIdM);
  [...]
  // Do the thread loop
  while (Running()) {
        UpdateCurrentState();
        switch (currentStateM) {
[...]
          case tsSet:
               debug4("%s: tsSet [device %d]", __PRETTY_FUNCTION__, deviceIdM);
               if (currentServerM.IsQuirk(cSatipServer::eSatipQuirkTearAndPlay))
                  Disconnect();
               if (Connect()) {
                  tuning.Set(eTuningTimeoutMs);
                  RequestState(tsTuned, smInternal);
                  UpdatePids(true);
                  }
               else
                  Disconnect();
               break;
[...]
          default:
               error("Unknown tuner status %d [device %d]", currentStateM, deviceIdM);
               break;
          }
        if (!StateRequested())
           sleepM.Wait(eSleepTimeoutMs); // to avoid busy loop and reduce cpu load
        }
  debug1("%s Exiting [device %d]", __PRETTY_FUNCTION__, deviceIdM);
}

Es wird ein Disconnect gemacht und dann alle 250ms erneut drauf gehämmert. Das Log wird geflutet. Mein Satip-Receiver mag das nicht so dolle und kann dann schonmal den Dienst quittieren, was dann nur zu noch mehr Meldungen führt...

Bei vtuner habe ich die "No-More: sessions" durch Zufall selbst erzeugt, in der alten Version des satip-Programms wurde kein Teardown gesendet, d.h. bei jedem Stop das satip-Programms verwaiste die Session. Das habe ich mittlerweile behoben.

Aber: Zusätzlich sollte IMHO grundsätzlich immer bei jedem 503 Service unavailable mindestens 65 Sekunden gewartet werden bis erneut eine Aktion durchgeführt wird (habe ich so im satip Programm umgesetzt). Sollte es sich um eine verwaiste Session handeln wurde diese mittlerweile freigegeben und der neuerliche SETUP geht ohne Fehler durch. Ist einfach kein Tuner mehr verfügbar so wird dann im Endeffekt nur einmal pro Minute geprüft ob ein Tuner frei ist im Gegensatz zur jetzigen Lösung: 240 Mal.

Das würde für das satip-Plugin bedeuten das jemand den Status in die Action-Funktion rausführt und entweder einfach die tsSet-Bearbeitung verzögert oder einen neunen State tsWaitForTuner oder sowas einfügt...

Quote from wirbel

Normal haben SETUP und PLAY keinen body, also sieht der Patch so noch falsch aus.

Das stimmt nicht für Rückmeldungen 400, 403 oder 503 die auch bei SETUP und PLAY kommen können:

Quote from Joe_D

Überhaupt gibt es bei keinem SAT>IP-Befehl außer DESCRIBE einen Body, dafür bei den Fehlern 400, 403 und 503 die bei allen SAT>IP-Befehlen außer DESCRIBE auftreten können