Hi,

Punkt 1: Die "hooked Meldung" kommt nur einmalig beim Boot, vllt habt ihr sie deshalb nicht gesehen. Kann es sein, dass ihr ein anderes Plugin benutzt, das irgendetwas mit der Film-Liste anstellt? StreamServerSeek sucht nämlich im Original-Template nach bestimmten Vorkommnissen und fügt an diesen Stellen einen zusätzlichen Button ein. Wenn das Original-Template geändert wurde, klappt das evtl. nicht. Ich habe jedenfalls bei mir immer noch einen Play-Button in der Film-Liste.

Punkt 2: Beim Testen ist mir aufgefallen, dass es unmöglich ist mit der aktuellen Version von StreamServerSeek zu streamen (zumindest auf meiner MIPS-Kiste). Ich fand heraus, dass in irgendeinem der letzten Updates das Connection-Handling vom dreamliveserver geändert worden sein muss. Jedenfalls kommt dieser nicht mehr damit klar, wenn ein "connection: close" Header gesendet wird. Genau diesen Header sendet aber StreamServerSeek bedingt durch die genutzte Technik. Ich habe dafür jetzt einen Workaround gebastelt und gaukele dem dreamliveserver vor, dass die Verbindung aufrecht erhalten werden soll, beende Sie aber nach dem Übertragen der Daten dann prompt. Reichi vllt. schaut ihr euch das mal genauer an. Sendet ein Client "connection: close", geht bereits der Abruf der m3u8 schief, wenn kein bisheriger dreamliveserver Prozess existierte.

Ich habe eine neue Version von StreamServerSeek erstellt. Wer nicht bis zum nächsten offiziellen Update des Feeds warten möchte, kann die Version aus dem ersten Post dieses Threads bereits vorab herunterladen. Wie man das installiert und was zu beachten ist, steht im ersten Post.

Die neue Version behandelt nur das in Punkt 2 angesprochene Problem. Es ändert nichts an dem Play-Button. Dem Problem können wir gern noch genauer auf den Grund gehen. Ich bin aber ab heute Nachmittag erstmal im Urlaub - danach dann gern

Versuch mal twonky

Edit: DLNA und Scannen auf hinzugekommene Dateien

Danke fürs Bescheid geben!
Kannst Du vielleicht mal gucken, ob der Fehler auch auftritt, wenn Du versuchst über Reichis Player einen normalen Sender zu schauen? Das wäre in dem Fall dann nämlich Reichis Baustelle. Ich fummel ihm da nicht dazwischen.

Klar habe ich das gesehen, denn ich habe es ja in StreamServerSeek so umgebaut, dass Reichis Player statt dem integrierten genommen wird. Also bei mir startet der Stream sowohl am PC als auch iPhone dann automatisch. Klappt es bei Dir auch nach Drücken des Play-Buttons nicht?

Reichis Player hat auch eine Zeitangabe/leiste.

Vielen Dank fürs Testen! Jetzt funktioniert ja scheinbar alles, wie es soll. Das mit den 5 Sekunden kann ich schlecht ändern. Der Client bekommt zum Anfang direkt eine m3u8, die alle Segmente enthält und berechnet sich aus der Anzahl und Länge der Segments die Dauer des Films. Wenn ich da was ändere, passt die Zeitleiste nicht. Aber da man beim seeken nicht genau die richtige Stelle treffen kann (weil es ja einen delay durch den cache gibt), passt das nachher nicht mehr hundertprozentig.
Aber schön, dass es jetzt sauber funktioniert

Probier mal bitte die 1.2, die ich gerade hochgeladen habe.

Ich hatte das erste Log falsch gedeutet. Der dreamliveserver hatte sich wohl korrekter weise deaktiviert, weil keine Requests mehr ankamen. Das wiederum lag daran, dass reactor.callLater irgendwann aufgehört hat zu funktionieren. Das passiert unregelmäßig - warum weiss ich nicht. Aber "in Auftrag" gegebene Funktionsaufrufe werden dann einfach nicht mehr ausgeführt. Ich habe das jetzt durch eTimer() ersetzt und es scheint zu funktionieren. Bitte mal testen.

In dieser Version ist viel Debug-Output - also bitte nicht wundern

Super, danke! Schaue ich mir asap an.

U hast das Log mit -u gemacht oder? Lass mal bitte einfach nur "journalctl -f" laufen. Sieht mir nämlich ganz danach aus, dass dreamliveserver gecrashed ist und das sieht man leider mit -u nicht. Ansonsten würde nicht aus heiterem Himmel StreamServerControl._onSourceStateChanged aufgerufen werden.
Also davon ab, dass das Problem wahrscheinlich also durch einen Bug in dreamliveserver hervorgerufen wurde, werde ich mir mal gedanken machen, wie ich einen Workaround dafür bastele und das abfange

@Kurti79: Probier mal bitte die hier: https://dreambox.de/board/inde…rseek-4-3-2-f1-1-all-deb/

Komisch. Ich habe aber zum Testen auch ein iPhone 6 mit iOS 10 benutzt. Evtl hat sich da in iOS 11 was geändert. Ist aber auch egal, ich habe eine Idee, wie ich das Problem umgehen kann. Bin aber im Moment mit den Kids unterwegs und eigentlich heute Abend auch verplant. Evtl. komme ich da erst Montag zu - aber ich schau mal, was sich machen lässt.

Ich sende dem Client HTTP Status 503 zurück, wenn ein segment noch nicht verfübar ist. Auf meinem iPhone funktioniert das und der Client fragt das segment einfach nochmal neu an. Dein iPad scheint aber einfach das nächste segment anzufordern. Ich muss mal schauen, wie ich das hier reproduzieren und fixen kann

