dreamrtspserver hangup

  • Hallo,


    ich schaue von meiner Client-Box (dm525) die meisten Sender als transkodierte Streams, die von meiner Server-Box (dm820) kommen. Das funktioniert im Normalfall super. Leider hängt sich der dreamrtspserver beim zappen immer wieder mal auf. Das monitore ich zwar mit einem Script (wenn er sich aufhängt, gibt es Verbindungen mit Status CLOSE_WAIT und ich starte den Service einfach neu), aber man muss immer ein paar Sek warten und hin und her zappen, bis die Client-Box wieder ein Bild bekommt.


    Jedenfalls nervt mich das so sehr, dass ich mal auf Fehlersuche gegangen bin.


    Das Problem entsteht wie folgt:


    1. Client zappt zu anderem Kanal
    2. Neue Verbindung zu RTSP-Server wird aufgebaut und die alte geschlossen.
    3. Bei jedem 10. bis 20. Zap liefert der RTSP-Server auf einmal kein Bild mehr und schreibt auch gar nichts mehr ins journal. Die neue Verbindung kam aber noch zustande und die alte wurde korrekt geschlossen.
    4. Der Client zappt weiter, weil ja kein Bild kam.
    5. Eine neue Verbindung wird zwar aufgebaut, aber keine Daten werden gesendet. Die alte Verbindung bleibt mit CLOSE_WAIT offen.


    Per GST_DEBUG env kann man im WARN-Level sehen, dass ab Zeitpunkt "3." immer wieder folgende Meldung gesendet wird. Habe zwar mal in den Code von gst-plugin-dreamsource gesehen, aber mir den Quellcode der anderen Projekte noch nicht genau angesehen und zurück verfolgt, wo genau die aufrufende Schleife sich befindet, aber es scheint so, als wenn der dreamrtspserver in einer Schleife versucht einen Zeitwert aus einem Stream, der vorher anscheinend nicht korrekt geöffnet wurde, zu lesen. Da das nicht funktioniert, hängt der Server hier fest und bearbeitet auch weitere Anfragen nicht richtig.



    Code
    0:00:45.387926747 13205 0x75d06e60 WARN        dreamsourceclock gstdreamsource.c:118:gst_dreamsource_clock_get_internal_time:<GstDreamAudioSourceClock> can't ENC_GET_STC error: Inappropriate ioctl for device, fd=13, ret=-1
  • Wenn genannte WARN-Meldung ausgegeben wird, wurde die Funktion aufgerufen durch Zeile 1021 in gstdreamvideosource.c.
    Aber selbst wenn man dort state = READTRREADSTATE__STOP setzt, falls gst_clock_get_internal_timeden Wert 0 zurückgegeben hat, wird die while Schleife zwar verlassen - aber der rtsp-Server hängt immer noch und neue Verbindungen werden nicht vernünftig bedient.

  • Habe heute mal ein bisschen Zeit zum debuggen und testen gehabt und dabei auch gstreamer inkl. plugins etc. auf 1.12.4 geupdated.
    Das Problem tritt auch mit gstreamer 1.12.4 auf und scheint ein deadlock Problem zu sein.


    Und zwar erfolgt in dreamrtspserver.c in der Funktion tsmux_pad_probe_unlink_cb() in Zeile 2379 ein Aufruf von gst_element_set_state (), der unter bestimmten Voraussetzungen nie beendet wird.


    Ich habe die ganze if-Abfrage testweise mal durch folgenden Code ersetzt:



    Code
    gst_element_call_async(source, (GstElementCallAsyncFunc) gst_element_set_state, (gpointer *)((GstState) GST_STATE_NULL), NULL);


    Und voila... Keine Hänger mehr. Ich kann wild hin und her zappen und der dreamrtspserver läuft super durch :)


    Es gibt noch mehrere Stellen, an denen gst_element_set_state aufgerufen wird. Die habe ich zwar jetzt nicht angefasst - aber theoretisch muss jede Stelle angepasst werden, die auf ein element zugreift, auf das auch ein anderer Thread zur gleichen Zeit zugreifen könnte.


    Leider wurde der commit, der gst_element_call_async enthält (https://lists.freedesktop.org/…ts/2016-April/093926.html) erst in Version 1.9.1 aufgenommen. Keine Ahnung, ob das jetzt ein Backport auf 1.6.4 wird oder gstreamer und was noch alles so dazugehört ein Update erhält - aber ich würde mich freuen, wenn ich bald wieder gstreamer und dreamrtspserver vom Feed laufen lassen kann und meine "Frickel-Version", die zwar bis jetzt gut funktioniert, aber nicht alle Features enthält (hatte z.B. keine Lust den udpsrc IGMPv3 patch anzupassen und habe den und andere einfach weggelassen), in Rente schicken kann. :)

  • Die rege Beteiligung hier spricht irgendwie nicht dafür das da in nächster Zeit etwas entscheidendes passiert.
    Wobei ich mich diesbezüglich gerne eines anderen belehren lasse ;)

  • Ah ok, das ist super!
    Wenn Interesse seitens der User besteht, kann ich gern meine .debs für die Zeit bis zum Release des neuen Servers hier hochladen?! Schaffe ich aber micht vor Montag - bin unterwegs.


    @Ghost: Ein Killer-Feature wäre übrigens, wenn man dem rtsp-Server nicht nur srefs als Parameter übergeben kann, sondern auch Datei-Pfade zu lokalen Aufnahmen/Filmen. Ich habe nämlich auf meiner Server-Box einige Filme liegen, die zu gross zum direkten Streamen sind (zu wenig Bandbreite). Die muss ich mir immer entweder vor dem schauen au die Client-Box kopieren oder über das Webinterface den Film auf der Server-Box starten, den rtsp-Server auf Live-TV stellen und darüber streamen. Wenn man in der Url direkt einen Dateinamen zum abspielen übergeben könnte, würde das die Sache extrem vereinfachen. Ist etwas in dieser Richtung geplant?

    • Official Post

    Naja generell geht das auch jetzt schon... eine Aufnahme.. oder eine andere Wiedergabe .. also container mp4 mkv.. avi whatever kann man ja auch einfach als servicereference darstellen.. bzw. werden sie intern ja schon.


    Sieht man ja in den debug ausgaben recht gut.


    Bei Aufnahmen .. also ts wird das auch recht gut funktionieren ... aber wenn man einen container abspielt.. mkv.. mp4.. avi.. dann geht das nur entweder einmal lokal an der box oder streamen.


    cu

  • Auf die Idee, dass man die container als service ref darstellt, bin ich noch gar nicht gekommen. Ich habe erst vor kurzem angefangen mich mit Enigma2-Receivern zu beschäftigen und bin noch lange nicht mit allem vertraut. Werde mir aber die Debug-Ausgaben auf jeden Fall demnächst mal ansehen. Danke für den Tipp!

  • Dein Vorschlag mit der Pfadangabe in der Service-Ref funktioniert leider nur mit Aufnahmen (bzw. .ts Files). Sobald man versucht x264 oder xvid abzuspielen, funktioniert das nicht mehr:


    Mir ist klar, dass ihr am alten rtspserver nichts mehr macht. Wäre aber super, wenn ihr das in den neuen rtsp direkt mit einbaut, falls es der Arbeitsaufwand zulässt.


    Auch top wäre es, die EPG-Daten mit im rtsp-Stream unterzubringen :)

  • Danke!


    Allerdings wird jetzt zwar mein journal nicht mehr mit Meldungen vollgebombt, Bild gibt es leider trotzdem nicht.


    Hier das Log von dreamrtspserver:


    Dann trennt der Client (getestet mit dm520 als Client und VLC als Client) irgendwann die Verbindung, weil da nichts ordentliches vom Server gesendet wird.