Leider nur teilweise gelöst: Ruckeln und Stottern bei Timeshift etc.

Liebe Leute,

wegen der besseren dxr3-Unterstützung bin ich kurz vor Weihnachten vom ct-vdr auf Linvdr umgestiegen und bin auch soweit sehr zufrieden damit. Dr. Seltsams dxr3-Paket ist wirklich klasse.

Nun zum Problem:
Sobald außer dem vdr noch irgendwas läuft (Aufnahme, timeshift, noad oder gar vdrconvert), beginnt nach 10-20 Minuten ein Ruckeln und Stottern, das einem das Fernsehen verleidet. Die Aufnahmen sind auch hinüber.

Das Problem tritt auf bei Kernel 2.6.9 und Dr. Seltsams 2.6.14.2 sowie 2.6.15 (2.6.15 subjektiv heftiger als die anderen Versionen). Außerdem alle vdr-Versionen, die ich mit Linvdr ausprobiert habe (1.3.12, 1.3.17, 1.3.24, und noch irgendeine 1.3.3x). Zum Testen hatte ich jeweils nur das dxr3-Plugin aktiviert.

Schaue ich nur fern, ist alles ok. Lasse ich den vdr während der Aufnahme in Ruhe, ebenso. In den Aufnahmen ist dann höchstens mal ein kleiner Ruckler.

Vom ct-vdr (vdr 1.2.6, Kernel 2.4.x) kann ich mich an sowas überhaupt nicht erinnern. Timeshift und stundenlange Parallel-Aufnahmen waren kein Thema (dafür gabs andere Probleme genug).
Die CPU-Belastung ist unter 10%, und im Log steht - Nichts. Nur ständig Meldungen über das OSD (siehe Anhang).

Ähnliche Probleme wurden hier unter Linvdr öfters berichtet, teils nur für FF Karten, teils für andere Spezialfälle. Eine Lösung habe ich nicht gesehen. Nach allem, was ich bisher ausprobiert habe, könnte es an der Kombination dxr3, Kernel 2.6 und vdr>1.2.6 liegen. An die CPU-Last und Daten-Transferraten glaube ich nicht, weil dieses Problem mit vdr 1.2.6 und Kernel 2.4 eben nicht auftrat.

Kennt jemand Kombinationen aus Kernelversion und vdr-Version (eventuell auch Version der dxr3-Treiber und des Plugins), die das Ruckelproblem "sicher" nicht haben?

Für Hinweise ist dankbar
Matthias

Moin Toxic,

den neuen Kernel und das dxr3-Plugin werde ich demnächst ausprobieren. Bisher hat das neueste vom neuesten allerdings keine Abhilfe gebracht ...

Die meisten Aufnahmen etc. mache ich tatsächlich auf der arte-Phoenix-N3-ARD-Frequenz (dvb-t). Ich werde nochmal versuchen, das Problem auf anderen Frequenzen nachzuvollziehen. Gibt es da welche, die man zuerst ausprobieren sollte?

AC3 benutze ich gar nicht.

Systemlast ist m.E. kein Thema, werde ich aber auch nochmal nachsehen. Bei Timeshift habe ich wie gesagt CPU deutlich unter 10% und außer vdr taucht bei top nichts auf, was nennenswert CPU braucht. Mit noad oder vdrconvert kann ich das Ruckeln auch erzeugen bzw. zusätzlich verschlimmern.

Vielen Dank jedenfalls für die Hinweise, ich melde mich sobald ich was Neues weiß,

Matthias

PS: Der Logauszug scheint wirklich normal zu sein, aber durch die vielen gleichen Meldungen sehe ich kaum noch was Wichtiges im Log. Es speichert ja auch nur ca. 400 Zeilen oder so. Kann man das eigentlich ändern?

Es war scheinbar doch das dvb-t-Signal bzw. die Antenne. Ich bin nochmal einen Abend lang mit der Antenne durchs Wohnzimmer geturnt und habe den Blick auf die BER von femon gerichtet. Jetzt liegt die Antenne horizontal auf dem Regal(!) und ich habe erstmals eine nur 3-stellige BER, jedenfalls bei arte/Phoenix/N3/ARD. Bei den anderen Sendern sind es 4 Stellen, aber es geht auch.

