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

Freddy · 14. Juli 2011

Zitat von AnK

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

Nein, ich habe mit der Version auch Probleme.

Freddy · 14. Juli 2011

Zitat von AnK

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

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

if (phiISR) {
			dprintk(SAA716x_INFO, 1, "unknown interrupt source");
			SAA716x_EPWR(PHI_1, FPGA_ADDR_EMI_ICLR, phiISR);
		}

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

FireFly · 14. Juli 2011

Zitat von MegaV0lt

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.

FireFly · 14. Juli 2011

Zitat von Freddy

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.

AnK · 15. Juli 2011

Zitat von Freddy

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.

Zitat von Freddy
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
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.

Zitat von Freddy

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.

hivdr · 15. Juli 2011

Zitat von Freddy
danke fürs ausprobieren, hivdr! Steht bei dir im syslog auch folgendes
Code
sti7109_raw_data (0): timed out waiting for data ready
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.

Mr_T · 15. Juli 2011

Zitat von Freddy

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:

Code

int cDvbHdFfDevice::PlayTsVideo(const uchar *Data, int Length)
{
  int pid = TsPid(Data);
  if (pid != playVideoPid) {
     PatPmtParser();
     if (pid == PatPmtParser()->Vpid()) {
        playVideoPid = pid;
        mHdffCmdIf->CmdAvSetVideoPid(0, playVideoPid, MapVideoStreamTypes(PatPmtParser()->Vtype()), true);
        }
     }
  int lengthOrErrorCode = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
  if (lengthOrErrorCode == -1) {
     //UFO said: Just discard the data, it is not important
     //Mr_T thinks: I have no idea how to discard the data, lets try Freddy's method
     lengthOrErrorCode = Length;
  }
  return lengthOrErrorCode;
}

Alles anzeigen

Zitat von Freddy

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 ). 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)

Gurkendieb · 15. Juli 2011

coole Comments

Freddy · 15. Juli 2011

Zitat von Mr_T

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?

Freddy · 15. Juli 2011

Zitat von Mr_T

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...
[/Vermutung]
Kann die EAGAIN auch durch eine nicht signalisierte WaitQueue verursacht werden, wie bei

Code

timeout = wait_event_interruptible_timeout(sti7109->osd_result_avail_wq,
							   sti7109->osd_result_avail == 1,
							   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.

Freddy · 15. Juli 2011

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

Code

#define SIZE_CMD_DATA		0x01A0 /* maximum size for command data (416 Bytes) */
#define SIZE_OSD_CMD_DATA	0x0420 /* maximum size for OSD command data (1056 Bytes) */
#define SIZE_FE_CMD_DATA	0x0040 /* maximum size for frontend command data (64 Bytes) */
#define SIZE_BLOCK_DATA		0x3800 /* maximum size for block data (14 kB) */
#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?

Freddy · 15. Juli 2011

Zitat von Morone

coole Comments

Hier noch eins:

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

AnK · 15. Juli 2011

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

Jul 15 18:00:34 htpc kernel: [24420.062378] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:35 htpc kernel: [24421.061276] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:36 htpc kernel: [24422.060162] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:37 htpc kernel: [24423.059066] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:38 htpc kernel: [24424.057972] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:39 htpc kernel: [24425.056889] sti7109_raw_cmd (0): timed out waiting for command ready

Mr_T · 15. Juli 2011

Zitat von Freddy

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.

Mr_T · 15. Juli 2011

Zitat von Freddy

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

Guck Dir mal die tools.c des VDR an:

Code

int WriteAllOrNothing(int fd, const uchar *Data, int Length, int TimeoutMs, int RetryMs)
{
  int written = 0;
  while (Length > 0) {
        int w = write(fd, Data + written, Length);
        if (w > 0) {
           Length -= w;
           written += w;
           }
        else if (written > 0 && !FATALERRNO) {
           // we've started writing, so we must finish it!
           cTimeMs t;
           cPoller Poller(fd, true);
           Poller.Poll(RetryMs);
           if (TimeoutMs > 0 && (TimeoutMs -= t.Elapsed()) <= 0)
              break;
           }
        else
           // nothing written yet (or fatal error), so we can just return the error code:
           return w;
        }
  return written;
}

Alles anzeigen

Negative Werte sind also error codes...

Mr_T · 15. Juli 2011

Zitat von AnK

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

Jul 15 18:00:34 htpc kernel: [24420.062378] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:35 htpc kernel: [24421.061276] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:36 htpc kernel: [24422.060162] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:37 htpc kernel: [24423.059066] sti7109_raw_cmd (0): timed out waiting for command ready
Jul 15 18:00:38 htpc kernel: [24424.057972] sti7109_raw_cmd (0): timed out waiting for command ready
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

if (timeout == -ERESTARTSYS || sti7109->cmd_ready == 0) //TRUE
if (timeout == -ERESTARTSYS) //FALSE

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

Freddy · 15. Juli 2011

Ich bin so dermaßen vor der Tastatur eingepennt ... 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...

Mr_T · 15. Juli 2011

Zitat von Freddy

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.

Mr_T · 15. Juli 2011

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

Freddy · 15. Juli 2011

Zitat von Mr_T

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

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

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

Jetzt mitmachen!

Teilen

Tags