dreamliveserver

    In der Info siehst du jetzt eh die Clients :thumbs_up:

    Also bei mir läuft's immer noch nicht rund.


    Mit 6000 bit streamen funktioniert zwar jetzt, aber beim Kanalwechsel sendet der server immer noch eine Minute lang an die alte Client-Verbindung weiter. D.h. man muss nach jedem Kanalwechsel eine Minute warten, bis ein vernünftiges Bild kommt. Vorher hat man sehr viele Bildfehler.


    Beide Boxen haben ein aktuelles orig unstable image. Hier mal ein Log vom Kanalwechsel:


    Client:


    Server:


    hatte jetzt Zeit den Dreamliveserver zu testen.


    Hardware:
    7080HD mit aktuellem Unstable NN2
    streamt im lokalen Netzwerk (Gigabit) zu einem Windows PC (10 aktueller Build) mit aktuellen VLC Player (64-Bit) (nur mit RTSP getestet)


    Mein Eindruck:


    Pro:

    • schnellere Umschaltzeiten
    • allgemein stabileres Verhalten bei Zapping, es tauchten keine mehrfach Clients bei "aggressiven" Zapping auf

    Con:

    • bei minimaler Bild- und Tonqualität (wenn ich bei beiden jeweils mit Mehrfachdruck auf 0, auf Videobitrate 255 und Audiobitrate 32 erreiche), habe ich trotzdem ein, für diese Bitraten, gutes Bild und Ton

      • Grund: scheinbar wird hier nicht richtig mit den Parametern transkodiert und das trotz Server und Box Neustart.
      • Vergleicht man die Bandbreite kommen mit dem "alten" Streamingserver bei diesen Settings rund 2,3Mbit/s an, mit dem "neue" Streamingserver jedoch zwischen 6-7Mbit/s und das trotz der selben Settings


    • der Port ist "hardcoded", kann also nicht mittels Konfiguration geändert werden (ist aber nicht dramatisch)


    Ich hab mein Backup wieder eingespielt, da ich die "sparsam" mit der Bandbreite umgehen muss.

    • Offizieller Beitrag
    Zitat von maluhi

    Mit 6000 bit streamen funktioniert zwar jetzt, aber beim Kanalwechsel sendet der server immer noch eine Minute lang an die alte Client-Verbindung weiter

    Hast du denn auch das gstreamer update gemacht?
    Ohne wird das Problem nicht verschwinden :). (es geht um diesen commit hier: https://github.com/opendreambo…ccfea1a90d48fb8077349108e )

    Zitat von Reichi

    Hast du denn auch das gstreamer update gemacht?Ohne wird das Problem nicht verschwinden :). (es geht um diesen commit hier: https://github.com/opendreambo…ccfea1a90d48fb8077349108e )

    Habe vorher extra alles mit apt-get update && apt-get dist-upgrade auf den neusten Stand gebracht und auch gesehen, dass gstreamer aktualisiert wird. Geht also bei mir auch mit diesem Commit nicht.
    Der Server schickt fröhlich weiter UDP Pakete und ignoriert sogar die ICMP port unreachable Antworten eine Minute lang.

    • Offizieller Beitrag

    Also ich hab das eben nochmal in Ruhe gelesen.
    Du sagst ja man kann nicht "zappen" weil der Kanal erst nach einer Minute freigegeben wird.


    Die Sache ist, so funktioniert das alles garnicht ;).
    Es gibt nur genau EINEN Kanal der für den Encoder allokiert wird.
    Schickt ein beliebiger Client eine "neue" Servicereferenz wird der Kanal für alle verbundenen Clients gewechselt.
    Ich glaube dein Problem hat eher eine andere Ursache die man sich ggf. mal genauer ansehen müsste.

    Nein, so sage ich das nicht. Kam vielleicht falsch rüber.
    Wenn man zappt, wird durchaus der Kanal gewechselt. Man "kann" aber nicht gucken, weil ein Haufen Bildfehler entstehen. Sieht dann so aus wie das Bild im Anhang. Und das liegt daran, dass die Bandbreite aufgebraucht ist und der Stream nicht vernünftig übertragen wird. Die Bandbreite ist aufgebraucht, weil der dreamliveserver den gleichen Stream zweimal raussendet. Einmal an den neuen Client und einmal an den alten, der gar nicht mehr existiert. Die Client-Box schickt daraufhin auch dauernd ICMP port unreachable Pakete an den Server, weil der versucht den alten Client auf einem inzwischen geschlossenen Port zu kontaktieren. Nach einer Minute wird die alte Clientverbindung auch vom Server geschlossen und die Bildfehler verschwinden, weil wieder genug Bandbreite zur Verfügung steht.
    Workaround wäre z.B. das Senden von Daten abzubrechen sobald icmp port unreachable zurück kommt. Dadurch wären dann auch alle anderen kaputten Clients gefixt.

    Sehr gut!
    Ich kann bestätigen, dass die alte Verbindung beim Zappen nun nicht mehr 1 Minute weiter besteht.
    Allerdings ist gerade nach mehrmaligem hin- und her-zappen der dreamliveserver mit SEGV abgesoffen. Da ich vor ein paar Tagen schonmal das Speichern von Core-Dumps aktiviert hatte, kann ich euch gern den dump schicken, wenn ihr mir sagt wie ich euch das 160MB File am besten bereitstelle.


    Edit: Danach hat die Client-Box natürlich versucht wieder zu connecten, aber jedes mal ist der dreamliveserver wieder abgeschmiert - ohne core-dump o.ä. Hat sich ohne sichtbaren Log-Eintrag einfach immer sofort wieder beendet. Nach Umschalten auf einen anderen Kanal war das Problem behoben.


    Hier das Log vom Umschalten und dem SEGV:




    Und nach Umschalten ging es dann wieder:



    Einmal editiert, zuletzt von maluhi ()

    Umschalten des Streams im DreamDroid dauert jetzt erheblich länger.

    Und jetzt gerade bekomme ich nach ein wenig zappen nur noch Ton - egal auf welchem Kanal. Auch nach komplettem Disconnect und somit Neustart des dreamliveservers ist das unverändert.


    Ich musste die Server-Box komplett rebooten! Schätze mal da hing irgendwas am Encoder device, was dreamliveserver auch nach Neustart nicht wieder resettet hat.


    Werde dann wohl leider vorerst wieder auf den dreamrtspserver "downgraden". Dass meine Freundin sich, falls ich nicht da bin, per VPN mein Heimnetz einloggen soll und dann remote meine Box restarten muss, wenn es mal nur Ton und kein Bild gibt, gäbe nur Komplikationen, schätze ich :winking_face: