Beiträge von maluhi

    Da er von Upload schreibt, geht es um externe Empfänger. Einfach dran denken, dass man sowas nur über VPN machen sollte. Und dann wirst du mit 6 mbit nicht glücklich

    Doch, dürfte reichen. Einfach ein zweites Netz mit openvpn einrichten, das nur für den Streamserver ist, und richtig konfigurieren. Mtu und fragment setzen und chipher auf none.
    Dann ist die encryption zwar für die Datenübertragung aus, aber immer noch für die Auth aktiv. Und der Overhead des VPN ist dann zuvernachlässigen, weil er nur ca. 40 byte beträgt. Das fällt bei 1400 byte großen Paketen nicht auf.


    Ich habe zwar 10 Mbit Upstream, aber die Bitrate auf 6000 kb/s gestellt, damit ich auch noch Bandbreite für anderes übrig habe. Das ergibt bei 720p super Bild, bei dem man mit normalem Sitzabstand nicht merkt, dass das Bild komprimiert wurde. und auch mit etwas weniger Bitrate wäre das noch ok.

    Wenn ein SSH Login ewig dauert hat das entweder mit der Auslastung des Servers zu tun, oder es gibt einen DNS Timeout. Zumindest openssh versucht nämlich einen reverse dns lookup auf die connectende IP.
    Und wenn Du auf die Box kommst, aber ein Update nicht funktioniert, dann lässt das auch darauf schließen, dass zwar Netzwerk da ist, aber keine Hostnames aufgelöst werden können. Schau mal ob der DNS in /etc/resolv.conf richtig gesetzt wurde.

    Mag sein, dass ich ein Sonderfall bin. Aber ich z.B. nutze Partnerbox über das Internet. Ich habe zwar das movie Dir per NFS hier gemountet und es läuft gut für die meisten Filme - aber es gibt da den ein oder anderen großen Film, der zu groß ist, um ihn ruckelfrei anschauen zu können. Von daher würde mindestens ich das nutzen.. also alles gut :smiling_face:

    Ich hatte beim Testen mit dem Streamserver auch ein paar mal, dass diese Meldung kam. Da hatte ich allerdings selbst Änderungen am alten Streamserver vorgenommen und noch einen Bug darin. Jedenfalls hat die Client-Box versucht zu connecten, dies hat nicht funktioniert, der streamserver dabei abgesoffen und wurde anschließend neugestartet. Danach hat der Client versucht nochmals zu connecten (was auch geklappt hat), aber die Fehlermeldung des ersten Connection-Versuchs wurde eingeblendet. Reproduzieren konnte ich das nicht zuverlässig - es ist nicht immer so passiert.


    Mache mal mit journalctl ein Log von Client und Server während das Problem auftritt und poste das hier.

    Genau das habe ich vor. Es soll ein Erweiterungs-Plugin für Partnerbox werden, also zwar eigenständig sein, aber von Partnerbox abhängen und bspw. die Config mit den Daten der Server-Boxen dort auslesen, damit der User nicht alles doppelt und dreifach konfigurieren und auf Stand halten muss. Wer den RemoteMovie-Player nutzt, nutzt höchtwahrscheinlich auch Partnerbox, dacht ich mir.
    Aber vielleicht mache ich es auch nur so, dass zusätzlich zur eigenen Config auch die bereits bestehenden Partnerboxen, wenn Partnerbox installiert ist, auswählbar sind oder so...

    Ja, das sollte bereits mit den vorhandenen Api-Funktionen klappen. Ich habe aber trotzdem noch vor diese zu erweitern. Bspw. um eine Status-Funktion, die gesammelt Werte wie sref, name, length, playposition, pausable, seekable zurückgibt, damit man das alles mit einem Aufruf erhält.


    Ich habe da noch ein paar Ideen im Kopf, die ich gern noch umsetzen möchte:


    - Automatischer Wechsel in den LiveTV-Modus, wenn ein avi/mkv abgespielt werden soll. Dazu temporär CEC disablen, damit der TV nicht mitangeht. Das ganze natürlich nur, wenn die Server-Box gerade nicht anderweitig in Verwendung ist.
    - Kleines Webinterface, das Bedienelemente wie Start/Pause, vor/zurückspulen, Schieberegler zum seeken, etc. enthält
    - Eine erweiterung für das Partnerbox-Plugin: Remote-Movie. Quasi ein Dateibrowser, womit man Filme auf der Server-Box encodiert abspielen kann und ganz normal (mit Verzögerung) mit der FB zum pausieren, spulen, etc. bedienen kann.


    Wann und in welcher Reihenfolge ich das umsetze weiss ich moch nicht genau, muss ja auch noch irgendwie Geld verdienen und mich um Freundin und Kids kümmern und so :smiling_face:

    Danke! Ich habe den Initial Commit jetzt in euer repo gepushed.
    Vorher hatte ich noch in einer lokalen OE build umgebung und meinem fork getestet, ob das Paket richtig gebaut wird. War auch ganz gut so, denn ich hatte Depends auf "dreamliveserver | dreamrtspserver", das wird allerdings falsch geparsed und ich konnte das Package nicht bauen, weil ein depend auf das Paket "|" erstellt werden sollte. Könnt ihr ja bei Gelegenheit mal fixen, ist aber auch nicht wirklich relevant - habe die depends darauf rausgenommen.


    Wird jetzt jedenfalls richtig gebaut! https://github.com/opendreambo…ec6e0d702486d090523d066b1

    Ja, gerne. Habe seit Jahren viel Erfahrung mit git auf privaten repositories, aber mir letztens auch einen github account angelegt: https://github.com/maluhi
    Du hast übrigens vor kurzem bereits einen Pull Request von mir in partnerbox gemerged. :smiling_face:


    Wie läuft das jetzt am besten? Packe ich das Plugin analog zu den anderen Plugins einfach in meinen lokalen Fork und pushe, nachder Rechtevergabe, in euer repo? Oder soll ich das in meinem Fork machen und Du schaust erst nochmal drüber? Oder erstellst Du das Grundgerüst mit dem bestehenden Code und ich übernehme dann nachher nur die Pflege?

    Naja wenn Du das Plugin installierst, sieht es nach außen sonaus, als wenn das direkt im dreamliveserver integriert ist. Kann also theoretisch in Clients integriert werden. Praktischer wäre es natürlich echt, wenn das von DMM direkt in StreamServerControl.py übernommen wird. Aber ob und wie das passiert, werden wir sehen.
    Aber es gibt sauberere Wege das noch viel besser hinzubekommen. Bspw. das Webinterface um Api Funktionen erweitern, womit man im laufenden Stream vor/zurückspulen und seeken, pause/resume usw. kann. Vllt mache ich sowas mal, wenn ich Zeit und Lust habe.

    Auch wenn ich mich wiederhole: Das wäre technisch dann eben nicht möglich...


    Es läuft so:


    Python -> e2-core -> SoC -> streamserver -> client


    Wobei python mit den Methoden eServiceCenter.play(ref) und dann .setTarget() und .start() dem e2-core mitteilt, welchen service er an den SoC senden soll. Der streamserver liest dann vom encoding device, die encodierten Daten. Der Client holt sich diese dann per Stream vom Streaming-Server.
    Du möchtest den letzten Schritt ersetzen. Statt eines Clients möchtest Du am Ende der Kette in eine Datei ausgeben.


    Ich rede allerdings davon, dass der e2-core einen 4097 service nicht richig an den SoC weitergibt. Normalerweise werden 4097 vor der Wiedergabe durch gstreamer gejagt (um divx/whatever zu DEcoden). Die Kette müsste dann also so aussehen:


    Python -> e2-core -> gstreamer -> SoC -> streamserver -> client


    Das funktioniert aber eben nicht. Ob dabei dann der client durch eine Ausgabe in eine Datei ersetzt wird ist irrelevant für das Problem, das ich hier anspreche.


    Übrigens habe ich der Einfachheit halber in der Kette oben weggelassen, dass vorher der streamserver noch die Client-Verbindung annimmt und dann per dbus dem e2-core bescheid gibt, dass eine neue Url aufgerufen wurde und dieser dann _onUriParametetChanged() in StreamServerControl.py aufgeruft, was dann wiederrum eServiceCenter nutzt, um dem e2-core zu sagen, welchen service er an den SoC durchschleifen soll...

    Das habe ich verstanden. Aber darum geht es doch hier gar nicht :smiling_face:


    Angenommen Dein Feature-Request wird realisiert, dann könntest man zwar das TV-Programm und Aufnahmen direkt in eine Datei encoden, aber das würde mit avi/mkv immer noch nicht funktionieren. Und genau darum geht es in diesem Thread: Die Möglichkeit avi/mkv zu encoden. Ob die Ausgabe dann per rtsp/hls oder in eine Datei erfolgt, möchte ich hier gar nicht thematisieren. Es geht lediglich darum avi/mkv als Input benutzen zu können. (Und da enigma zu Wiedergabe dieser gstreamer benutzt, muss man halt eine 4097 ServiceRef benutzen, die enigma2 veranlasst gstreamer *zur Wiedergabe* zu benutzen. Nur deshalb rede ich hier von gstreamer.. es geht NICHT darum, dass gstreamer als Client zum rtsp-Server benutzt werden soll!)

    Das eine hat ja dem anderen nichts zu tun. Klar wäre es gut, wenn die Ausgabe des Encoder Devices in ein File erfolgen könnte. Egal wie und wo das gelöst wird.


    Aber dann wäre das Problem aus diesem Thread immer noch da und man könnte zwar Aufnahmen in ein File encodieren, aber keine anderen Filme. Dein Thread geht um den Output - ich rede vom Input.


    Im Moment werden nämlich Filme (mkv / api / etc.), gar nicht erst richtig an das Encoder Device durchgereicht. Wenn es sich nicht um Aufnahmen handelt, müsste man gstreamer dazwischen schalten (= ServiceRef mit 4097). Da scheint aber irgendwas nicht im Core zu funktionieren.

    Man kann wunderbar .ts Files vom SoC encoden lassen und streamen, indem man dem Streaming-Server einfach eine ServiceRef übergibt, die den Dateinamen enthält. Diese wird dann an eServiceCenter übergeben und danach hat man per Python keinen Einfluss mehr. Das sieht dann so aus:



    Allerdings funktioniert das nicht, wenn man statt einer Aufnahme einen Film streamen möchte, der erst noch durch gstreamer gejagt werden muss:




    Es wäre klasse, wenn das auch funktionieren würde. Vielen Dank!