Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

841

Freitag, 15. Juli 2011, 23:57

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.

Danke für die Info, FireFly. Ich hätte folgende Kandidaten:

Quellcode

1
2
3
4
5
6
7
8
Jul 15 17:13:53 Supernova kernel: [	0.837395] pci 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:53 Supernova kernel: [	0.837403] pci 0000:00:1c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:53 Supernova kernel: [	0.837422] pci 0000:00:1c.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:53 Supernova kernel: [	1.409861] xhci_hcd 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:53 Supernova kernel: [	1.457727] xhci_hcd 0000:01:00.0: irq 16, io mem 0xfbefe000
Jul 15 17:13:53 Supernova kernel: [   21.317953] SAA716x FF 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:57 Supernova kernel: [   25.252313] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jul 15 17:13:57 Supernova kernel: [   25.747893] cx88-mpeg driver manager 0000:06:02.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16

Trifft es auch bei Message Signaled Interrupts zu? Denn laut cat /proc/interrupts ändert sich bei 16 nichts:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
       	CPU0   	CPU1   	CPU2   	CPU3   	
 16:  	27417 	304933      	0      	0   IO-APIC-fasteoi   cx88[0]
 43:      	1      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 44:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 45:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 46:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 47:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 48:	8780068      	0      	0      	0   PCI-MSI-edge  	SAA716x Core
 49:	1503651   	6084  	57004      	0   PCI-MSI-edge  	i915

       	CPU0   	CPU1   	CPU2   	CPU3   	
 16:  	27417 	304933      	0      	0   IO-APIC-fasteoi   cx88[0]
 43:      	1      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 44:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 45:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 46:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 47:      	0      	0      	0      	0   PCI-MSI-edge  	xhci_hcd
 48:	8782420      	0      	0      	0   PCI-MSI-edge  	SAA716x Core
 49:	1504224   	6084  	57004      	0   PCI-MSI-edge  	i915
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

842

Samstag, 16. Juli 2011, 16:01

Bevor ihr noch ewig mit EAGAIN in PlayTsVideo kämpft:

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Bei Wiedergabe von Aufzeichnungen füttert VDR das Device so lange mit Daten, bis die Play-Funktionen mit EAGAIN signalisieren, dass sie voll sind. Würde man dann einfach Daten verwerfen, würde er in Festplatten-Lesegeschwindigkeit durch die Aufnahme jagen, und fast nichts anzeigen.

Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders. Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Gruß,

Udo

843

Samstag, 16. Juli 2011, 17:27

Hi,

eine Quelle habe ich für "unknown interrupt source" gefunden: ISR_FE_READY_MASK wird nicht berücksichtigt. Muss man hier noch irgendwas (anders) machen, als das, was in dem if-Block für unbekannte Interrupts passiert?

@Udo: danke für die Infos :tup , wo lernt man sowas?

Ich kämpfe immer noch gegen osd bzw. data timeouts... :wand
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

844

Samstag, 16. Juli 2011, 17:38

Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders. Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Danke für die Hinweise! Hast Du eine Idee, welches Kommando das sein könnte?
Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Bei mir passiert es auch gelegentlich, dass nachdem ich auf Pause gedrückt habe, die Aufnahme noch mehrere Sekunden weiter läuft und dann erst pausiert.
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

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

845

Samstag, 16. Juli 2011, 18:32

Bevor ihr noch ewig mit EAGAIN in PlayTsVideo kämpft:

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.

Bei Wiedergabe von Aufzeichnungen füttert VDR das Device so lange mit Daten, bis die Play-Funktionen mit EAGAIN signalisieren, dass sie voll sind. Würde man dann einfach Daten verwerfen, würde er in Festplatten-Lesegeschwindigkeit durch die Aufnahme jagen, und fast nichts anzeigen.

So weit richtig.

Zitat


Im Transfer-Modus kommen die Daten genau in dem Tempo vom Sender, wie sie die Karte wiedergibt. Damit beide die exakt gleiche Geschwindigkeit einhalten, synchronisiert sich das Ausgabedevice mit der Program Clock Reference des Senders.

Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

Zitat


