Bugfix "video data stream broken" schon umgesetzt?

Hallo,

ich habe die aktuelle out-of-the-box ctvdr 3 Version, softwareseitig keine weiteren Änderungen vorgenommen (außer apt-get upgrades), sowie eine Nexus 2.1 (device 1) und eine Skystar 2.6c (device 2) im System .

Auch bei mir das Problem:

Bei nahezu jeder Timer-gesteuerten ersten Aufnahme, die ja immer auf dem letzten device (in meinem Fall skystar) gestartet wird, startet der VDR wegen des vdsb errors der skystar neu. Für den Neustart werden ca. 50 Sekunden benötigt, die Aufnahme läuft dann allerdings ordnungsgemäß durch.
Von daher ist das auch noch nicht weiter schlimm (außer dass die Aufnahme ca. 50 Sekunden später begint), da:

a)
die erste Aufnahme immer auf dem letzten device (in diesem Fall device 2 - skystar) gestartet wird und somit keine andere bereits laufende Aufnahme durch einen Neustart des VDR beeinträchtigt werden könnte und

b)
im Falle des Startens einer zweiten (gleichzeitgen) Aufnahme ja dann die Nexus (device 1) verwendet wird, die jedoch keinen vdsb error produziert.

Somit habe ich in der Praxis damit derzeit noch kein Problem, außer dass ich Video-Dateien mit 0 Byte Größe habe - die jedoch vom VDR gehandelt werden können - und ich im Log-File eben diese unschönen Restarts sehe.

Ich spiele allerdings mit dem Gedanken, eine dritte Budget-Karte (weitere Skystar oder Nova-S) in das System zu geben. In diesem Fall würde dann die erste Aufnahme auf dem letzten device 3 starten (allenfalls auch da bereits mit einem restart - was allerdings noch egal wäre), die zweite (gleichzeitige) Aufnahme würde dann auf device 2 (skystar) starten, dann jedoch wohl einen vdsb-error produzieren, den VDR neu starten und somit auch die laufende Aufnahme auf device 3 in Mitleidenschaft ziehen.

Im oben genannten Fix (http://www.vdr-portal.de/board/thread.php?threadid=28559&sid=&threadview=0&hilight=&hilightuser=0&page=1) scheint es hierfür jedoch eine Lösung zu geben, die diesen vdsb-Error bei Budget-Karten beheben soll.

Da ich nicht der ultimative Linux-King bin auch meine Frage, ob schon jemand für die out-of-the-box ctvdr 3 Version (ctvdr 1.2.6-27, kernel 2.4.27-ctvdr-1) ein "out-of-the-box"-Debian-Paket gebastelt hat und dies eventuell zur Verfügung stellen könnte?

Viele Grüße!

Franz, alias angelosarikis

Wieso denkt ihr, dass der Patch das Skystar2-Problem löst? Der Patch ist doch für saa7146-basierte Karten (also Nova etc), während die Skystar2 den "B2C2 FlexCopII" Chip benutzt?

Würde mich natürlich auch freuen, da ich genau das selbe Problem habe (TT1.5+Skystar2).

Zitat

Original von kilbert
Wieso denkt ihr, dass der Patch das Skystar2-Problem löst? Der Patch ist doch für saa7146-basierte Karten (also Nova etc), während die Skystar2 den "B2C2 FlexCopII" Chip benutzt?

Würde mich natürlich auch freuen, da ich genau das selbe Problem habe (TT1.5+Skystar2).

Schade!

Bei drei Karten wäre dann zunächst die Lösung, die Skystar als letztes device (3) zu verwenden und als device 2 eine Nova. Ich gebe dennoch die Hoffnung nicht auf, dass das Problem ja irgendwann mal auch bei der skystar in den Griff zu bekommen sein müsste.

In Österreich sind derzeit Nova-s (und Nexus) leider kaum zu bekommen => Hauppauge: bitte mehr produzieren!

Gruß

Angelosarikis

Hoffentlich tut sich hier bald etwas, seit 3.06 kommt der Fehler regelmäßig, vorher war er bedeutend seltener.
Ich werde aber mal szap vor dem Starten rausnehmen, vieleicht liegt es daran?

cu

bau dir halt selbst einen neuen treiber ... anleitungen findest du in genau diesem forum

das es an eurer konfiguration hängt habt ihr alle schon ausgeschlossen? jede karte hat einen irq für sich? acpi an/aus?

Zitat

Original von dunar
das es an eurer konfiguration hängt habt ihr alle schon ausgeschlossen? jede karte hat einen irq für sich? acpi an/aus?

ACPI ist aus, APM an, aber die Interrupts sind mehrfach belegt (siehe unten). Wie belege ich denn die IRQs um?

Der Kernel sagt mir öfters "spurious 8259A interrupt: IRQ7." - das ist aber wohl mein an lp0 hängendes LCD und deswegen okay.

visor:~# cat /proc/interrupts 
           CPU0       
  0:     117710          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  4:       6830          XT-PIC  lirc_serial
  8:          4          XT-PIC  rtc
  9:          0          XT-PIC  ehci_hcd
 10:     508880          XT-PIC  via82cxxx, usb-uhci, saa7146 (0)
 11:       1841          XT-PIC  usb-uhci, eth0
 12:      44599          XT-PIC  usb-uhci, Skystar2
 14:      11291          XT-PIC  ide0
 15:          2          XT-PIC  ide1
NMI:          0 
LOC:     117669 
ERR:         72
MIS:          0

einstellen kannst das mit etwas glück im bios, mit weniger glück acpi anmachen und hoffen das linux die verteilung gut macht

da ich ein sch... oenes asus habe (mit dem msi kt266 pro2 ging das im bios einwandfrei) hab ich es mit acpi gemacht, sieht dann in etwa so aus:

das "interrupt 7 ..." kommt vom lpt hat irgendwie jeder, schaded aber nichts

CPU0       
  0:   86926998          XT-PIC  timer
  1:     154907    IO-APIC-edge  keyboard
  3:    4627484    IO-APIC-edge  serial
  4:     595468    IO-APIC-edge  lirc_serial
  8:  892936733    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:    6423034    IO-APIC-edge  PS/2 Mouse
 14:   24300692    IO-APIC-edge  ide0
 15:    8790236    IO-APIC-edge  ide1
 16:   48663512   IO-APIC-level  saa7146(2)
 17:   10324646   IO-APIC-level  ohci1394, EMU10K1
 18:  395830238   IO-APIC-level  saa7146(1)
 19:  909933692   IO-APIC-level  saa7146(0)
 22:   88974415   IO-APIC-level  eth0
NMI:          0 
LOC:   86927045 
ERR:          0
MIS:          0

weidnerd

ich hab den treiber benutzt den kls in seinem vdr 1.3.19 thread erwähnt hat, war allerdings zu faul ein package zu bauen also so compilt und benutzt, die letzte wochen auch in irgend einem thread geschrieben wie/was zu tun ist