Die neue Version 1.0 stellt Filme nun per HLS als Video On Demand bereit. Dazu wird eine Playlist an HLS-Clients ausgeliefert, die bereits alle segmente enthält. Je nachdem welches segment der Client nun abruft, merkt StreamServerSeek, dass der Client die aktuelle Position geändert hat und seeked daraufhin an die richtige Position. Im Hintergrund wird der dreamliveserver ganz regulär über fortlaufende segments angesprochen und weiss gar nichts davon, dass der Client eine Seek-Bar hat.

StreamServerSeek benutzt jetzt Dreambox TV - Beta von @Reichi als Player. Danke dafür, der ist super

Wen es interessiert: Dazu müssen einige Timestamps in den segments geändert werden. Das war mir in Python aufgrund der Datentypen zu blöd und außerdem dürfte das in C sowieso deutlich schneller gehen (es dauert in C nur ca. 2-3ms). Diese Funktionalität ist in libsss-segment enthalten (auch im ersten Post). Source-Code dazu gibt es hier: https://github.com/opendreambox/libsss-segment

Hast Du evtl den den HLS-Server deaktiviert? Die Meldung kommt, wenn der Streamserver nicht anfängt den Film abzuspielen.
Schau mal unter Menü->Einstellungen->Netzwerk->Streamserver.
Abstellen, dass StreamServerSeek beim Klick auf den Film startet kann man leider nicht ohne es zu deinstallieren. Ist noch unglücklich gelöst, aber bald kommt sowieso ein großes Update

Ich hatte in folgendem Thread mal postfix hochgeladen. Da ist auch eine sendmail binary enthalten.
https://board.newnigma2.to/wbb…und-GPG-auf-der-Dreambox/

You don't need a serial port. Just get a cheap usb to serial converter.

Zitat von alpha

wenn es direkt von amazon kommt, dann eher nicht... kommt eher bei den marketplace haendlern vor.

Das ist Quatsch. Amazon weiss manchmal nichtmal was da so alles im Lager herumfleucht. Die sortieren nämlich oft ihre Artikel nur nach Typ und nicht nach Market-Place Händler. Es gibt nämlich auch welche, die über Amazon versenden. Und wenn die ihre Ware einliefern, dann kommt die einfach zum bereits vorhandenen Lagerbestand. Kauft dann bspw. ein Kunde direkt bei Amazon, kann es sein, dass er einen Artikel erhält, der von einem Händler eingeliefert wurde. Dafür bekommt dann als Ausgleich der Kunde eines Händlers dann den Artikel, den Amazon einst gekauft hat. Amazon weiss schlicht und einfach nicht, wo die Artikel herkommen.
So kam es schon vor, dass ein Händler gefälschte Artikel eingelagert hat und Amazon diese an die eigenen Kunden verschickt hat.

So war es zumindest vor ein paar Jahren noch. Ob das inzwischen geändert wurde, weiss ich nicht.

Na wir nehmen Deinen.

Ich habe da keine große Arbeit reingesteckt, der ist eher so nebenbei entstanden. Das sind nur ein paar Zeilen Code zusätzlich zu dem was ich eh schon für die seek bar gemacht hatte. Ist halt video-js mit contrib-hls.

Aber ich hätte da einen Feature-Request: Support von m3u8 mit Typ VOD (also feststehenden Playlists, die sich nicht mehr ändern). Ich bastel da nämlich gerade an was, das zwar nicht vom Web-Player abhängt, aber wäre toll, wenn der Player das dann auch kann. video-js kann das

Hast ne PN

Wie genau meinst Du das? Es ist korrekt, dass dreamliveserver sich beendet, wenn kein Client verbunden ist. Er wird dann wieder durch dreamliveserver.socket gestartet, wenn ein Client auf Port 554 oder 8080 connected.
Das kannst Du auch mit "netstat -apn | grep 554" kontrollieren. Da sollte man sehen, dass "init" auf dem Port lauscht.

Nachtrag zu Problem 1)

@Ghost: Kann es sein, dass ihr die segments nicht in einem Stück in den transport schreibt, sondern zwischendurch immer flushed und wartet bis der Client den Erhalt bestätigt? Ich habe nämlich jetzt einen Reverse-Proxy in StreamServerSeek eingebaut und kann damit wieder HLS mit einer Bitrate von 6000 streamen. Trotz dem Umweg über Python kommen die segments viel schneller beim Client an. Ich kann mir das nur so erklären, dass sich eine direkte Verbindung zum Streamserver durch flushen o.ä. verzögert, weil die Antwortpakete nunmal auch eine Latency haben, die nicht ins Gewicht fällt, wenn der Reverse-Proxy diese direkt lokal absetzen kann.

Klappt ja jetzt mit Hilfe des Reverse-Proxies in StreamServerSeek trotzdem (einfach http://[IP]/streamserverseek/proxy/stream.m3u8 statt http://[IP]:8080/stream.m3u8 benutzen), aber wäre natürlich trotzdem schön, wenn das auch im dreamliveserver direkt gefixed wird

Die neue Version 0.9 bringt sowohl einen Reverse-Proxy als auch einen Web-Player mit. Mit Hilfe des Reverse-Proxies wird ein HLS-Stream in langsamen Netzen (bspw. über das Internet) deutlich schneller übertragen, was darin resultiert, dass man eine höhere Bitrate benutzen kann. Der Web-Player startet automatisch, wenn man in den üblichen Stream-URLs einfach /rtsp/ bzw. /hls/ durch /player/ ersetzt. Außerdem kann man nun einen Film direkt in der Filmliste per WebPlayer abspielen.
Details in Post 1