Beiträge von maluhi

    maluhi: hmm ich kann da gar nicht viel zu sagen. Der Server ist nicht meine Baustelle... und ich hab auch keinen Überblick ob es da Änderungen gab die verhindern, dass der alte Server noch läuft. Aber es gab schon einige Änderungen am dbus interface. Denke nicht, dass man das so einfach anpassen kann.

    Ja, am dbus interface hat sich soviel geändert, dass ich das jetzt selbst übernehmen musste. Habe das nun auch laufen und benutze den alten Streamserver jetzt mit dem neuen enigma. Allerdings ist der core jetzt komplett raus und ich kommuniziere in einem zusätzlichen python thread selbst per dbus mit dem dreamrtspserver. Funktioniert soweit, ich muss nur noch ein wenig am error handling anpassen.
    Ist zwar hier etwas OT, aber vielleicht kannst Du mir ja schnell beantworten, ob ich irgendwie in einem Plugin den shutdown von enigma2 abfangen kann bzw darüber informiert werde. Der dbus thread bekommt nämlich nicht mit, wenn enigma runterfährt und läuft fleißig weiter - dadurch sieht das für systemd natürlich so aus, als wenn enigma noch läuft und es wird nicht neugestartet.

    HLS hatte ich auch probiert. Zwar immer klares Bild, aber dauernd Aussetzer. :frowning_face:


    Kein Thema, wenn das noch ein wenig dauert, ich kann ja den alten dreamrtspserver einfach weiter nutzen. Aber gibt es vllt eine Möglichkeit trotzdem die enigma updates mitzumachen? Wäre das überhaupt möglich, wenn ich den rtspserver etwas modifiziere oder macht der core das gar nicht mehr mit? Hast Du eine Idee, wie man das umsetzen könnte?

    @alpha: Dein dreamrtspserver ist nicht ordentlich installiert, deshalb verschluckt sich apt beim ersetzen des selbigen. Probiere mal: dpkg --purge --force-all dreamrtspserver
    Jedenfalls sollte danach "apt-get install dreamliveserver" hoffentlich funktionieren.


    @Ghost: Danke für den schnellen FIx. Jetzt bekomme ich auch Bild - leider ungenießbar, da massiv Bildfehler auftreten.


    Problem 1) Mit Videobitrate 6000 und Audio 256 (so wie ich es vorher hatte), bekomme ich es gar nicht klötzchenfrei zum laufen. Das liegt aber definitiv nicht an zu wenig Bandbreite. Es funktionierte vorher auch mit mehr als 6000 - damit hatte ich noch Luft nach oben bis zum ausreizen meiner 10 Mbit/s Upstream (laut Router ist der Upstream auch NICHT ausgelastet - trotzdem mieses Bild).


    Problem 2) Wenn ich das Preset "Hoch" benutze (4000 / 192), bekommt man klares Bild, wenn man die Server-Box vorher etwas "in Ruhe lässt". Oft tritt allerdings auch hier das Problem der Klötzchenbildung oder komplett verzerrter Bilder auf, wenn man umschaltet. Hier merkt der dreamliveserver erst ca. eine Minute nach dem umschalten, dass die erste Verbindung schon längst beendet wurde und schickt fleißig weiter UDP-Pakete zum ersten Cient (der aber auch laut netstat wirklich die Verbindung längst beendet hat!) und müllt damit den Upstream voll. Auch im journal kommt erst eine Minute versetzt die Meldung, dass der Client-Count runter gegangen ist:



    Code
    Mar 23 09:45:32 dm820 enigma2[233]: I/  [StreamServerControl._onUriParametersChanged] :: ref=1:0:19:EF75:3F9:1:C00000:0:0:0:
    Mar 23 09:45:32 dm820 enigma2[233]: I/  [StreamServerControl._applyUriParameters] :: setting encoder service to 1:0:19:EF75:3F9:1:C00000:0:0:0:
    Mar 23 09:45:32 dm820 enigma2[233]: I/  [StreamServerControl.stopEncoderService] :: Stopping encoder service (1:0:19:EF75:3F9:1:C00000:0:0:0:)
    Mar 23 09:45:32 dm820 enigma2[233]: I/  [StreamServerControl._startEncoderService] :: Starting encoder service [1:0:19:EF75:3F9:1:C00000:0:0:0:]!
    Mar 23 09:45:32 dm820 enigma2[233]: I/  [StreamServerControl._onRtspClientCountChanged] :: 2 /
    Mar 23 09:46:37 dm820 enigma2[233]: I/  [StreamServerControl._onRtspClientCountChanged] :: 1 /


    Ich werde jetzt wieder zurück flashen :thinking_face:


    Edit: Läuft nach flashen des Backups wieder wunderbar mit 6000 / 256. Da passt irgendetwas nicht beim dreamliveserver. Kann leider von hier nicht testen, ob Problem 1) auch im lokalen Lan auftreten würden (so wie als wenn man bei der dm820 versucht in 1080p zu transkodieren, weil der SoC das einfach nicht mitmacht), oder nur bei Übertragung über das Internet. An zu wenig Bandbreite liegt es aber definitiv nicht.

    Ich habe mir das Partnerbox-Plugin so angepasst, dass man 1) nun einstellen kann, ob der Partnerbox-Name in Klammern an den Bouquet und Sendernamen angehängt wird und 2) die Sender direkt als transkodierte Streams hinzufügen kann. Dazu kann man einfach auswählen, ob normale Urls, RTSP-, HLS- oder Custom-Urls benutzt werden. Custom-Urls deshalb, da ich z.B. zwei VPNs zwischen meinen Boxen habe. Eins das verschlüsselt ist und ein zweites VPN das nur beim Auth die encryption an hat, aber die Daten unverschlüsselt überträgt (= mehr nutzbare Bandbreite, aber unsicherer - nutze ich nur für die Übertragung der IPTV-Streams). Daher stelle ich einfach Transcoding auf Custom und setze dann die Custom Stream URL auf "rtsp://10.9.0.1/stream?ref=".
    Da das evtl. auch für andere Nutzer hilfreich ist und man so nicht immer die Bouquets manuell nach dem Hinzufügen von neuen Services anpassen muss, war ich einfach mal so frei und habe einen Pull-Request erstellt: https://github.com/opendreambo…-plugin-partnerbox/pull/2

    Habe mal testweise den dreamliveserver.socket service deaktiviert und dreamliveserver mit strace gestartet. Hier das Log (den Anfang habe ich weggelassen und fange genau da an, wo die Verbindung zum Client hergestellt wird). Scheint als kann der Socket für die Daten-Verbindung nicht initialisiert werden:


    Edit: Das sieht immer gleich aus - egal ob VLC oder anderer Client.

    Danke @juanito_perez, aber hat sich erledigt. Habe nochmal geupdatet und herausgefunden, dass die settings sich nun unter /var/lib/dreamliveserver/settings befinden und anscheinend eh default Werte enthalten.


    Punkt 1) aus meinem Ursprungsposting hat sich erledigt. Da hatte etwas aus meinem Netzwerk den Port 8080 gescanned, weil dort früher mal sabnzbd lief, und dadurch den dreamliveserver immer wieder gestaret.


    Die Fehlermeldung aus 2) habe ich immernoch.


    Weder Live-TV noch TV-Kanäle funktioniert :thinking_face:


    Da kann wahrscheinlich nur @Ghost was zu sagen.

    Hallo,


    habe vorhin in freudiger Erwartung auf den neuen RTSP-Server meine Server-Box geupdatet. Leider funktioniert der neue dreamliveserver bei mir absolut nicht.


    1) Folgendes wiederholt sich im journal durchgehend:


    2) Wenn man dann trotzdem mit einem Client connected:



    Bild kommt auf der Client-Box keins. Nur eine Fehlermeldung, dass die Resource nicht geschrieben werden kann.


    Hatte dann zwar den dreamliveserver wieder runtergeschmissen und meine gefixte Version installiert (dreamrtspserver hangup - läuft bei mir jetzt seit Wochen ohne Probleme und ohne stranded clients!), aber es wird natürlich kein enableRTSP Signal mehr gesendet, weshalb dann auch nicht auf Port 554 gelauscht wird.


    Mir bliebt nichts anderes übrig, als das Backup, das ich vor dem Update gemacht hatte, zu flashen. Bin gerne bereit als Tester zur Verfügung zu stehen, nochmal upzudaten und rumzuprobieren, um den Fehler asap zu finden. Vorausgesetzt ich habe dafür dann gerade Zeit und meine Freundin schaut gerade kein Fernsehen über die Client-Box :smiling_face:

    Vorsicht: /etc/rc.local gibt es unter OE2.5 nicht. Wird auch nicht automatisch ausgeführt, wenn man sie anlegt, da systemd verwendet wird. Da müsste man erst einen Service anlegen.
    Kannst aber einfach Script in /etc/init.d anlegen und von /etc/rc3.d/S99script o.ä. dagin verlinken. Das klappt trotz systemd.
    Sauberer ist trotzdem einen systemd seevice anzulegen oder das UserScripts Plugin zu verwenden.

    Also davon ab, dass Du Dich anscheinend im Ton vergreifst, ohne es zu merken, solltest Du vielleicht bessere Fehlerbeschreibungen liefern, damit man Dich auch vesteht.
    Aus Deinem zweiten Post ist zu erahnen - sicher bin ich mir da nicht - dass die Fehlermeldungen auftreten, wenn Du NICHT auf einem Partnerbox-Sender bist... richtig?

    Nur eine Idee, falls dein Patch nicht übernommen wird.
    Du könntest Dir ein eigenes python-httplib2 deb erstellen, dass die gepatchte Datei enthält. Das nennst Du bspw. bobo71-python-httplib2 und gibst sowohl in "Conflicts" und "Provides" das Originalpaket an.
    Dann kannst Du Dein deb einfach mit ausliefern. Das sollte funktionieren, solange keine Abhängigkeiten auf das original-Paket bestehen, die eine bestimmte Versionsnummer benötigen. Ohne Version sollte das "Provides" vernünftig funktionieren.

    Du brauchst die Pakete curl und ffmpeg (nur, um die Länge der Aufnahme zu bestimmen)


    Zwar ein langer Einzeiler - aber immerhin ein Einzeler :winking_face:


    Code
    MOVIE='/media/hdd/movie/20180312 2046 - ProSieben HD - Young Sheldon.ts' NAME='Young Sheldon Transcoded' DURATION=$(printf %.0f $(ffprobe -v error -select_streams v:0 -show_entries stream=duration -of default=noprint_wrappers=1:nokey=1 """$MOVIE""" 2>/dev/null | head -n1)) && curl -X POST "http://localhost/web/timeradd?sRef=1%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A`echo -ne 'rtsp://127.0.0.1:554/stream?ref=1%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A0%3A'$(echo -n $MOVIE | hexdump -v -e '/1 "%02x"' | sed 's/\(..\)/%\1/g')%3ATranscode | hexdump -v -e '/1 "%02x"' | sed 's/\(..\)/%\1/g' | hexdump -v -e '/1 "%02x"' | sed 's/\(..\)/%\1/g'`&begin="$(date +"%s")"&end="$(( $(date +"%s") + $DURATION))"&name="$(echo -n $NAME | hexdump -v -e '/1 "%02x"' | sed 's/\(..\)/%\1/g')"&description=&eit=0&sessionid=$(curl -s -X POST "http://localhost/web/session" |grep -o -E "<e2sessionid>(.*)</e2sessionid>" |sed "s|.*<e2sessionid>\(.*\)</e2sessionid>.*|\\1|")"

    Musst nur MOVIE und NAME am Anfang der Zeile anpassen. Daraufhin wird die Länge des .ts Files gelesen und eine Aufnahme gestartet, die als Quelle den RTSP-Server hat.


    Ob das jetzt so sinnvoll ist, sei mal dahingestellt. :smiling_face:


    Edit: Der RTSP-Server darf dafür NICHT auf Follow-Live stehen, sondern muss auf TV-Kanäle eingestellt sein. Das ganze findet dann im Hintergrund statt. Heisst du kannst sogar nebenbei Fernsehen.