[Gelöst] Streamen von Aufnahmen mit streamdev

  • Hallo zusammen,


    ich habe gerade mal versucht, ob das Streamen von Aufnahmen über streamdev bei mir funktioniert. (Damit ich die Funktion in Lazy Bones testen kann.)
    Bei meinem Testsystem handelt es sich um VDR 2.0.4 und streamdev-server 0.6.1 (Gentoo stable).


    Lazy Bones hab ich so konfiguriert, dass ein Player mit (xine) mit folgender URL aufgerufen wird: http://localhost:3000/TS/1.rec.ts
    Der VDR reagiert im Log mit:

    Code
    Oct 20 13:07:11 henni vdr: [12476] Streamdev: Accepted new client (HTTP) 127.0.0.1:57029
    Oct 20 13:07:11 henni vdr: [12543] streamdev-writer thread started (pid=12470, tid=12543, prio=high)
    Oct 20 13:07:11 henni vdr: [12544] streamdev-recstreaming thread started (pid=12470, tid=12544, prio=high)
    Oct 20 13:07:13 henni vdr: [12543] streamdev-server: streamer done - writer exiting
    Oct 20 13:07:13 henni vdr: [12543] streamdev-server: closing HTTP connection to 127.0.0.1:57029
    Oct 20 13:07:13 henni vdr: [12543] streamdev-writer thread ended (pid=12470, tid=12543)
    Oct 20 13:07:13 henni vdr: [12544] streamdev-recstreaming thread ended (pid=12470, tid=12544)


    Das sieht erst mal nicht schlecht aus. Das Problem ist aber, dass überhaupt nichts über die Leitung kommt. Beweis mit curl:

    HTTP
    henni@henni ~ $ curl http://localhost:3000/TS/1.rec.ts
    henni@henni ~ $ curl -I http://localhost:3000/TS/1.rec.ts
    HTTP/1.1 200 OK
    Content-Type: video/mpeg
    Connection: close
    Pragma: no-cache
    Cache-Control: no-cache
    Server: VDR-2.0.4 / streamdev-server-0.6.1
    Date: Mon, 20 Oct 2014 11:15:29 GMT
    Accept-Ranges: bytes


    Hat jemand eine Idee, was da schief läuft?

  • Hast du mal eine aktuellere Git-Version probiert? Bei mir klappt die Wiedergabe mit VLC (ich nutze Rechner mit VDR 2.0.6 und VDR 2.1.6), die Zeile für Lazybones sieht dann so aus:

    Code
    http://<host>:3000/TS/<recording_number>.rec.ts

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also bei mir gehts auch. Versuch doch mal eine URL aus http://<ip>:3000/recordings.html


    Ansonsten siehts mit curl genauso aus:


    HTTP
    HTTP/1.1 200 OK
    Content-Type: video/mpeg
    Connection: close
    Pragma: no-cache
    Cache-Control: no-cache
    Server: VDR-2.1.6 / streamdev-server-0.6.1-git
    Date: Mon, 20 Oct 2014 13:51:51 GMT
    Accept-Ranges: bytes

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Aber bei Dir ballert er die Konsole voll, wenn Du den -I switch weglässt, oder nicht?


    Der andere URL klappt auch nicht. Grundsätzlich findet er die Aufnahme auch. Ansonsten bekommt man einen HTTP-Error zurück, wie sich das gehört ;)

    Code
    Oct 20 16:03:15 henni vdr: [25186] streamdev-server: streamer done - writer exiting


    Das finde ich komisch. Irgendwie kommt er auf den Trichter, dass er mit dem Stream durch ist, obwohl noch gar nichts geschickt wurde.


    Edit:
    Hab jetzt mal das Plugin mit DEBUG=1 kompiliert:

  • Aber bei Dir ballert er die Konsole voll, wenn Du den -I switch weglässt, oder nicht?


    Ja, dann empfängt er die Daten.


    Ansonsten weiss ich auch grad nicht weiter, vielleicht hat scmirl eine Idee.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Ich glaube ich habs. Der Aufnahme-Player lieferte immer -1 als Größe der Aufnahme. Also habe ich dort mal weiter gebohrt. Es stellte sich heraus, dass er die Dateien nicht scannen kann. Und das liegt wohl daran, dass es ein 32bit-System ist und alle Aufnahmen größer als 4GiB sind. Ich habe jetzt mal eine Aufnahme auf ein paar Minuten geschnitten und damit hat es sofort funktioniert.


    Edit:
    Das war es tatsächlich. Intern wird die Dateigröße mit ftell bestimmt, die auf 32 Bit bei entsprechend großen Dateien (> 2GiB) dann nicht mehr funktioniert. Hab das mal gefixt - unglaublich, ich als Java-Entwickler ;) - und werde den Patch an schmirl schicken.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!