You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

841

Friday, July 15th 2011, 11:57pm

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:

Source code

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:

Source code

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

Urig

Professional

Posts: 1,223

Location: Kassel

  • Send private message

842

Saturday, July 16th 2011, 4:01pm

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

Saturday, July 16th 2011, 5:27pm

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

Saturday, July 16th 2011, 5:38pm

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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

845

Saturday, July 16th 2011, 6:32pm

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.

Quoted


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.

Quoted


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!

Quoted


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

Saturday, July 16th 2011, 8:26pm

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

Saturday, July 16th 2011, 10:45pm

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

Saturday, July 16th 2011, 10:57pm

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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

849

Saturday, July 16th 2011, 11:36pm

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.

Quoted


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

Quoted


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

Posts: 5,464

Location: Main-Spessart

  • Send private message

850

Saturday, July 16th 2011, 11:57pm

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 | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

Urig

Professional

Posts: 1,223

Location: Kassel

  • Send private message

851

Sunday, July 17th 2011, 12:44am


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?

Quoted

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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

852

Sunday, July 17th 2011, 1:46am


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

Quoted


Quoted

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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

853

Sunday, July 17th 2011, 2:31am

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

Sunday, July 17th 2011, 9:27am

Moin!

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

Source code

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?

Source code

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?

Source code

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:

Source code

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

MegaV0lt

Professional

Posts: 1,028

Location: Ehem. Zentrum der Europäischen Union

  • Send private message

855

Sunday, July 17th 2011, 9:52am

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...
Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. [StGB §328 Absatz: 2 Nr.: 3]

VDR: Gen2VDR V5 u6; VDR 2.1.6; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: ASUS M3N78-EM, AMD Athlon 4850e, Zotac GT630 Zone Edition, 2GB RAM; DVB: 1x Digital Devices CineS2 Quad

856

Sunday, July 17th 2011, 10:22am

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

Sunday, July 17th 2011, 12:53pm

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:

Source code

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.

Source code

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.

Source code

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 has attached the following image:
  • OSD Timeouts.jpg
Freddy has attached the following file:
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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

858

Sunday, July 17th 2011, 12:54pm

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.

Quoted

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:

Quoted

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

Sage

Posts: 5,124

Location: Großherzogthum Baden

  • Send private message

859

Sunday, July 17th 2011, 1:16pm

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 has attached the following file:
VDR Remote Control Plugin (Version 0.5.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

Posts: 5,464

Location: Main-Spessart

  • Send private message

860

Sunday, July 17th 2011, 1:41pm

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 | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition