[STREAMDEV] - Streaming von Aufnahmen via HTTP-Menü funktioniert nicht

  • Hi,


    ich habe soeben das Streamen von Aufnahmen via streamdev Plugin ausprobiert.


    Wenn ich die Aufnahme mit der Aufnahmen-ID anspreche, dann funktioniert der Stream:


    Code
    mplayer http://receiver-1:3000/EXT/5.rec


    Nun wollte ich die Aufnahmen via HTTP-Menü (http://receiver-1:3000/EXT/recordings.html) streamen. Dabei ist mir aufgefallen, dass JEDE Aufnahme die gleiche URL hat und der Stream nicht funktioniert.


    Code
    http://receiver-1:3000/EXT/2053:0.rec



    Kann mir jemand helfen, bzw. dies bestätigen?



    Gruß Andreas

  • Vermutlich wird die externremux.sh nicht mehr zu deiner Streamdev-Server Version passen.
    Da hat sich ab VDR 1.7.18 bzw. streamdev-Server 0.5.1 was geändert (laut Wiki http://www.vdr-wiki.de/wiki/index.php/Externremux.sh )


    Und ohne die Info welches Distribution und welche VDR bzw Streamdev version du verwendest ist es schwierig...


    Hier gibt es auch einen ungelösten Bug der sich auf die Sortierung der Recordings bezieht.
    http://projects.vdr-developer.org/issues/1226
    Ist es das ? Nein oder ?


    lg
    Joe

  • Das Streamen von Aufnahmen über Remuxer ist noch nicht implementiert. Habe leider im Moment sehr wenig Freizeit. Egal welchen Link (EXT, TS, PES) Du nimmst - es wird immer die Original-Datei gestreamt.


    Zu Deinem Problem mit der identischen ID: Die setzt sich zusammen aus der Device-ID und der Inode-Nummer. Die Inode-Nummer scheint bei Dir überall 0 zu sein. Welches Dateisystem nutzt Du? Zeigt der Befehl "stat AUFNAHMEVERZEICHNIS.rec" auch Inode-Nummer 0 an?

  • Kleiner Nachtrag:


    Wenn ich die INODE aus dem stat in die URL reinkopiere dann spielt er die Aufnahme ab - natürlich als TS aber sie läuft, also stimmt da was mit dem Sammeln der INODES nicht.
    Eventuell wegen XFS?


    Danke!!!

  • Das ist interessant. Sowohl für das Erzeugen der Link-Liste als auch für die Suche nach der zur URL passenden Aufnahme wird die inode auf gleiche Weise ermittelt. Evtl. wird für die inodes kein "unsigned long" sondern etwas längeres verwendet. Bitte mal mit folgendem Patch versuchen:

    Diff
    --- a/server/menuHTTP.c
    +++ b/server/menuHTTP.c
    @@ -28,7 +28,7 @@ const cString cRecordingsIterator::ItemRessource() const
     {
            struct stat st;
            if (stat(current->FileName(), &st) == 0)
    -               return cString::sprintf("%lu:%lu.rec", st.st_dev, st.st_ino);
    +               return cString::sprintf("%lu:%lu.rec", (unsigned long) st.st_dev, (unsigned long) st.st_ino);
            return "";
     }
  • Hallo,


    also wenn ich mich recht erinnere (bin nicht so der Coder) dann patche ich so:
    patch -p1 < patch030613


    dann sagt er mir:


    patching file server/menuHTTP.c
    Hunk #1 FAILED at 28.
    1 out of 1 hunk FAILED -- saving rejects to file server/menuHTTP.c.rej



    Sorry wenn ich da nen Fehler gemacht haben sollte...


    Habe aber den Patch manuell eingepflegt - > kompiliert/installiert und nochmal kontrolliert...


    keine Änderung... Jede Recording URL sieht dann nach wie vor so aus:


    http://vdrserver:3000/2097:0.rec.ts



    Danke,


    Gruß


    Amigaman

  • Steh da leider völlig auf dem Schlauch. Könntest Du den angehängten Patch anwenden (auf die original menuHTTP.c ohne die (unsigned long) casts), dann einmal die Aufnahmeliste abrufen und einmal eine Wiedergabe mit der manuell ermittelten inode-Nummer aus dem stat-Befehl starten? Wie unterscheiden sich die Meldungen zur gewählten Aufnahme im Log? Die eine Meldung beginnt mit "XX Linklist stat", die andere mit "XX SearchRec stat".

  • Jetzt bin ich aber baff, ich habe Deinen Patch erfolgreich und ohne Fehler auf die Originale Datei angewendet - was auch problemlos funktionerte und dann:


    läuft das alles. 8o ich habe definitiv nichts anderes am VDR verändert.


    vdr: [26865] XX Linklist stat /path/to/videodisk/Star_Trek_II_-_Der_Zorn_des_Khan/2009-11-20.23.53.50.99.rec: inode 2147483826
    vdr: [26865] XX SearchRec stat /path/to/videodisk/Star_Trek_II_-_Der_Zorn_des_Khan/2009-11-20.23.53.50.99.rec: inode 2147483826


    Was mir aber noch aufgefallen ist - wird wahrscheinlich vorher auch so gewesen sein, er hängt an den Pfad der Aufnahme immer das Format ran - ausser bei EXT


    http://vdrserver:3000/TS/2097:2147483826.rec.ts bei TS
    http://vdrserver:3000/PS/2097:2147483826.rec.vob bei PS
    http://vdrserver:3000/PES/2097:2147483826.rec.vdr bei PES
    http://vdrserver:3000/EXT/2097:2147483826.rec bei EXT


    also spielt der die anderen Formate nicht ab, nur wenn ich die zweite Endung entferne.


    Danke, ich hoffe ich konnte Dir auch helfen, weil komischerweise heute alles funktionierte....


    Amigaman

  • Hm - kannst Du die Änderungen in der menuHTTP.c schrittweise wieder rückgängig machen, bis Du wieder beim Original bist?


    * esyslog-Zeile raus
    * geschweifte Klammern raus
    * (unsigned long) casts raus


    Der entscheidende Schritt müsste eigentlich der letzte sein. Vielleicht ist am Montag beim manuellen Patchen etwas schief gegangen.


    Über das mit den Endungen bin ich gestern auch gestolpert. Schau ich mir bei Gelegenheit an. Danke!

  • Hallo,


    ich bin "damals" leider nicht mehr dazu gekommen und gestern habe ich so einen kleinen VDR-Aufräum-Tag gehabt, wobei mir einfiel "Was ist eigentlich aus dem Streaming von Records geworden" ..


    als ich den Thread hier las.. wusste ich Du hast gewartet...


    Aus dem Changelog war ersichtlich das Du das mit den Inodes hinbekommen hast.


    Ich habe mal die aktuelle installiert. Es scheint auch zu klappen, nur leider wird immernoch der Dateityp hinten angehängt - somit muss ich um den Stream abspielen zu können, manuell in der Streamadresse die letzte Endung löschen.


    Ist das gewollt oder woran kann das liegen?


    Also a bug or a feature :)


    NACHTRAG: Rufe ich die Playlist der Recordings direkt mit VLC auf, funktioniert das Abspielen der Aufnahmen.


    Danke für Deine Arbeit.

Jetzt mitmachen!

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