Daher sollte EAGAIN in dieser Situation überhaupt nicht auftreten. Wenn es hier dennoch so massiv auftritt, ist es meiner Meinung nach eher ein Hinweis darauf, dass das Ausgabedevice seine Wiedergabe gar nicht begonnen hat. Ein Versuch eines Workarounds wäre, einfach nochmal die notwendigen Kommandos an die Karte zu schicken, die die Wiedergabe starten sollen.

Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Zitat


Als - vermutlich nicht zusammenhängende - Randnotiz: Mir ist schon mehrfach aufgefallen, dass manchmal die Umschaltung zwischen Play und Pause fehlerhaft ist, und bei Play nur der Ton losläuft, das Bild aber nicht. Selbst beim Umschalten von Pause auf Live-Modus habe ich das schon beobachtet. Ein 'harter' Sprung im Videostream (Seek der Aufnahme oder Senderwechsel) hilft dann.

Ich vermute, daß bei der A/V-Synchronisation noch irgendetwas faul ist. Manchmal fehlt ja auch der Ton.

CU
Oliver
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

846

Samstag, 16. Juli 2011, 20:26

Ich habe versucht, alles mögliche auszugeben, die ich im Treiber ausgeben kann :) Nun, wirklich schlauer bin ich nach 14 Stunden rumprobieren immer noch nicht. Das einzige, was aus den Logs ausgeht, ist, dass nach einiger Zeit im Interrupt-handler die Ereignisse ISR_DATA_MASK und ISR_OSD_READY_MASK nicht mehr eintreten, dadurch die WaitQueues nicht mehr aufgeweckt werden, was letzendlich zu den timeouts führt. Hat jemand eine Idee, wo die Ursache liegen könnte? Ich habe sogar die Anzahl Bytes zusammengezählt, die erfolgreich übertragen werden, bevor es zum timeout kommt. Es sind aber doch recht unterschiedliche, mal um die 16 MB, mal 26 MB.
:hilfe
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

847

Samstag, 16. Juli 2011, 22:45

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.


Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?
-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.


Was können wir tun, um Deine Vermutung zu bestätigen und der Ursache auf den Grund zu gehen?

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!


Sollte dafür dann die transfer.c geändert werden oder gibt es eine Art Flag, falls in der PlayTsVideo eine Aufzeichnung verarbeitet wird?
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

848

Samstag, 16. Juli 2011, 22:57

Ich habe versucht, alles mögliche auszugeben, die ich im Treiber ausgeben kann :) Nun, wirklich schlauer bin ich nach 14 Stunden rumprobieren immer noch nicht. Das einzige, was aus den Logs ausgeht, ist, dass nach einiger Zeit im Interrupt-handler die Ereignisse ISR_DATA_MASK und ISR_OSD_READY_MASK nicht mehr eintreten, dadurch die WaitQueues nicht mehr aufgeweckt werden, was letzendlich zu den timeouts führt. Hat jemand eine Idee, wo die Ursache liegen könnte? Ich habe sogar die Anzahl Bytes zusammengezählt, die erfolgreich übertragen werden, bevor es zum timeout kommt. Es sind aber doch recht unterschiedliche, mal um die 16 MB, mal 26 MB.

Guck Dir mal die Funktion "static irqreturn_t saa716x_ff_pci_irq(int irq, void *dev_id)" in der "saa716x_ff_main.c" an. Nimm mal in Zeile 1277 die Kommentierung raus, vielleicht siehst Du dann mehr.
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

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

849

Samstag, 16. Juli 2011, 23:36

Es ist vollkommen normal, dass EAGAIN in PlayTsVideo auftritt. Die Funktion heißt aus gutem Grund WriteAllOrNothing: -1/EAGAIN ist genau der "or nothing" Teil! Der Aufrufer der PlayTs-Funktion ist verpflichtet, auf EAGAIN zu reagieren, und die Daten später noch einmal anzubieten.


Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?

Ja, denn es gibt keine gleichnamige Methode in dvbhdffdevice bzw. dvbddevice.

Zitat


-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Es liegt imho nicht daran, daß die Daten nicht nocheinmal angeboten würden. Afaik macht VDR dies doch sowieso.

Zitat


