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

  • Also die "unbehandelte" Version von Powerman läuft bis jetzt sang- und klanglos! :wand

    Nein, ich habe mit der Version auch Probleme.

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Jul 14 12:20:13 htpc vdr: [1578] Text2Skin: channelInfo display update thread started (pid=1175, tid=1578) Jul 14 12:20:14 htpc vdr: [1576] VDR: writeallornothing: len=188 written=-1 errno=11 Jul 14 12:20:16 htpc vdr: last message repeated 138 times Jul 14 12:20:16 htpc vdr: [1576] ERROR: TS packet not accepted in Transfer Mode

    Kann es sein, dass eigentlich alle vom selben Problem betroffen sind, wie ich, bloß die verbose-Option für den Treiber nicht eingeschaltet ist? Hier wird doch auch irgendwas mit OSD gemacht, wenn ich das richtig sehe?


    AnK könntest du bitte die Option verbose für den Treiber einschalten? Ich habe dazu eine Datei dvb.conf (egal, wie sie heisst) unter /etc/modprobe.d angelegt mit dem Inhalt

    Code
    1. options saa716x_ff verbose=3


    Danach entweder den Rechner neu starten oder nur den Treiber neu laden. Ich habe Ubuntu x64, ich weiss nicht, ob es auf deinem System auch so sein muss, aber vielleicht weisst es ja viel besser, als ich, wie das geht :)


    Ausserdem tendiere ich immer mehr dazu, dass es irgendwo ein memory leak gibt, denn je komplexer die anzuzeigende OSD ist, desto schneller kommt es zum Problem. Mit dem Standard-Skin und großer Schrift, muss ich schon fasst eine Minute im OSD rummachen, bis es zu einem timeout kommt. Mit skineigmang geht es deutlich schneller.


    @Treiber-Entwickler (ich meine damit die Leute, die egal wie, an den Treiber arbeiten, powarman? UFO?)
    Ich hätte eine Frage zu diesem Schnipsel aus saa716x_ff_main.c


    Code
    1. if (phiISR) {
    2. dprintk(SAA716x_INFO, 1, "unknown interrupt source");
    3. SAA716x_EPWR(PHI_1, FPGA_ADDR_EMI_ICLR, phiISR);
    4. }


    Wann kann eigentlich dieser Fall eintreten? Ich habe öfters diese Ausgabe im Syslog. Wäre es nicht sinnvoll, den Wert von phiISR mit auszugeben? Gibt es vielleicht ein weiterer #define ISR_xxx, was in saa716x_ff.h fehlt/undokumentiert ist?
    Und zum Schluss noch eine Frage: gibt es eigentlich eine öffentlich zugängliche Beschreibung (SDK, DDK, oder wie auch immer die Dinger heissen) für die Karte?
    Viele Grüße,


    Freddy

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Ich habe nun mal ein 2 Minuten Stück geschnitten, wo eine zweite Tonspur (ENG) zugeschaltet wird (nach ca. einer Minute). Am VDR entstehen Bild- und Tonstörungen beim Abspielen. Der Fehler ist wohl in der Aufnahme schon drin, weil mit VLC der selbe Effekt zu sehen und Hören ist. Der Mediaplayer hingegen stürzt ab.

    Sowas habe ich auch schon bei SD-Aufnahmen bemerkt: nach ca 1 sec wird das BIld kurz pixelig, evtl. auch stotternder Ton und im VDR-Log gibts ne Meldung zum retuning. Ich gehe davon aus, dass der VDR früher einfach das BrokenLink-FLag im MPEG2-Strom gesetzt hat wenn er so etwas bemerkt hat. Heute wird der Stream nicht mehr analysiert, heute müsste das vermutlich die FW bzw. Ausgabedevice machen.

  • Wann kann eigentlich dieser Fall eintreten?

    Wenn der Kernel meint, der IRQ kommt vom Device, für den der Treiber zuständig ist, aber die HW dahinter hat gar keinen ausgelöst. Kann IMHO nur bei shared Interrupts kommen, evtl. reicht der Kernel die Interrupts auch an alle Treiber weiter, die diesen IRQ registriert haben bis ein Treiber signalisiert, das er ihn behandelt hat.

  • Kann es sein, dass eigentlich alle vom selben Problem betroffen sind, wie ich, bloß die verbose-Option für den Treiber nicht eingeschaltet ist? Hier wird doch auch irgendwas mit OSD gemacht, wenn ich das richtig sehe?


    Jein, also die OSD/Text2Skin Meldung kommt nur vom Umschalten. Problem bei mir ist, dass eigentlich so gut wie kein HD Kanal beim ersten Versuch angezeigt werden kann. Es kommt kein Bild und kein Ton, im Log stehen die Fehlermeldungen bzgl. buffer overflow und TS packet not accepted in Transfer Mode. Danach ist der VDR und der Treiber quasi tot, ein zurück schalten auf ein SD Kanal bringt auch kein Bild mehr. Da hilft nur VDR neustarten und DVB Treiber neuladen. Die Debug Meldungen (writeallornothing) kommen normalerweise auch nicht, die haben wir bei mir extra eingebaut.


    AnK könntest du bitte die Option verbose für den Treiber einschalten? Ich habe dazu eine Datei dvb.conf (egal, wie sie heisst) unter /etc/modprobe.d angelegt mit dem Inhalt

    Code
    1. options saa716x_ff verbose=3


    Danach entweder den Rechner neu starten oder nur den Treiber neu laden. Ich habe Ubuntu x64, ich weiss nicht, ob es auf deinem System auch so sein muss, aber vielleicht weisst es ja viel besser, als ich, wie das geht :)


    Alles klaro, hab ich gerade gemacht, hatte bis jetzt verbose=0. Btw. hab bei mir auch Ubuntu x64. ;)


    Ausserdem tendiere ich immer mehr dazu, dass es irgendwo ein memory leak gibt, denn je komplexer die anzuzeigende OSD ist, desto schneller kommt es zum Problem. Mit dem Standard-Skin und großer Schrift, muss ich schon fasst eine Minute im OSD rummachen, bis es zu einem timeout kommt. Mit skineigmang geht es deutlich schneller.


    Kann ich bei mir bei Gelegeneheit auch noch mal probieren, ob das Problem ohne Text2Skin ebenfalls besteht.

  • danke fürs ausprobieren, hivdr! Steht bei dir im syslog auch folgendes

    Code
    1. sti7109_raw_data (0): timed out waiting for data ready
    2. sti7109_raw_osd_cmd (0): timed out waiting for osd command ready

    Diese Einträge finde ich in den Logs nirgendwo, weder in der fraglichen Zeit noch seither. Könnte allerdings, wie hier mittlerweile angesprochen wurde, daran liegen, dass ich keine verbose-option gesetzt habe.
    Gestern hatte ich dann tatsächlich auch nochmal einen Total-Hänger, der nur durch Restart zu beheben war, und der auch nach OSD roch: mitten beim Blättern / Herumschalten im EPG war Schluss, die obere Hälfte des OSD zeigte den beabsichtigten neuen Inhalt, dann brach es ab und zeigte unten den Inhalt der vorigen Ansicht. Gewissermassen eine "Abrisskante" mitten in einer Zeile.


    Kann also auch bestätigen, dass mit dem OSD offenbar doch nicht alles so 100% OK ist, auch wenn bei normaler Nutzung nur selten sowas passiert. Hoffe die Ursache kann noch identifiziert werden.


  • Wenn der Rückgabewert die Länge der geschriebenen Daten sein soll, dann würde ich einfach mal Length (Parameter) zurückgeben?


    Bitte mal testen:


    Hier wird nie eine negative Zahl zurückgegeben, wenn mal WriteAll... z.b. -2 liefern würde (kenne die Funktion nicht, bin zu müde noch danach zu suchen :sleep ). Wenn ich richtig sehe, diese Prüfung fehlt in PlayTsVideo, dort wird nur der Fall -1 geprüft.


    Die Fehlerbehandlung spielt sich an verschieden Stellen ab und ist zT einfach nicht implementiert. Erstmal muss eine Behandlung für den Fehler -1 ( Code 11: EAGAIN) her (siehe UFOs Post)

    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

  • Bitte mal testen:

    Falls das die Klötzchenbildung beheben soll, so vermute ich, dass das leider nicht helfen wird. Verworfen ist verworfen, egal, wie man es letztendlich schafft. Das kann nur zu einem kaputten Stream führen und damit zu Klötzchen. Oder was beabsichtigst du mit der Änderung?

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Die Fehlerbehandlung spielt sich an verschieden Stellen ab und ist zT einfach nicht implementiert. Erstmal muss eine Behandlung für den Fehler -1 ( Code 11: EAGAIN) her (siehe UFOs Post)

    [Vermutung]
    Wenn ich aber davon ausgehe, dass ich einen Ringbuffer an der Funktion übergebe, und dann in der Annahme, dass in schlimmsten Fall 0 zurück kommt, auf meinen Buffer-Pointer den Rückgabewert addiere (ich weiss nicht, ob tatsächlich das passiert), dann sieht es ziemlich schlecht aus... :wow
    [/Vermutung]
    Kann die EAGAIN auch durch eine nicht signalisierte WaitQueue verursacht werden, wie bei

    Code
    1. timeout = wait_event_interruptible_timeout(sti7109->osd_result_avail_wq,
    2. sti7109->osd_result_avail == 1,
    3. timeout);


    Übrigens, ist es hier (thread)sicher, sti7109->osd_result_avail == 1 zu prüfen? In einem anderen Treiber (weiss nicht mehr, wo ich es gesehen habe) wird hier eine Art cancel-flag geprüft.

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Ich vermisse noch die Längenüberprüfungen im Treiber für

    Code
    1. #define SIZE_CMD_DATA 0x01A0 /* maximum size for command data (416 Bytes) */
    2. #define SIZE_OSD_CMD_DATA 0x0420 /* maximum size for OSD command data (1056 Bytes) */
    3. #define SIZE_FE_CMD_DATA 0x0040 /* maximum size for frontend command data (64 Bytes) */
    4. #define SIZE_BLOCK_DATA 0x3800 /* maximum size for block data (14 kB) */
    5. #define SIZE_LOG_MESSAGE_DATA 0x0080 /* maximum size for log message data (128 Bytes) */


    oder habe ich etwas übersehen? Wer weiss, mit welchen Daten der Treiber gefüttert wird?

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • :tup coole Comments :D

    Hier noch eins:


    // Freddy means, never return a negative value in cDvbHdFfDevice:: PlayTsVideo

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Hi,


    anbei zur Info, wenn bei mir das Problem mit Buffer Overflow und TS packet not accepted in Transfer Mode auftritt,
    dann beschwert sich auch der Treiber etwas, mit verbose=3:


    Code
    1. Jul 15 18:00:34 htpc kernel: [24420.062378] sti7109_raw_cmd (0): timed out waiting for command ready
    2. Jul 15 18:00:35 htpc kernel: [24421.061276] sti7109_raw_cmd (0): timed out waiting for command ready
    3. Jul 15 18:00:36 htpc kernel: [24422.060162] sti7109_raw_cmd (0): timed out waiting for command ready
    4. Jul 15 18:00:37 htpc kernel: [24423.059066] sti7109_raw_cmd (0): timed out waiting for command ready
    5. Jul 15 18:00:38 htpc kernel: [24424.057972] sti7109_raw_cmd (0): timed out waiting for command ready
    6. Jul 15 18:00:39 htpc kernel: [24425.056889] sti7109_raw_cmd (0): timed out waiting for command ready
  • Falls das die Klötzchenbildung beheben soll, so vermute ich, dass das leider nicht helfen wird. Verworfen ist verworfen, egal, wie man es letztendlich schafft. Das kann nur zu einem kaputten Stream führen und damit zu Klötzchen. Oder was beabsichtigst du mit der Änderung?

    UFO meinte ein paar Seiten vorher, dass es nicht so schlimm wäre, im Transfermodus ein paar Daten wegzuwerfen. Genau das soll die Änderung bewirken. Dem Treiber etwas Zeit zu geben (UFOs 1. Vorschlag) war ja nicht erfolgreich.

    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

  • // Freddy means, never return a negative value in cDvbHdFfDevice:: PlayTsVideo


    Guck Dir mal die tools.c des VDR an:


    Negative Werte sind also error codes...

    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

  • Hi,


    anbei zur Info, wenn bei mir das Problem mit Buffer Overflow und TS packet not accepted in Transfer Mode auftritt,
    dann beschwert sich auch der Treiber etwas, mit verbose=3:


    Code
    1. Jul 15 18:00:34 htpc kernel: [24420.062378] sti7109_raw_cmd (0): timed out waiting for command ready
    2. Jul 15 18:00:35 htpc kernel: [24421.061276] sti7109_raw_cmd (0): timed out waiting for command ready
    3. Jul 15 18:00:36 htpc kernel: [24422.060162] sti7109_raw_cmd (0): timed out waiting for command ready
    4. Jul 15 18:00:37 htpc kernel: [24423.059066] sti7109_raw_cmd (0): timed out waiting for command ready
    5. Jul 15 18:00:38 htpc kernel: [24424.057972] sti7109_raw_cmd (0): timed out waiting for command ready
    6. Jul 15 18:00:39 htpc kernel: [24425.056889] sti7109_raw_cmd (0): timed out waiting for command ready


    Sehr guter Hinweis, der Fehler kommt also aus der saa716x_ff_main.c Funktion: static int sti7109_raw_cmd(struct sti7109_dev * sti7109, osd_raw_cmd_t * cmd)
    Die Fehlermeldung erscheint nur, wenn:

    Code
    1. if (timeout == -ERESTARTSYS || sti7109->cmd_ready == 0) //TRUE
    2. if (timeout == -ERESTARTSYS) //FALSE


    d.h.
    sti7109->cmd_ready == 0
    Ich habe keine Ahnung was das bedeutet, aber ich forsche weiter...

    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

  • Ich bin so dermaßen vor der Tastatur eingepennt :sleep ... Die Woche war etwas lang...


    AnK : danke für die Info, anscheinend bin ich doch nicht so allein mit meinem Problem :) Bei dir ist es zwar nicht ein osd-command, was ein Timeout auslöst, die Ursache dürtfe aber auch ähnlich sein (eventuell bei der IRQ-Behandlung?)


    Mr_T : interessanter wäre zu wissen, wo PlayTsVideo aufgerufen wird. Was verwendest du als IDE? Mit gedit ist es ein Krampf, die Quelltexte zu durchsuchen...

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952

  • Mr_T : interessanter wäre zu wissen, wo PlayTsVideo aufgerufen wird. Was verwendest du als IDE? Mit gedit ist es ein Krampf, die Quelltexte zu durchsuchen...


    Ich benutze vim und bin außerdem ein c++ Boon. Wo PlayTsVideo aufgerufen wird, weiss ich ehrlich gesagt nicht.


    Ich habe mir die Funktion "sti7109_raw_cmd" mal genauer angesehen. Der Fehler tritt dann auf, wenn die Queue "sti7109->cmd_ready_wq" nicht innerhalb des Timeouts (1Hz) den passenden sti7109->cmd_ready Wert hat.


    Die zusätzliche Warterei auf dem höheren Level (dvbhddecive) bringt nichts, daher vermute ich, dass die Karte/Queue irgendwie "abgesoffen" ist.

    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

  • Noch etwas: An anderen Stellen werden die "osd_raw_cmd_t * cmd" Kommandos exklusiv gesperrt. Um dem Problem weiter auf die Schliche zu kommen, wäre es hilfreich, den letzten (hängenden) Befehl (osd_raw_cmd_t * cmd) sichtbar zu machen.


    Treibergurus :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

  • Ich habe mir die Funktion "sti7109_raw_cmd" mal genauer angesehen. Der Fehler tritt dann auf, wenn die Queue "sti7109->cmd_ready_wq" nicht innerhalb des Timeouts (1Hz) den passenden sti7109->cmd_ready Wert hat.

    Ja, soweit war ich auch schon. Diese und andere WaitQueues werden in der IRQ-Handler (?) signalisiert.

    Code
    1. static irqreturn_t saa716x_ff_pci_irq(int irq, void *dev_id)
    2. ...
    3. if (phiISR & ISR_READY_MASK) {
    4. /*dprintk(SAA716x_INFO, 1, "READY interrupt source");*/
    5. sti7109->cmd_ready = 1;
    6. wake_up(&sti7109->cmd_ready_wq);

    VDR 1.7.31 @ Ubuntu 12.04 x64, Kernel 3.2.0-31-generic
    Gigabyte H67A-UD3H-B3, Intel i5-2500K, 8 GB RAM, OCZ-Vertex4 128GB, Seagate 2TB
    1 x TT-6400 + 1 x DVBSky S952