Timeshift macht jetzt kein Problem mehr. Ich hatte bereits früher schon den Eindruck, dass die dxr3 sehr empfindlich gegenüber fehlerhaften Daten ist. Und das kommt bei dvb-t scheinbar ständig vor.

OK, ich bin zufrieden, vielen Dank für Eure Tipps!

Zitat

Ich vermute mal, das die eine der beiden Nova-T-Karten noch die alte Karte ist. Die hatte ziemlich bescheidene Empfangseigenschaften.

So ist es. Mein Eindruck von der Neuen ist aber nicht grundsätzlich besser. In sowas habe ich mich aber schon oft getäuscht ...

Zitat

Interessant wäre jetzt mal, auf welche der beiden Budget-karten vdr beim Fernsehen bzw. beim Aufzeichnen zuerst zurückgreift. Bau doch mal die alte Karte aus...

Die alte Karte wird zuerst verwendet. Die neue könnte ich wahrscheinlich durch Tauschen der Modulreihenfolge auch zuerst laden (?). Leider kann femon sie aber nicht auslesen, es zeigt keine sinnvollen Werte. Ich nehme an, dass sie vielleicht zwei frontends besitzt, das Log beim Laden sieht irgendwie danach aus (kann ich bei Interesse nachliefern). Laut Homepage unterstützt femon solche Karten nicht.

Zitat

...und schaue, ob Du mit der neuen eine BER von unter 500 hinkriegst.

500 hex oder dezimal?

Viele Grüße,
Matthias

Wie gesagt, macht timeshift mit dem besseren Antennensignal keine Probleme mehr.
ABER ich habe jetzt wieder mal noad ausprobiert, und sofort ruckeln und stottern Bild & Ton unerträglich. Leider also erst ein Problem gelöst von mehreren. Mich verblüfft, dass keiner sonst das Problem hat.
Als einzige Chance sehe ich ein Update auf vdr 1.3.47 + dxr3-Module 0.15.3 + dxr3-plugin 0.2.6-cvs. Davon liest man ja viel Gutes, und das werde ich demnächst versuchen, wenn ich mal wieder zu viel Zeit habe.

Dr. Seltsam:
Alte Karte ausbauen und nur mit der neuen testen werde ich als Nächstes in Angriff nehmen. Andere Modulreihenfolge war natürlich Quatsch, brachte nur Ärger, und die alte war immer noch die erste Karte.
Danke für den Tipp mit der Empfangsqualität.
Übrigens: Wickys brandneues dxr3-deb-Paket müsste doch eigentlich mit Deinem 2.6.15 Kernel funktionieren? Er erwähnt immer nur Codys Kernel-Update-CD-Kernel.

Zunächst: dma ist "on", die Platte ist eine Samsung Spinpoint 160 GB, die sollte doch wohl schnell genug sein?

Inzwischen habe ich mal die alte nova-t ausgebaut und es nur mit der neuen probiert. Wenn der Rechner offen vor dem Regal steht, geht die BER schon mal um eine Stelle zurück (also Faktor 16). Leider kann er da nicht bleiben. Außerdem scheint der Empfang von der Kabelführung abzuhängen: hinter dem vdr sind die Antennenkabel etwas zusammengeknautscht. Wenn ich ihn aus dem Regal nehme, strecken sie sich natürlich. Das Geknautsche werde ich also demnächst zu reduzieren versuchen.

Femon liest die Karte (also die neue 90002) doch aus, nur die STR nicht. Die BER kriege ich mit gut ausgerichteter Antenne auf konstant 0 (das hatte ich zuerst für einen Fehler von femon gehalten). Es war auch gerade besonders gutes Wetter.

Mit einem optimalen Antennensignal kann ich nun auch fernsehn, während noad läuft (wieder ein Forschritt...).
Es bleiben reproduzierbare Abstürze: wenn noad läuft und ich den Sender wechsle, fehlt nach dem ersten Umschalten der Ton. Beim zweiten Umschalten stürzt das dx3-Plugin ab, wahrscheinlich auch der vdr, ich sehe ihn unter top jedenfalls nicht mehr. Das habe ich ca. 5 mal hintereinander gemacht (mit reboot), jedesmal absolut identisches Verhalten.

Ich habe es nicht geschafft, die Karten in den Slots so anzuordnen, dass die neue nova-t als primäres DVB-Interface geladen wird. Stets ist es die alte!