Meine *Vermutung* ist, daß beim gepatchten Plugin die Daten an die Karte ausgegeben werden, wenn sie diese gar nicht annehmen kann. Dann laufen die Ringbuffer in VDR und Treiber über. Artefakte sind das Ergebnis.


Was können wir tun, um Deine Vermutung zu bestätigen und der Ursache auf den Grund zu gehen?

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!


Sollte dafür dann die transfer.c geändert werden oder gibt es eine Art Flag, falls in der PlayTsVideo eine Aufzeichnung verarbeitet wird?


Sorry, um dies alles korrekt zu beantworten, müßte ich mir die Sourcen im Detail vornehmen und einiges ausprobieren. Dann kann ich mir das Wochenende gleich abschminken. Kommt nicht in Frage, das letzte ging schon für DVB-Treiber drauf. Ihr müßt das schon selbst machen.

Was man noch ausprobieren könnte:
Fängt sich das ganze, wenn man in femon auf den anderen Tuner umschaltet?

CU
Oliver
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

850

Samstag, 16. Juli 2011, 23:57

Wie kommt ihr denn darauf, dass die Overflows nur im Live-TV auftreten.

Wenn ich zb etwas SyFy oder Disney Channel (womöglich auch auf anderen SDTV-Sendern) aufnehme und dabei die Taste 4 oder 6 gedrückt halte um eine Marke zu verschieben bekomme ich die selben Overflows wie ihr.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | Digital Devices Cine S2 V6 | ZOTAC GT630 (Rev. 2) Zone Edition

851

Sonntag, 17. Juli 2011, 00:44


Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

... und wieder was gelernt.

Letztlich kann der Clock der Karte und der des Senders aber doch nie 100% synchron sein, d.H. es muss zwangsläufig irgendwann zu einem frame drop oder zu einem fehlenden frame kommen, oder?

Zitat

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Das macht ja der transfer mode: Nach 100 Versuchen bzw. 1 Sekunde verwirft er das Paket. So wird man natürlich nicht viele Daten los, vermutlich wird daher der Receiver eher Daten verlieren.

Daraus ergeben sich mir ein paar Fragen:
-Ist es denn so, dass die PlayTs Funktion der normalen device.c verwendet wird?
-Wird das Verhalten, die Daten noch einmal anzubieten, nicht sowieso durch die Funktion "cTransfer::Receive" in der transfer.c abgedeckt (100x10ms warten...)?

Im Wesentlichen, ja.

Um den Weg der Daten mal nachzuzeichnen:
  • cTransfer ist die Kombination eines cReceiver und eines cPlayer.
  • Der cReceiver ist üblicherweise an ein cDvbDevice angehängt
  • cDvbDevice öffnet das Quelldevice, und übergibt den filehandle an ein cTSBuffer
  • cTSBuffer lässt in einem Thread (cTSBuffer::Action) einen 2Mb-cRingBufferLinear aus dem Device lesen (cRingBufferLinear::Read(int FileHandle...)). So lange der Buffer voll ist, wird auch nichts gelesen. cTSBuffer reagiert aber auf ein EOVERFLOW des Device ("driver buffer overflow on device 2"), falls der Treiber überläuft.
  • Der Thread von cDevice (cDevice::Action) holt über cDvbDevice::GetTSPacket() die Daten aus dem cTSBuffer ab, und übergibt sie an die zugehörigen cReceiver mittels Receive(), und damit auch cTransfer::Receive.
  • cTransfer::Receive übergibt die Daten unmittelbar an cPlayer::PlayTS - mit der 100x-Wiederholen Schleife.
  • Ein cPlayer wiederum ist immer mit einem Ausgabedevice verbunden, hier mit dem cDvbHdFfDevice.
  • cPlayer::PlayTs ist nur eine Weiterleitung an cDevice::PlayTs, welches ein wenig Streamanalyse macht, und die Daten unmittelbar auf PlayTsVideo und PlayTsAudio etc. verteilt.
  • cDvbHdFfDevice::PlayTsVideo und -Audio übergeben die Daten dann per Filehandle an den Treiber der 6400.


Der einzige Buffer ist also der des Receivers. Durch die 100x wiederholen und das sleep bleibt der cDevice-Thread nahezu stehen, und holt nur 1 Paket pro Sekunde vom cTSBuffer ab. Dieser muss also vollaufen, und so bald dieser voll ist, läuft auch der Treiber selbst über. So bald die 100 Versuche durch sind (TS packet not accepted in Transfer Mode), wird ein Paket verworfen, es entsteht Platz für ein Paket in cTSBuffer, und cTSBuffer versucht, weiter aus dem Device zu lesen. Dabei fällt dann auf, dass der Treiber übergelaufen ist (driver buffer overflow on device 2).

Man könnte höchstens noch auf das EOVERFLOW mit einem Leeren des cTSBuffer reagieren, damit wieder normal Daten abgeholt werden. Nur, so lange das Ausgabe-Device keine Daten annimmt, wird sich die Situation dadurch auch nicht bessern...


Gruß,

Udo

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

852

Sonntag, 17. Juli 2011, 01:46


Das ist falsch. Für das Ausgabedevice ist Transfermode das gleiche wie Wiedergabe von der Platte. Nix mit PCR!

So war es bei der alten FF-Karte (und ich vermute, hier ist es genauso):
Die Karte läuft mit ihrer internen STC. Die Clock-Abweichung zwischen Sender und Wiedergabe wird durch Pufferung in VDR bzw. Treiber ausgeglichen.

... und wieder was gelernt.

Letztlich kann der Clock der Karte und der des Senders aber doch nie 100% synchron sein, d.H. es muss zwangsläufig irgendwann zu einem frame drop oder zu einem fehlenden frame kommen, oder?

Völlig richtig. Allerdings sind die Pufferkapazitäten im Vergleich zur Abweichung so groß, daß dies erst nach sehr langer Zeit auftritt.
Wichtig ist natürlich, daß man die Ausgabe zum richtigen Zeitpunkt startet (Ringbuffer weder zu leer noch zu voll).

Zitat


Zitat

Daher mein Vorschlag, in so einem Fall die Daten wegzuwerfen. (Damit der Ringpuffer in VDR geleert wird.)
Sollte klar sein, daß man dies nur im Transfermode machen darf, nicht bei Wiedergabe einer Aufzeichnung!

Das macht ja der transfer mode: Nach 100 Versuchen bzw. 1 Sekunde verwirft er das Paket. So wird man natürlich nicht viele Daten los, vermutlich wird daher der Receiver eher Daten verlieren.

Falls man wirklich 1s warten muß, erfolgt zwangsläufig ein Pufferüberlauf - erst in VDR, dann im Treiber.
Und wenn gleichzeitig aufgezeichnet wird, ist die Aufnahme beschädigt.

Normalerweise sollten die 100 Versuche nicht zum Tragen kommen, es sei denn, es ist etwas faul.

CU
Oliver
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

853

Sonntag, 17. Juli 2011, 02:31

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.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

854

Sonntag, 17. Juli 2011, 09:27

Moin!

Ich wollte noch mal den Treiber frisch holen und kompilieren, aber einige Sachen wollen nicht mehr:

Quellcode

1
2
media_build_experimental/v4l/cx23885-cards.c:29:50: fatal error: ../../../staging/altera-stapl/altera.h: No such file or directory
compilation terminated.


Gibt es eine elegante Lösung, ausser die Datei manuell zu bearbeiten?

Quellcode

1
2
3
4
#include <linux/firmware.h>

#include "../../../staging/altera-stapl/altera.h"
#include "cx23885.h"


Ich habe einfach die Zeile in #include "altera.h" geändert. Welche Karte müsste man hier abwählen, damit das Kompilieren geht?

Quellcode

1
WARNING: "put_compat_timespec" [/home/nagyi/VDR/TT6400/fresh/media_build_experimental/v4l/v4l2-compat-ioctl32.ko] undefined!


Dies führt dazu, dass die Treiber für meine alten Karten nicht mehr geladen werden können. Einen Patch habe ich hier gefunden, damit geht es.

@Mr_T: ich war gestern den ganzen Tag in der von dir erwähnte Datei mit einem Editor unterwegs. Dadurch habe ich meine Infos im vorherigen Post bekommen.

@UFO: wäre es denkbar, diesen Code in saa716x_ff_main.c aufzunehmen, natürlich nur, wenn es richtig ist:

