vdsb workaround

Zitat

Original von marpiet
jetzt verstehe ich gar nichts mehr - was macht vdr denn da (MARK)????

Der VDR macht da eigentlich gar nix, das kommt glaube ich vom Cron-Daemon.

[EDIT]
Stimmt gar net, habe gerade gelesen, das es sich dabei um ein Syslog Interna handelt.
Genau Bedeutung und Funktion kann ich dir jetzt leider auch nicht sagen,
aber wird es schon wissen...

Zitat

Original von AnK
das kommt vom Cron-Daemon.

das hatte ich hier auch:
Dec 10 20:00:04 vdr -- MARK --
Dec 10 20:17:01 vdr /USR/SBIN/CRON[6913]: (root) CMD ( run-parts --report /etc/cron.hourly)
Dec 10 20:40:04 vdr -- MARK --
Dec 10 21:00:04 vdr -- MARK --

Dürfte ich noch freundlich nachfragen, was das nun bedeutet ?

gruß

marpiet

marpiet:

Hi, Sorry hier die verspätete Antwort:

Ich habe in der runvdr (in der Schleife nach Treiberentladen) einen zusätzlichen "zap " Block eingefügt. Da ich nur 2 Karten habe, sind nur die ersten beiden Zeilen aktiv. Außerdem habe ich das 1 + 2 Prg gezapt.
(erste Zeile in der channel.. Datei ist eine Kanalgruppenbezeichnung.

Parameter kannst Du mit zap --help abfragen.

Also damit klappt es bei mir. Ich habe aber die klassische TV Karten Variante TT 1.5 + TT Budget.

Viel Erfolg Norbert.

zum -- MARK --
das ist eine art zeitstempel, damit man sieht, das System läuft noch...

habte schon immer probleme mit der VDSB und restart des VDR vor einen Aufnahme, aber jetzt mit drei Karten (2xFF+1Nova) ist das unschön, wenn das bei der zweiten Aufnahme passiert...darum habe ich auch mal den VDSB_WORKAROUND eingebaut, mal sehn ob es hilft...ich hoffe.

Gibts da nicht eine bessere Firmware für die DVB??? oder sind die neueren DVB Treiber genau so fehleranfällig???

berichte ob es was hift...erst mal beobachten...

Ich sage es immer wieder, mein Wechsel von 1.2.6 auf 1.3.10 hat Wunder getutet. Nur mal so als Versuch! Wieso sich mit Altem rumärgern?

bei mir Nexus + Nova krachts auch mit der vdr 1.3.xx. Hab ansonsten die ctvdr 3 im Einsatz. DVB Treiber gewechselt, Karten vertauscht, Kabel durchgemessen und umgesteckt -- nix hat gholfen....

Nach wie vor wundert mich dass die femon Ausgabe bei einer Karte immer in regelmåssigen Abständen Status 02 ausspukt und sonst alles gleich ist.

Bevor ich jetzt wieder Geld zum Fenster raus werfe fuer ne neue Karte, gibts denn gar keine Aussicht auf ne Lösung ??

Um das zu klären:

MARK kommt vom Syslog-Deamon und ist in der Tat eine Art Zeitstempel. es dient dazu den ungefähren Zeitpunkt eines System-Crashes festzustellen. Der Daemon schreibt regelmäßig diesen Entrag, wenn sonst nichts passiert und sorgt dafür, dass es auf der Platte landet.

Wenn das System abstürtz, dann kann man am diesen Eintrag erkennen wann es war.

Volker

bei mir hat es geholfen, bis jetzt nicht eine aufnahme verlohren...restartet aber ab und an noch wenn die aufnahme beginnt...aber zum glück nur bei der ersten aufnahme

Ich habe das Problem auch nicht mehr, seitdem ich den EPG Scan abgestellt habe. Das EPG habe ich trotzdem,weil
a) Das EPG immer aus dem aktuellen Transponder aktualsiert wird.
b) ich TVMovie2VDR installiert habe.

Gruß
beagle

Mal eine kleine Zwischenfrage an jene, die den VDSB-Workaround erfolglos einsetzen: Wie sieht die erste Zeile Eurer channels.conf aus? Ist da direkt ein Kanal drin oder habt Ihr einen Abschnitts-Text eingefügt:

:Privatsender
RTL...
Sat.1...

Das mag der Workaround nähmlich gar nicht, da der den szap nur auf die erste Zeile der channels.conf los lässt. In der ersten Zeile muss also zwingend ein gültiger Kanal liegen, sonst bricht szap mit Fehler ab und ihr merkt das nicht.

Ich bin mir jetzt nicht sicher, aber glaube dass bei mir trotz EPG-Scan=0 die Kiste abschmiert. Werd ich morgen abend testen.

Andere Frage. Dieser Workaround in der runvdr. Wird der ueberhaupt ausgefuehrt, wenn man ueber /etc/init.d/vdr start die Muehle anwirft.

Wenn nein, wie kann ich das bewerkstelligen. Die Variable VSDB_WORKAROUND ist in /etc/default/vdr gesetzt.

Gruss eines verzweiflers

Hallo,

ich will ja nicht nervern, könnten bitte jene, die trotz VDSB-Workaround noch Probleme haben. prüfen was ich 2 Beiträge vorher geschrieben habe und Ergebnisse hier posten?

schluzkrapfn:
Ich hoffe Du hast nur beim Abschreiben des Parameters für Deinen Beitrag hier einen Typo drin, denn es muss heißen VDSB_WORKAROUND="yes"