Ich habe auch mal versucht, den PCI-Bus zu entlasten, indem ich alle nicht notwendigen Devices im BIOS deaktiviere. Waren sie aber eigentlich schon. USB hatte ich schon längst deaktiviert, findet der Kernel aber trotzdem.

Fällt Euch zu den Abstürzen noch was ein? Vielleicht doch "das neueste vom neuesten" (vdr und dxr3-Module und -Plugin)?

Viele Grüße erstmal von
Matthias

Dr. Seltsam:

Zitat

Besserung bei offenem Gehäuse könnte auf Elektrosmog hindeuten

Wenn ich den Deckel wieder draufsetze und den vdr vorm Regal stehen lasse, bleibt die Verbesserung. Die Kabelführung scheint es also zu bringen.

Zitat

Die Reihenfolge der dvb-devices kann durch Änderung der Reihenfolge der Treibermodule in der runvdr bestimmt werden.

Ehrlich? Ich hatte damit keinen Erfolg. Wie weit oben kann ich denn die cx88-Module eintragen?

Zitat

Aber ein primäres device kann eine Budget glaube ich nie werden.

War wohl auch ungenau ausgedrückt. Wenn ich das richtig verstanden habe, ist für den vdr das "primäre DVB-Device" dasjenige, das die Wiedergabe übernimmt. Bei mir also stets die dxr3. Mir kommt es natürlich darauf an, welche Karte der primäre Empfänger wird.

@hummingbird_de
Guter Tipp, probiere ich, sobald ich zu Hause bin!

Vielen Dank an alle,
Matthias

... 32 bit i/o support war bereits aktiv - schade eigentlich.

Hallo nochmal,

jetzt habe ich die Module so angeordnet, dass die neue Karte (90002) als erste geladen wird. Geht also doch.

Außerdem Dr. Seltsams Kernel 2.6.15 vom 7.5.2006 installiert - wie immer problemlos. "Gefühlte" Umschaltzeit ist tatsächlich etwas kürzer.

Leider bleibt das Problem, das ich oben beschrieben habe: Wenn noad läuft und ich den Kanal wechsle, wird das TV-Bild dunkel und zuckt regelmäßig alle paar Sekunden. Das Log verrät, dass nichts abstürzt (wie ich zuerst dachte), aber die dxr3 Probleme hat. Ein kleiner Ausschnitt kommt hier. Das geht so lange, bis noad fertig ist, dann fängt sich das wieder, und alles läuft einwandfrei.

(...)
May  9 19:04:48 Calvin user.notice kernel: em8300: Microcode version 0x29 loaded
May  9 19:04:48 Calvin user.notice kernel: adv717x.o: Configuring for PAL
May  9 19:04:48 Calvin user.debug vdr[1607]: dxr3: configure: audio mode: analog
May  9 19:04:48 Calvin user.debug vdr[1607]: dxr3: resuscitation: device failure or user initiated reset
May  9 19:04:48 Calvin user.notice kernel: adv717x.o: Configuring for PAL
May  9 19:04:48 Calvin user.notice kernel: em8300_audio.o: Analog audio enabled
May  9 19:04:48 Calvin user.debug vdr[1607]: dxr3: resuscitation: reopening devices took 0 seconds
May  9 19:04:48 Calvin user.debug vdr[1607]: dxr3: configure: video mode: PAL
May  9 19:04:49 Calvin user.notice kernel: em8300: Microcode version 0x29 loaded
May  9 19:04:49 Calvin user.notice kernel: adv717x.o: Configuring for PAL
May  9 19:04:49 Calvin user.debug vdr[1607]: dxr3: configure: audio mode: analog
May  9 19:04:49 Calvin user.debug vdr[1607]: dxr3: audiodecoder: sample rate=48000
May  9 19:04:49 Calvin user.debug vdr[1607]: dxr3: audiodecoder: channels=2
May  9 19:04:49 Calvin user.debug vdr[1607]: clearing transfer buffer to avoid overflows
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.err vdr[1407]: dxr3: unable to play audio frame: Bad file descriptor
May  9 19:04:49 Calvin user.debug vdr[1608]: buffer usage: 0% (tid=163852)
May  9 19:04:49 Calvin user.debug vdr[1607]: dxr3: resuscitation: device failure or user initiated reset
May  9 19:04:50 Calvin user.notice kernel: adv717x.o: Configuring for PAL
May  9 19:04:50 Calvin user.notice kernel: em8300_audio.o: Analog audio enabled
May  9 19:04:50 Calvin user.debug vdr[1607]: dxr3: resuscitation: reopening devices took 1 seconds
May  9 19:04:50 Calvin user.debug vdr[1607]: dxr3: configure: video mode: PAL
(...)