Quellcode

1
2
3
4
5
		if (phiISR & ISR_FE_READY_MASK) {
			SAA716x_EPWR(PHI_1, FPGA_ADDR_EMI_ICLR, ISR_FE_READY_MASK);
			phiISR &= ~ISR_FE_READY_MASK;
			dprintk(SAA716x_INFO, 1, "FE_READY interrupt source");
		}

Dadurch gibt es einen verwirrenden Eintrag weniger in syslog (direkt nach dem Laden des Treibers).

Gruß,
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

Beiträge: 1 280

Wohnort: Ehem. Zentrum der Europäischen Union

  • Nachricht senden

855

Sonntag, 17. Juli 2011, 09:52

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.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver
Zwangsläufig! Da ja die Tonspur dazugeschaltet wird. Mit VDR1.6 ist die "Störung" aber minimal. Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...
„Ein Teil dieser Antworten würde die Bevölkerung verunsichern“ [Innenminister Thomas de Maizière] November 2015

Gen2VDR V5.3 Update 7; VDR 2.2.0; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: ASUS M4A78LT-M, AMD Athlon II X2 240e, Zotac GT630 Zone Edition, 4 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5 [VDR-User #1540]

856

Sonntag, 17. Juli 2011, 10:22

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...

CU
Oliver
Zwangsläufig! Da ja die Tonspur dazugeschaltet wird. Mit VDR1.6 ist die "Störung" aber minimal. Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...
Diesen Fall hatte ich auch schon, ca 1s nach Aufnahmebeginn ist das Bild für ca. 1s verpixelt und im VDR Log findet sich die retuning Meldung. IMHO hat VDR 1.6 dann das Broken-Link Flag im MPEG 2 Datenstrom gesetzt (Logmeldung: ""SetBrokenLink: no GOP header found in video packet") weshalb es dort nicht aufgefallen ist, aber mangels Streamanalyse im VDR 1.7 ist das nicht mehr möglich ist. Kann man das für MEPG2 im Treiber oder FW realisieren?

857

Sonntag, 17. Juli 2011, 12:53

IRQ wird verschluckt?

Für mein Problem habe ich einen bösen Würgaround gefunden. Könnte auch bei anderen helfen, wie mit verbose=3 im Syslog eine Timeout (osd command, command oder data) stehen haben, denn so wie der Code war, kann nach einem dieser Timeouts nichts mehr weitergehen:

Quellcode

1
timeout = wait_event_interruptible_timeout(sti7109->cmd_ready_wq, sti7109->cmd_ready == 1, timeout);


Problem ist hier, dass wenn der Interrupt-handler static int __devinit saa716x_ff_pci_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id) einmal (warum auch immer, hier wird das tatsächliche Problem liegen) nicht ausgeführt wird, wird weder sti7109->cmd_ready_wq aufgeweckt, noch sti7109->cmd_ready jemals wieder auf 1 gesetzt. Wenn man nach diesen Timeouts aus den Prozeduren nicht mit -EIO aussteigt, sondern die Kommandos einfach absetzt, läuft alles wunderbar weiter, die IRQ-s kommen wieder, und die entsprechenden WaitQueus werden schön wieder aufgeweckt.

Quellcode

1
2
3
4
5
6
7
8
9
if (timeout == -ERESTARTSYS || sti7109->cmd_ready == 0) {
		if (timeout == -ERESTARTSYS) {
			/* a signal arrived */
			dprintk(SAA716x_ERROR, 1, "cmd ERESTARTSYS");
			return -ERESTARTSYS;
		}
		dprintk(SAA716x_ERROR, 1, "timed out waiting for command ready %lu. Let the shit go on...", timeout);
		//return -EIO;
	}


Diese Änderungen habe ich jeweils in folgende Prozeduren eingebaut (jeweils NUR DIE ERSTE timeout-Prüfung). Ausserdem den timeout aus von 1 auf 0,1 reduziert.

Quellcode

1
2
3
4
5
static int sti7109_raw_cmd(struct sti7109_dev * sti7109, osd_raw_cmd_t * cmd)

static int sti7109_raw_osd_cmd(struct sti7109_dev * sti7109, osd_raw_cmd_t * cmd)

static int sti7109_raw_data(struct sti7109_dev * sti7109, osd_raw_data_t * data)


Wenn's jemand probieren möchte, nur auf eigene Gefahr! Ich kann jedenfalls endlich die Karte genießen, ohne immer wieder zur Tastatur zu greifen, um den VDR neu zu starten. Es werden natürlich einige Befehle weiterhin nicht (richtig) ausgeführt, die Ursache des Problems ist mir immer noch unklar, dazu fehlen mir die Hardware-Level-Kenntnisse. Wie das OSD z.B. beim schnellen Vorlauf bei Wiedergabe aussieht und die Logfile dazu, sind im Anhang. Mit diesen Macken kann ich leben ;)

Grüße,
Freddy.
»Freddy« hat folgendes Bild angehängt:
  • OSD Timeouts.jpg
»Freddy« hat folgende Datei angehängt:
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

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

858

Sonntag, 17. Juli 2011, 12:54

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.

Die Datei enthält "Continuity Counter Errors", d.h. es fehlen Datenpakete. Klar, daß es dort eine Störung gibt.

Im Log steht nicht zufällig etwas von "retuning due to modification of channel". Das wäre dann die Ursache...
Zwangsläufig! Da ja die Tonspur dazugeschaltet wird.

Nein, das Zuschalten einer Tonspur verursacht keine Störung, sondern das Retuning!
Denn dadurch wird der Datenstrom bei den bereits vorhandenen PIDs kurzzeitig unterbrochen.

Dieses Verhalten liegt an VDR und nicht am Ausgabedevice. Ein Retuning ist unnötig, es würde genügen, die Tonspur zuzuschalten.

Zitat

Mit VDR1.6 ist die "Störung" aber minimal.

Liegt auch an VDR, denn 1.7 setzt z.B. an Schnittmarken nicht mehr das Broken Link Flag.
Auch mit der alten FF sieht man an Schnittmarken nun eine Verpixelung.

Daß die A/V-Synchronisation noch verbessert werden muß, habe ich weiter oben schon geschrieben:

Zitat

Es fehlen ein paar Frames; aber Standbild, Verpixelung, stotternder Ton ist erst seit der TT-6400 und HD VDR 1.7... Die Störungen sind schon relativ stark (mehrere Sekunden!). Im Treiber kann bestimmt noch was verbessert werden - allein in Bezug auf den Ton beim Springen oder Spulen. In der Zeitlupe spielt komischerweise auch Ton...


CU
Oliver
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

UFO

Erleuchteter

Beiträge: 5 408

Wohnort: Großherzogthum Baden

  • Nachricht senden

859

Sonntag, 17. Juli 2011, 13:16

IMHO hat VDR 1.6 dann das Broken-Link Flag im MPEG 2 Datenstrom gesetzt (Logmeldung: ""SetBrokenLink: no GOP header found in video packet") weshalb es dort nicht aufgefallen ist, aber mangels Streamanalyse im VDR 1.7 ist das nicht mehr möglich ist. Kann man das für MEPG2 im Treiber oder FW realisieren?

Unsinn, man kann es - zumindest für MPEG2 - ganz einfach in VDR realisieren.

Den angehängten Patch habe ich hier im Einsatz (und schon vor langer Zeit an Klaus geschickt).

CU
Oliver
»UFO« hat folgende Datei angehängt:
VDR Remote Control Plugin (Version 0.7.0): http://www.escape-edv.de/endriss/vdr
FAQ zum Remote Control Plugin: http://www.escape-edv.de/endriss/vdr/FAQ
Aktuelle Treiber: http://www.vdr-portal.de/board18-vdr-har…-s2-6400-teil-3
Full-TS-Mod für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-full-ts-mod bzw. hier
SDRAM-Erweiterung für SD full-featured Karten: http://www.escape-edv.de/endriss/dvb-mem-mod

860

Sonntag, 17. Juli 2011, 13:41

Ein Retuning ist unnötig, es würde genügen, die Tonspur zuzuschalten.


Hat das schonmal jemand Klaus gesagt?
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | Digital Devices Cine S2 V6 | ZOTAC GT630 (Rev. 2) Zone Edition

Immortal Romance Spielautomat