Beiträge von skyball

    Hallo Jochen und fnu,


    vielen Dank für die Antworten. Ich war natürlich ungeduldig und hatte inzwischen schon meine eigene Lösung gefunden.


    Dazu habe ich den VDR-Source von eTobi heruntergeladen, denn das ist ja die VDR Version, die ich benutze. Das ging mit


    apt-get vdr
    apt-get build-dep vdr


    Dann habe ich in das Unterverzeichnis PLUGINS/src den Source des vnsiservers gapackt mit
    git clone https://github.com/FernetMenta/vdr-plugin-vnsiserver


    Anschliessend habe ich dann den ganzern VDR kompiliert, dabei wurde unter anderem das binary für das vnsiserver plugin mit erzeugt.


    So läuft's auch bei mir.


    Grüße,


    Christian

    ...nein, das würde nix helfen. Es ist ja nicht der VDR oder das streamdev plugin, das lange zum Umschalten braucht.


    Der Stream wird von VDR quasi sofort gesendet aber der Client muss dann erstmal erkennen um welches Transportformat es sich handelt, was darin für Video- und Audio-Datenströme sind, welche Codecs, etc., dann wird noch ein bisserl gepuffert und dann geht's langsam los. Das dauert halt ein paar Sekunden und wenn's aus irgendeinem Grund besonders schwierig ist, dann dauert's halt noch ein paar Sekunden länger.


    Beim Umschalten wird der Stream ja auf jeden Fall unterbrochen. Ein anderer Sender hat ja vielleicht ganz andere Datenströme (z.B. Audiokanäle), daher muss also auf jeden Fall eine neue Erkennung stattfinden.


    Ich kann mit Startzeiten von einigen Sekunden ganz gut leben. Die habe ich auch, wenn ich ein Video von einem Netzwerkshare starte. Zappen brauche ich praktisch nicht, dazu gibt's inzwischen eh' zuviele Sender.


    Unangenehm wird's für meinen Geschmack wenn der Start mal länger als 10 oder gar 20 Sekunden dauert. Aber das ist natürlich Geschmackssache.


    Dafür ist so eine wdtv halt billig, sparsam, einfach zu bedienen, etc...



    skyball

    ...die Umschaltzeiten sind ein bisschen unterschiedlich. zwischen 5 Sekunden und max. 20 Sekunden. Das ist scheinbar teilweise zufallsbedingt. Je nachdem wie lange die Box braucht um den Stream zu "erkennen", also zu verstehen um was für ein Format es sich handelt.


    Manchmal geht's dann auch plötzlich gar nicht mehr, ist also alles noch ein bisschen "beta". Allerdings ist die Entwicklergemeinde für die wdtv live momentan recht aktiv und es tut sich praktisch täglich was Neues.


    Die Bildqualität ist aber ganz prima, HD funktioniert bestens. Also würde ich sagen: aufgrund der Umschaltzeiten für's Zappen nicht geeignet, aber für's gezielte Fernsehen super.


    Achja, Voraussetzung ist derzeit ein VDR 1.7 und aufwärts, wg. TS Format. Ob die Box das alte PS Format könnte habe ich nicht untersucht.


    skyball

    Um HDTV ansehen und aufnehmen zu können habe ich mir VDR 1.7.8 installiert. Im Grossen und Ganzen ging das ganz schön (Dank E-Tobi!).


    Auch vdradmin_am arbeitete auf Anhieb weitgehend problemlos mit dem neuen VDR. Nur das Streamen von Aufnahmen ging nicht mehr. Die erzeugten Playlists (m3u) waren immer leer. Leider habe ich nirgends Informationen oder gar einen Patch dazu gefunden (Nein, es lag nicht an Umlauten, Sonderzeichen, falsch eingetragenen Pfaden ,etc.).


    Also hab' ich mich selbst darangesetzt und herausgefunden, dass das Problem daher kommt, dass der neue VDR...


    1. die Aufnahmeverzeichnisse etwas anders benennt und
    2. die Aufnahmen in einem anderen Dateiformat (.TS) ablegt.


    In meiner Konfiguration (Client ist Windows PC mit VLC und MPC als Player) ist das Abspielen dieser Dateien eigentlich kein Problem, nur vdradmin-am erzeugt keine Playlist, weil er die Dateien nicht mehr findet. Damit das wieder geht musste ich 2 Ergänzungen am Code vornehmen.


    Basis war vdradmin_am Version 3.6.4 aus Debian Lenny.


    Funktion findVideoFiles, Zeile 4828 ff:

    Code
    sub findVideoFiles {    my ($minute, $hour, $day, $month, $title) = @_;    my $data;    $title =~ s/ /_/g;    $title =~ s/~/\//g;    Log(LOG_DEBUG, "rec_stream: find $CONFIG{VIDEODIR}/ -follow -regex \"$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...\\...\\.rec/...\\.vdr\"");    my @files = `find $CONFIG{VIDEODIR}/ -follow -regex "$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...\\...\\.rec/...\\.vdr" | sort -r`;    # VDR 1.7.x patch, cd 20090713    unless (@files) {        @files = `find $CONFIG{VIDEODIR}/ -follow -regex "$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...-.\\.rec/.....\\.ts" | sort -r`;    }    # VDR 1.7.x patch end    foreach (@files) {        chomp;        Log(LOG_DEBUG, "findVideoFiles: found ($_)\n");        $_ =~ s/$CONFIG{VIDEODIR}/$CONFIG{ST_VIDEODIR}/;        $_ =~ s/\n//g;        $data = $CONFIG{ST_URL} . "$_\n$data";    }    return $data;}



    Funktion findVideoFolder, Zeile 6090 ff:

    Code
    sub findVideoFolder {    my ($minute, $hour, $day, $month, $title) = @_;    my $folder;    $title =~ s/ /_/g;    $title =~ s/~/\//g;    $folder = `find $CONFIG{VIDEODIR}/ -follow -regex "$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...\\...\\.rec"`;    # VDR 1.7.x patch, cd 20090713    unless ($folder) {        $folder = `find $CONFIG{VIDEODIR}/ -follow -regex "$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...-.\\.rec"`;    }    # VDR 1.7.x patch end    Log(LOG_DEBUG, "findVideoFolder: find $CONFIG{VIDEODIR}/ -follow -regex \"$CONFIG{VIDEODIR}/$title\_*/\\(\_/\\)?....-$month-$day\\.$hour.$minute\\...\\...\\.rec\"");    chomp($folder) if ($folder);    return $folder;}



    Damit werden die Aufnahmedateien wieder gefunden und das Streamen geht bei mir wieder pfundig...


    Skyball