Hier ist nochmal /proc/interrupts:

CPU0       
  0:     295236    IO-APIC-edge  timer
  4:         30    IO-APIC-edge  lirc_serial
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:       3065    IO-APIC-edge  ide0
 15:         26    IO-APIC-edge  ide1
169:          0   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
177:     115214   IO-APIC-level  em8300
185:        692   IO-APIC-level  eth0
193:     198122   IO-APIC-level  cx88[0], cx88[0]
201:      24994   IO-APIC-level  saa7146 (0)
NMI:          0 
LOC:     295210 
ERR:          0
MIS:          0

Und hier lspci:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3148
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:09.0 Multimedia video controller: Conexant: Unknown device 8800 (rev 05)
00:09.2 Multimedia controller: Conexant: Unknown device 8802 (rev 05)
00:09.4 Multimedia controller: Conexant: Unknown device 8804 (rev 05)
00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
00:0b.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD Decoder (rev 02)
00:10.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 80)
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3177
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74)
01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8d04

Anderes Netzteil probiere ich auch noch aus, aber dafür muss ich etwas Zeit einplanen..

In einem anderen Thread hatte jemand ähnliche Probleme, nachdem er eine neue Platte (übrigens auch eine Samsung...) eingebaut hatte. Gibts dazu mehr Erfahrungen?

Hat noch jemand eine Idee?

Viele Grüße,
Matthias

Hallo nochmal,

ich hab gerade mal den neuesten 2.6.17.8 von Dr.Seltsam installiert - wie immer ohne Probleme, alles läuft wie vorher.
Leider killt mir - auch wie vorher - ein laufendes noad die Ausgabe der dxr3. Fehler genau wie oben beschrieben. Schade um noad ... ich würde es soo gerne wieder automatisch für alle Aufnahmen starten.

Kann es sein, dass der 2.6er Kernel ein so viel schlechteres Timing (oder was auch immer) als der 2.4 bietet, dass die dxr3 bei laufendem noad einknickt?
Gibt es eigentlich eine Möglichkeit, den noad-Prozess auf z.B. 50% CPU zu beschränken? Er läuft schon mit nice-level 19.

Nach wie vor voller Hoffnung,
Matthias

Hej Tom,

wenn der vdr bei Aufnahmen ruckelt, kann das wahrscheinlich die verschiedensten Ursachen haben.

Wenn noad bei Dir ständig bei Aufnahmen mitläuft, wird es wohl in der runvdr zusammen mit vdr gestartet. In dieser Zeile kannst Du den Aufruf von noad (oder noadcall.sh oder was auch immer) löschen. Dann wird noad nur noch gestartet, wenn es über das Aufnahme-Menu für eine bestimmte Aufnahme aufgerufen wird.

Bei mir sieht es gerade wieder besser aus: Ich habe noch mal auf der Homepage von noad gestöbert und dort den Schalter "--background" gefunden. Den habe ich in meine noadcall.sh eingetragen und die reccommands.conf (oder so) geändert, so dass sie noad über die noadcall.sh startet. Beim manuellen Start von noad traten bis jetzt keine Fehler mehr auf.
Bis jetzt habe ich nur kurz angetestet, insbesondere online-Betrieb habe ich noch gar nicht probiert. Auch weiß ich nicht, worauf sich "--background" überhaupt genau auswirkt. Bin wieder voller Hoffnung, werde demnächst genauer berichten!

Viele Grüße,
Matthias

Hej Tom,

ein geteilter Interrupt wird oft als Problem berichtet. Ich nehme an, dass Du im BIOS einstellen kannst, dass dieser IRQ als "reserviert" oder "used by ISA" oder so behandelt wird. Dann müssten die IRQs neu verteilt werden.

Vielleicht hilft es auch, unbenutzte Peripherie im BIOS zu deaktivieren (Floppy-Controller, Parport, ...), um IRQs einzusparen.

Ich selbst hatte das Problem nie, sind daher nur Vorschläge.

Viel Glück,

Matthias