UPDATE Plugin: Advanced Transcode: Streamen alltagstauglich gemacht

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • @ostfriese2, vielen dank für das plugin - das hilft mir enorm weiter!
      ich verwende es über einen reverse-proxy für https und schalte die benötigten ports bei bedarf durch port-triggering frei. drum herum habe ich noch eine dynamische m3u8 datei geschrieben, die sender über namen ansteuern kann und je nachdem ob ich zu hause bin oder unterwegs unterschiedliche qualitätssettings wählt. ich habe 10 unterschiedliche settings über die ports konfiguriert.

      ein einziges thema habe ich, dass leider immer wieder zum show-stopper wird:
      die streaming (8001) und transcoding (8002) ports sind erreichbar, aber plötzlich die 900Xer ports nicht mehr. wenn ich reboote klappt alles wieder, aber ich kann den fehler leider nicht nachstellen, warum die standard-ports erreichbar sind, aber die plugin-ports nicht mehr. restart ist leider nicht immer zeitnah möglich, falls aufnahmen laufen.

      hast du eine idee, wie ich das plugin ohne reboot reaktivieren bzw. den fehler in meiner config näher eingrenzen kann. manchmal funktioniert es tagelang, manchmal sind die ports nach kurzer zeit (bereich von stunden) nicht mehr erreichbar. kann evtl. ein prozess neugestartet werden oder das plugin selbst?

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von wugg527 ()

    • Also, das Plugin ist eigentlich super stabil und stürzt nicht ab.
      Ich vermute, der Fehler liegt in deinem, etwas komplizierten, Oberbau.

      wugg527 schrieb:

      ich verwende es über einen reverse-proxy für https und schalte die benötigten ports bei bedarf durch port-triggering frei. drum herum habe ich noch eine dynamische m3u8 datei geschrieben, die sender über namen ansteuern kann und je nachdem ob ich zu hause bin oder unterwegs unterschiedliche qualitätssettings wählt.
      Ein einfaches Vpn tut's ja auch und ist auch noch sicherer :)

      Versuche doch einmal, ob du den Fehler reproduzieren kannst, wenn du das Plugin im LAN benutzt, nur mit der lokalen Box-IP.
      Ich vermute, dass dann alles reibungslos läuft.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ostfriese2 ()

    • danke für die schnelle antwort. ich hätte die details zu meinem setup vllt. eher weg lassen sollen, da das verwirrt und es ist naheliegend, dass du die probleme in diesem bereich vermutest (ginge mir ähnlich). ich teste bei fehlern aber ohne all diesem overhead direkt über http und ohne reverse proxy über das LAN auf die box. drum kann ich den rest als fehlerquelle ausschließen. den overhead brauche ich nur um mehr komfort zu haben, da ich keine spezielle VU+ app, sondern direkt VLC verwende und die senderauswahl über den technischen code zu mühsam ist. VPN macht sicher sinn, aber da ich oft auf reisen im hotel nicht immer perfektes WLAN habe oder manchmal auch VPN-netz-konflikte ist die port-triggering-variante eigentlich ein guter kompromiss aus sicherheit und simplem zugriff - der port kann nur über ein geschütztes script von außen geöffnet werden und geht automatisch nach einer bestimmten zeit wieder zu, wenn kein traffic mehr erfolgt. zudem kann man mitloggen wann das script ausgeführt wird und würde daher missbrauch schnell bemerken.

      zurück zum thema: ich wollte bei dir/euch mal nachfragen ob das problem bekannt ist bzw. auch bei anderen auftritt. nachdem das offenbar nicht der fall ist, ist das einerseits ein weiter pluspunkt für deine hervorragende arbeit und andererseits ist die wahrscheinlichkeit hoch, dass irgendwas an meinem setup faul ist. ich weiß zwar immer noch nicht was, werde aber mal alles deinstallieren und neu aufsetzen. ich habe die variante mit den überschriebenen dateien für weitere configs laufen. vllt. ist auch da was schief gegangen.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von wugg527 ()

    • Ok, good luck. Melde dich, wenn ich helfen kann !

      Gruß aus Ostfriesland.

      P.S. füll mal bitte dein Profil aus. Box? Image?...

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von ostfriese2 () aus folgendem Grund: Dicke Finger

    • ich melde mich nochmals zu diesem thema:

      einige tage ist alles problemlos gelaufen, leider aber seit gestern wieder probleme, dass das transcoding nicht erreichbar ist. der normale 8001-stream ist erreichbar, 8002 und alle 90xx ports eben nicht. neue, interessante erkenntnis, das plugin ändert weiterhin korrekt die transcoding settings, es scheint aber das transcoding selbst nicht anspringen zu wollen. dabei laden die 90xx ports ewig ohne bild, aber auch ohne fehler, wobei es ein timeout gibt, falls ich direkt auf den 8002er gehe (generell alles wieder ohne meinem oben beschriebenen overhead direkt im LAN getestet). im webinterface wird der stream, den ich versuche aufzurufen, über das modal aus der headerbar angezeigt und dies ändert sich auch, wenn ich den kanal wechsle - eben auch dann, wenn kein bild angezeigt wird.

      meine inetd.conf sah bis gestern so aus:

      Quellcode

      1. 8002 stream tcp nowait root /usr/bin/transtreamproxy transtreamproxy
      2. et server configuration database
      3. #
      4. # If you want to disable an entry so it isn't touched during
      5. # package updates just comment it out with a single '#' character.
      6. #
      7. # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
      8. #
      9. #:INTERNAL: Internal services
      10. #echo stream tcp nowait root internal
      11. #echo dgram udp wait root internal
      12. #chargen stream tcp nowait root internal
      13. #chargen dgram udp wait root internal
      14. #discard stream tcp nowait root internal
      15. #discard dgram udp wait root internal
      16. #daytime stream tcp nowait root internal
      17. #daytime dgram udp wait root internal
      18. #time stream tcp nowait root internal
      19. #time dgram udp wait root internal
      20. ftp stream tcp nowait root /usr/sbin/vsftpd vsftpd
      21. telnet stream tcp nowait root /usr/sbin/telnetd telnetd
      22. 8001 stream tcp nowait root /usr/bin/streamproxy streamproxy
      23. 8002 stream tcp nowait root /usr/bin/transtreamproxy transtreamproxy
      Alles anzeigen
      ich habe gestern die ersten beiden zeilen gelöscht, hoffe das ist korrekt so.

      wenn ich alle streamproxy und transtreamproxy prozesse auf der kommandozeile abschieße, dann gehen 8001 und 8002 ports wieder, aber die 90xx ports springen weiterhin nicht an.
      nach einem neustart ist alles wieder gut - bis zum nächsten mal.

      selbst wenn ich das eigentliche problem nicht lösen kann, würde es trotzdem helfen, wenn ich zumindest über kommandozeilen-befehle alles wieder reparieren kann.

      P.S.: mir kommt aber gerade eine idee - ich könnte (wiedermal über ein skript :D) den 8002 port immer verwenden und dier 90xx ports nur zur änderung der settings verwenden. werde das mal testen, wenn ich zeit hab.

      ok, ich glaube jetzt habe ich es eingegrenzt, da ich etwas vglbares in einem anderen thread gelesen habe.

      ich verwende VLC, der offenbar den transcode stream nicht immer korrekt freigibt, wenn man beendet (stopptaste hilft, kann man in der praxis, vor allem am smartphone aber nicht immer zuverlässig garantieren).

      schieße ich dann den transtreamproxy auf der kommandozeile ab, ist der stream frei, aber die plugin verbindung zum stream scheint nicht mehr zu funktionieren.

      das problem ist daher zwar nicht das plugin, sondern der client in kombi mit dem transtreamproxy, die auswirkungen betreffen aber das plugin.

      daher vmtl. für diesen thread kein thema, aber totzdem vielen dank für die hilfe. vllt. helfen anderen auch meine posts dazu.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von wugg527 ()

    • danke, das mache ich jedenfalls gleich.

      ich fürchte aber, dass wirklich diese stream-stopp-problematik das problem verursacht, da ich die inetd.conf änderungen gestern gemacht habe, das transcoding dann lief und jetzt ohne überschreibungen in der inetd.conf trotzdem der stream wieder hängengeblieben ist.
    • kein problem & danke nochmals für die hilfe!

      noch vor den änderungen:
      der stream läuft gerade, aber die inetd.conf ist wirklich grad wieder in alle einzelteile zerlegt worden. wird wohl wirklich das der grund sein.
      ich ändere das mal und berichte in ein paar tagen wieder, ob es das problem für länger gelöst hat.

      vllt. schreib kurz eine erwähnung dazu in das initiale post, wenn du zeit hast.
    • ich gebe hier nochmal ein kurzes update. auch wenn leider keine lösung dabei ist, hilft es vllt. jmd der später in diesen thread schaut.

      leider hat das sperren der inetd.conf keine lösung des problems gebracht. tagelang lief alles gut, auch gestern abend konnte ich noch einen transkodierten stream schauen, heute leider wieder nicht erreichbar und, wie oben erläutert, ein offener stream im openwebif ersichtlich. IP lautet auf 127.0.01. abschießen des streamproxy prozesses bewirkt nichts, abschießen des transtreamproxy macht port 8002 wieder verfügbar, aber die 90xx ports des plugins leider nicht.

      einzig mir bekannte problembehebung: restart der ganzen box samt aller damit verbundener probleme (z.b. aktive aufnahmen werden beendet).

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von wugg527 ()

    • Dass das Advanced Transcode Plugin der Schuldige ist, der die inetd.conf zerstört, ist ja nur ein Verdacht...

      Wie ist das denn, wenn Du die inetd.conf per ACL sperrst?
      Kannst Du denn dann noch mit dem Plugin Änderungen vornehmen?
      Das hieße ja, dass das Plugin die Datei dann doch noch schreiben kann...
      Es hieße außerdem, dass der Fehler im Prinzip dann auch wieder auftreten könnte, wenn er tatsächlich vom Plugin kommt.
    • Wie schon mal im Thread gesagt:

      DAS PLUGIN FASST DIE inetd.conf GAR NICHT AN!!!

      Das Wort inetd.conf kommt im Quelltext des Plugins gar nicht vor.

      wugg527 schrieb:

      ... wie oben erläutert, ein offener stream im openwebif ersichtlich ...
      Dort liegt das Problem. Der Player sollte den Stream beenden. Tut er aber nicht. Das hat ja weder mit dem Plugin noch mit ined.conf zu tun.

      @wugg527

      Benenne mal auf der Box die plugin.py um in plugin.old und ersetze sie durch die Angehängte. -> Neustart.

      Wenn das nicht klappt, wieder rückgängig machen.

      (Nur ein Test, die Angehängte könnte evtl. das Problem beheben. Ist aber ein ungeprüfter Schuss in' Blaue.)
      Dateien
      • plugin.py.zip

        (2,05 kB, 4 mal heruntergeladen, zuletzt: )
    • @ostfriese2 ich finde es ja auch faszinierend. Aber bevor ich die inetd.conf „gesperrt“ habe, hat es mir die reproduzierbar zerschossen, wenn ich an den Einstellungen des Plugins gespielt habe.

      Allerdings war das wirklich nur bei den Einstellungen. Nicht bei der reinen Nutzung der transcodierten Streams.
    • @Knifte Du hast Recht. Genau das vermute ich auch. Leider kann man, außer sperren der inetd.conf nichts machen.

      Das Problem von @wugg527 scheint aber noch ein anderes zu sein. Bei ihm wird wohl ein Stream nicht beendet, so dass dann ein weiterer gestartet wird, und mein Plugin abstürzt .

      Wenn seine inetd.conf zerschossen wäre, würde das ja auch nach einem Neustart, wie er sagt, nicht wieder funktionieren .
    • @ostfriese2, vielen dank für die geänderte plugin.py

      ich teste das und melde mich, sobald ich weiß ob es über ca. eine woche hinweg funktioniert (da ich es noch immer nicht direkt reproduzieren kann, ist der zeitraum für den test leider auch nur nach bauchgefühl).

      die sperre der inetd.conf belasse ich ohnehin aktiv, also kann man das bei mir als fehlerquelle ausklammern.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von wugg527 ()