@all:
noch was. In /usr/sbin/runvdr und ...runvdrdevel ist meiner Ansicht nach ein Fehler: Hier wird szap zweimal mit dem Parameter -a 3 aufgerufen. Der Adapter 2 wird hingegen nicht abgearbeitet. Ist natürlich nur relevant, wenn jemand mehr als 2 DVB-S Karten eingebaut hat. Also notfalls so ändern das jeweils einmal die Adapter 0 bis 3 angesprochen werden (Adapter 0 = erste DVB-Karte).

Wenn man den Parameter -n 1 auf 2 oder 3 setzt, kann man den Fehler vermeiden, den ich zwei Beiträge vorher beschrieben habe...

Zitat

ich will ja nicht nervern, könnten bitte jene, die trotz VDSB-Workaround noch Probleme haben. prüfen was ich 2 Beiträge vorher geschrieben habe und Ergebnisse hier posten?

hallo,

vor meiner twinhan-kare, also mit skystar 2.6 hatte ich ständig probs mit VDSB. in der tat hatte ich meine channels.conf editiert:
:hauptsender
....

somit hatte wohl szap bei mir nie funktioniert......

aktuell habe ich den workaround aktiviert - die twinhan braucht ihn wohl nicht.

gruß

marpiet

HolgerAusB
Jo, war ein Tippfehler. Hab zwischenzeitlich die Karte zurückgegeben und das Geld mitgenommen. Jetzt such ich nach ner "gesunden" Alternative.

Thanks

Alle die probleme mit VDSB haben sollten erstmal auf der Console "cat /proc/interrupts" eingeben. Bei der Ausgabe sollten unten bei ERR sowie bei MIS eine 0 stehen, ist das nicht der Fall kann ich mir die VDSB`s gut erklären.

Wer da nicht 0 stehen hat postet doch bitte mal seine Werte. Evtl. kann man da durch umstecken der Karten, deaktivieren von APIC und ACPI etwas machen.

EDIT: Postet doch bitte auch noch welchen Chipsatz euer Mainboard hat.

Gruß Tüddelkopp

Hi tüddel,

Du hast es so gewollt, hier die Interrupts

vdr:~# cat /proc/interrupts
           CPU0
  0:      88096          XT-PIC  timer
  1:          2          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:          0          XT-PIC  NVIDIA nForce Audio, ehci_hcd
  4:        258          XT-PIC  lirc_serial
  5:     439695          XT-PIC  ohci1394, saa7146 (0)
  8:          4          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:      94933          XT-PIC  usb-ohci, eth0, saa7146 (1)
 11:          0          XT-PIC  usb-ohci
 14:      52527          XT-PIC  ide0
 15:          3          XT-PIC  ide1
NMI:          0
LOC:      88057
ERR:     298929
MIS:          0

Ich habe ein DFI lanparty nforceII Motherboard. Die budget Karte muss sich den Interrupt mit dem (unbenutzten) USB und dem etwas benutzten Netzwerk teilen.
Ich habe beim Start einer Aufnahme auf dem Device 2(TT budget) oft einen vdsb. Die Interrupts sehen allerdings auch wüst aus ...
Wie bekommt man heraus, welcher IRQ es ist? Ausser einem uninteressanten spurious IRQ7 sehe ich im log nix.

USB könnte ich beim booten in ??modules?? lahmlegen, wenn ich es dann bei Bedarf laden könnte, nur weiss ich nicht genau wie ...

Gruss, Schrauber

Ich hatte diese Probleme auch einmal. Und ich kann nur sagen ACPI ab Kernel 2.6.10 hat bei mir Wunder gewirkt. Seitdem ich dort ACPI eingeschaltet habe bekommt bei mir wirkliche jedes Gerät seinen eigenen IRQ Wie hier schön zu sehen ist.

cat /proc/interrupts
CPU0
0: 191868070 IO-APIC-edge timer
1: 8 IO-APIC-edge i8042
8: 7783388 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 587350 IO-APIC-edge ide0
15: 346 IO-APIC-edge ide1
16: 28897098 IO-APIC-level fcdsl
18: 85082429 IO-APIC-level saa7146 (0)
19: 13117320 IO-APIC-level saa7146 (1)
20: 22467194 IO-APIC-level eth0
21: 0 IO-APIC-level NVidia nForce2
22: 14 IO-APIC-level ehci_hcd
NMI: 0
LOC: 190748870
ERR: 0
MIS: 0

lspci -v schafft euch auch nochmal Klarheit welche Interupts von den einzelnen Geräten genutzt werden. Hat mich auch sehr geholfen.

Gruss,

Jörg

schrauber: Du hast ja Tonnenweise Interrupt Errors zu sehen bei ERR. Du solltest mal versuchen durch umstecken der Karten und deaktivieren der unbenutzten Sachen ( USB, Firewire ) die Lage etwas zu entspannen. Ausserdem würde ich mal verschuchen ACPI zu deaktivieren. ( acpi=off in der Kernel command line ) Das du bei den vielen ERRs VDSB`s bekommst wundert mich nicht. Der spurious Interrupt 7 ist garnicht so uninteressant, der wird nämlich beim ersten ERR geloggt.

ES sollte so aussehen wie bei Jackfritt, nämlich KEINE ERRs

Zitat

Gibt es den unter e-tobi.net beschriebenen vdsb workaround eigentlich auch unter ctvdr?

Entschuldigt, aber ich war eben auf ww.e-tobi.net, aber wo finde ich da das "vdsb workaround"?

Vielleicht bin ich blind, habe aber nichts gefunden...

Gruß
Sven

nach dem installieren im init skript (/etc/init.d/vdr)