TechnoTrend Premium S2-6400 dual HD Technik / Treiber / Installation und bitte nur das

  • Zitat von »rOw«


    genau das Verhalten kann ich bei mir auch nachvollziehen.
    Naja „schön“ zu hören, dass es nicht nur mir so geht… X(
    Stellt sich jetzt nur noch die Frage, was tun?

    Da Ihr das Problem reproduzieren könnt, ist wohl debugging angesagt. Da sind die Entwickler gefragt...

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • Zitat

    Ich kenne den Begriff "Transfermodus" auch nur im Zusammenhang mit ATM?! Vielleicht könnte das einer mal vernünftig erklären...

    Im VDR bedeutet das, dass VDR die Daten von einem Tuner - Device ausliest und in ein Decoder - Device überträgt (transferiert). Bei der 6400 können die Daten auch innerhalb der Karte vom Tuner zum Decoder übertragen werden, ohne dass VDR irgendetwas damit zu tun hätte. Wenn das nicht möglich ist, z.B. weil eine zusätzliche Tunerkarte gerade das "Live" - Gerät ist, fängt VDR an, die Daten zu schaufeln. Das nennt sich dann Transfermodus.


    Bei dem modifizierten dvbhddevice wird dafür gesorgt, dass VDR nicht merkt, dass die 6400 eine FF - Karte ist, die das selber kann. Die Karte wird gegenüber VDR als 2 Tuner + 1 Decoder ausgegeben. Deshalb arbeitet VDR dann immer im Transfermodus.


    Falk

  • ...vielen Dank Falk für Deine Erklärung!


    Ich folgere daraus, dass bei dem modifizierten Plugin die Last für den VDR quasi doppelt so hoch werden kann, wie bei dem Standard-Plugin.


    Ist denn bei yaVDR ein modifiziertes Plugin im Einsatz?


    Und was passiert, wenn ich meine S480 mit zwei Tunern wieder bekomme, laufen dann drei Tuner im Transfer-Modus und ist das evtl. problematisch?


    Ich werde mal ein wenig im Code stöbern, vielleicht kann ich ja auch etwas "helfen".

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • zum Debuggen des "TS packet not accepted in Transfer Mode" Bugs:


    In der Datei PLUGINS/src/dvbhddevice/dvbhdffdevice.c folgende Funktion


    durch diese


    ersetzen. Dann postet mal eine neues Log, wenn der Fehler wieder auftritt. Es sollte mehr zu sehen sein, vermute ich.


    An die Entwickler:
    Wird die Funktion

    Code
    int cDvbHdFfDevice::PlayVideo(const uchar *Data, int Length)


    überhaupt benutzt?

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • echo "blacklist saa716x_ff" > /etc/modprobe.d/blacklist-saa716x_ff.conf
    echo "blacklist ?dvbtstick?" > /etc/modprobe.d/blacklist-?dvbtstick?.conf

    OK, Danke, darauf hätte ich auch selbst kommen können.. ich blackliste jetzt nur das USB-device (dvb_usb_dib0700) und lade es in der runvdr, die sowieso erst mit 5s Verzögerung startet. Insgesamt nun Boot-Zeit bis Bild 45s (davon 20s BIOS), und tatsächlich tritt das Problem "not all devices ready after 30s" nun nicht mehr auf. Das DVB-T-Device ist erst der dritte Adapter in /dev/dvb und auch das dritte device im VDR. Scheint zu helfen, und auch beide 6400-Tuner scheinen wieder im Transfermodus zu laufen. Offenbar erwartet das dvbhddevice bzw. dessen Modifikation kein weiteres device, jedenfalls keines "vor" der 6400, vielleicht wird die Umschaltung über die Indices 0 und 1 vorgenommen, was nun wieder "stimmt".


    Danke für die Hinweise.

  • Zitat

    Und was passiert, wenn ich meine S480 mit zwei Tunern wieder bekomme, laufen dann drei Tuner im Transfer-Modus und ist das evtl. problematisch?

    Für die Tuner besteht da kein Unterschied, nur VDR arbeitet dann, wenn der die Tuner der S480 verwendet, im Transfermodus. Das ist aber kein grundsätzliches Problem. Der Transfermodus erzeugt ja nur eine zusätzliche Last für das Live - Signal. Wenn parallel Aufnahmen laufen, sind die davon nicht betroffen, da gibt es auch keinen Unterschied. Die Belastung ist auch nicht wirklich groß. Bei mir sind es ca. 8..10 %, um die die Prozessorlast steigt, wenn das Live - Signal per Transfermodus eingespeist wird.


    Falk

  • Ist denn bei yaVDR ein modifiziertes Plugin im Einsatz?

    Davon gehe ich an Hand der Versionsnummer aus, 0.0.4dag3-0yavdr2~natty.


    So, wenn noch einer der Debianer bzw. Ubuntuer debuggen will:

    Code
    apt-get remove vdr-plugin-dvbhddevice
    cd /usr/local/src 
    apt-get source vdr-plugin-dvbhddevice
    cd vdr-plugin-dvbhddevice-*
    vi dvbhdffdevice.c
    dpkg-buildpackage -rfakeroot -us -uc -b 
    dpkg -i ../*.deb


    Alle Abhängigkeiten wie z.B. vdr-dev, dpkg-dev, build-essential und fakeroot müssen im Vorfeld noch installiert werden.


    Mr_T
    Sobald ich das Problem reproduzieren konnte und etwas im Log steht, werde ich es hier wieder posten...


    [Update]
    Ging ja jetzt doch schneller als gedacht:



    Und immer so weiter... CPU Last <= 10%

  • Zitat von »Mr_T«




    Ist denn bei yaVDR ein modifiziertes Plugin im Einsatz?
    Davon gehe ich an Hand der Versionsnummer aus, 0.0.4dag3-0yavdr2~natty.

    Dann ist es bisher wohl so, dass das Problem nur mit dem modifizierten Plugin auftritt, oder gibt es hier jmd. bei dem es auch mit dem Plugin von powarman passiert?


    Trotzdem sollten wir das weiter debuggen...
    Dass das Log den Fehler

    Code
    (cDvbHdFfDevice::PlayTsVideo): WriteAllOrNothing returns -1


    zeigt, bedeutet: Wir sind auf der richtigen Spur.
    Die Methode "WriteAllOrNothing" befindet sich in der tools.c des VDR:


    Wenn ich das richtig sehe, scheint die "-1" ein (fatal) error code zu sein. Erweitert mal die Methode PlayTsVideo um die Längenangabe im Fehlerfall:


    Vielleicht könnten auch mal dag/kls/powarman/ufo Ihren Senf dazu geben?

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • In der tools.h steht:

    Code
    #define FATALERRNO (errno && errno != EAGAIN && errno != EINTR)


    Mein C reicht aber nicht aus, um das zu verstehen. :hilfe

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • Das ist doch gar nicht so schwer: write liefert immer -1 zurück, wenn irgendetwas schief gegangen ist (nicht nur Fatal Error) und dann ist auch die Variable errno gesetzt. Wenn errno den Wert EGAIN (lies:E-again) hat, dann heißt das quasi: "Spiels nochmal, Sam" und EINTR ("E-interrupt") heißt unterbrochen, z.B. durch einen höher priorisierten Prozess. In der man page von write (man 2 write) werden alle möglichen E-Fehler-Konstanten aufgelistet und erklärt (zumindest bei meinem opensuse). VDR bricht ab, wenn errno NICHT EGAIN und NICHT EINTR ist, also ein fataler d.h. nicht behebbarer Fehler vorliegt, wo nochmaliges Schicken der Daten nichts bringen würde.
    Wichtig wäre also zu wissen, welchen E-Fehler-Code das write zurückliefert, d.h. die WriteAllOrNothing sollte im Fehlerfall also vor dem return w um ein esyslog ergänzt werden, z.B. (ungetestet): esyslog("VDR: writeallornothing: len=%d written=d errno=%d", Length, w, errno); und die Fehlercodes dazu finden sich in einer include-Datei (grep zum suchen nutzen).

  • Aha, alles klar.


    AnK Dann teste mal fleißig und sag' Bescheid, welcher "error code" sich meldet.

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • Also gut ihr zwei, ich hab eure Posts jetzt ein paar Mal aufmerksam durchgelesen und interpretiere daraus die folgenden Änderungen


    vdr-plugin-dvbhddevice - dvbhdffdevice.c

    Code
    int tmpLength = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
      if (tmpLength <= 0) {
     esyslog("ERROR: (cDvbHdFfDevice::PlayTsVideo): WriteAllOrNothing returns %d", tmpLength);
     esyslog("DEBUG: (cDvbHdFfDevice::PlayTsVideo): Length is %d", Length);
    }
      return tmpLength;
    }


    vdr - tools.c

    Code
    // nothing written yet (or fatal error), so we can just return the error code:
    	esyslog("VDR: writeallornothing: len=%d written=d errno=%d", Length, w, errno);
           	return w;
        }
      return written;
    }


    Richtig?

  • agree

    HD-VDR
    Hardware: TT S2-6400, DD Cine S2 V6, ASUS P8H67-M Rev.3, Intel Core i3-2100T, 2x1GB RAM, SSD 40GB Intel X25-V, 2TB, Western Digital WD20EARS, Silverstone Grandia GD04
    Projektor: Epson LH-TW5500 LPE
    Audio: Onkyo TX-SR309, HECO Superior
    Software: Ubuntu 12.04 64bit, vdr 2.0.0, osdteletext, femon, markad, dvbhddevice, remote, streamdev-server
    Status:läuft 1a

  • Moin,


    würde mal sagen, da kommt 188.

  • Ähm, das hätte "esyslog ( ..... Length, tmpLength)" heißen müssen anstatt tmpLength, Length :wand jetzt sind beide vertauscht, aber egal. Was man daraus lesen kann: es sollen 188 Bytes geschrieben werden (= 1 TS-Paket), er liefert aber -1 zurück (=Fehler). Was ich vermisse sind die Meldungen aus der VDR-Funktion WriteAllOrNothing mit dem errno, die wären ja das Interessanteste ... Hat er das evtl. nicht kompiliert weil da vor dem "d" bei written=d das % fehlt?
    Er akzeptiert also erst keine Pakete und dann läuft der Buffer vom des VDR voll (driver Buffer overflow), was ja irgendwie logisch ist. Gibt's Meldungen bei dmesg?

  • Was ich vermisse sind die Meldungen aus der VDR-Funktion WriteAllOrNothing mit dem errno, die wären ja das Interessanteste ...
    Hat er das evtl. nicht kompiliert weil da vor dem "d" bei written=d das % fehlt?


    Da ist wohl was schief gelaufen,

    Code
    g++ -g -Wall -Woverloaded-virtual -Wno-parentheses -O0 -c -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DVDRDEBUG -DUSE_GRAPHTFT -DUSE_LIVEBUFFER -DREMOTE_KBD -DREMOTE_LIRC -DBIDI -DUSE_LIVEBUFFER -DLIRC_DEVICE=\"/dev/lircd\" -DRCU_DEVICE=\"/dev/ttyS1\" -D_GNU_SOURCE -DVIDEODIR=\"/var/lib/video.00\" -DCONFDIR=\"/var/lib/vdr\" -DPLUGINDIR=\"/usr/lib/vdr/plugins\" -DLOCDIR=\"/usr/share/locale\" -I/usr/include/freetype2   -I/usr/include/dvb-s2api-liplianin -I/usr/include/fribidi   tools.c
    tools.c: In function ‘int WriteAllOrNothing(int, const uchar*, int, int, int)’:
    tools.c:108:5: warning: too many arguments for format


    Anbei mal der ganze Ausschnitt, hab ich da was verbockt?


    Gibt's Meldungen bei dmesg?



    Das waren die letzten Meldungen, könnte da ein Zusammenhang bestehen?


    [UPDATE]


    FireFly
    Du hattest Recht, das fehlende % bei written=d war entscheidend, jetzt bekomme ich folgenden Output:

  • Code
    esyslog("VDR: writeallornothing: len=%d written=d errno=%d", Length, w, errno);
                                                               ^
                                                               %


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

Jetzt mitmachen!

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