VDR developer version 1.3.17

Hallo an alle,

möchte nur noch mal auf mich aufmerksam machen.
Ich dachte eigentlich, dass mein Posting "mundgerecht" verpackt war...

Gruß
Riscool

Zitat

Original von Riscool
möchte nur noch mal auf mich aufmerksam machen.
Ich dachte eigentlich, dass mein Posting "mundgerecht" verpackt war...

Such mal nach ring buffer overflow. Ich dachte dazu ähnliche logs gelesen zu haben.

Salvi, aber nicht wissend obs weiterhilft

Ich hab auch Probleme mit Ring Buffer Overflows mit einem frisch installierten LinVDR 0.7. Das Livebild beginnt zu stocken. Eine "wirkliche" Lösung oder Ursache des Problems habe ich über die Suchfunktion nicht finden können. Nur jemanden mit dem gleichen Problem und dem Hinweis, man möge doch den 2.4 Kernel wieder aufspielen. Aber das kann es doch nicht sein. Zumal bei mir LinVDR 0.6 mit 2.6 Kernel keine Probleme gemacht hat.

Mein System:
1x FF 1.3
1x Nexus-s

sowohl mit nem P2 350 als auch mit nem AhtlonXP 1600 tritt der Fehler bei 2 gleichzeitigen Aufnahem der Transponder Pro7&Co und RTL&Co auf. Von daher schliesse ich mal Hardwareprobleme aus.

Ich hab dann erstmal meine Suse 9.1 Platte mit vdr 1.3.12 eingebaut, die keine Probleme macht. Zum Testen werde ich mal die 1.3.17 auf die Suse bringen, um zu schauen, ob der Fehler dann wieder Auftritt und im Zusammenhang mit geanu dieser Version liegt.

Hi Dagget,

hast du es bereits mal mit SUSE probiert?
Ich hatte sonst mit den 2.6.x Kerneln keine Probleme mit Rring-Buffer-Overflows.

Wo kann man denn den Ringbuffer vergrößern?

Gruß
Riscool

Ich hab vielleicht den Übeltäter gefunden. Und zwar hatte die Zweitkarte keinen eigenen IRQ zugewiesen bekommen. Die Karte hatte sich mit eth0 (onboard) und der Grafikkarte einen IRQ geteilt.
Allerdings weiss ich nicht, ob dieser Umstand zu den Ring Buffer Overflows führt oder überhaupt darauf Einfluss hat.
Leider bin ich noch nicht dazu gekommen, die 1.3.17 auf Suse 9.1 zu kompilieren um das zu testen. Da das Problem bei anderen wohl nicht sehr häufig auftritt, könnte es das gewesen sein;)

Die IRQs habe ich "leider" äußerst sorgfältig verteilt. Ich denke, da brauch ich nicht zu schauen. Jede Karte benutzt ihren eigenen IRQ.

Mir fällt gerade ein, dass ich evtl. den IRQ des TT-FF von 11 auf 5 umstellen könnte, um die interne Priorität zu erhöhen. Vielleich wird dann der Ringbuffer schneller geleert.

Obwohl ich mir auch vorstellen kann, dass die Größe des Buffer zu moderat gewäht ist. Das Problem tritt ja nur bei Sendern mit viel "Abstrahlvolumen" auf.
Will heißen: Das Datenvolumen von SAT1 und Pro7 sind in der Regel größer als bei z. B. Kabel 1. Der AC3 Stream ist ja mehr als doppelt so groß, wie ein "normaler" Audio-Stream.

Die letzten Sätze sind allerdings reine Gedankenspiele. Auch wenn sie zumindest mir sehr plausibel erscheinen...

Gruß
Riscool

Auch wenn's unglaublich klingt, aber 15 hat hoehere Prioritaet als 5!

<Historie>
der XT hatte nur 8 Interrupts, die sich irgendwann mal als zuwenig erwiesen, woraufhin IBM mit dem AT den Interrupt 2 (!) auf weitere 8 Interrupts aufgebohrt hat.
</Historie>

Damit sind wir bei 15 Interrupts ("es wird niemand geben, der mehr als 15 Interrupts braucht" ).
Die Interrupts 9-15 werden ueber den IRQ2 "eingeschleift", der eine höhere Priorität als Dein IRQ5 hat.

Korrigier' mich jemand, falls das inzwischen bei modernen Chipsätzen anders sein sollte. Da aber auch der Itanium2 noch das A20-Gate hat, wage ich zu bezweifeln, dass jemals einer die heilige Kuh 'Abwärtskompatibilität' geschlachtet hat.

Gruss,
uwe

EDIT:
Siehe z.B. hier

Hallo Riscool,

wie läuft den der Vdr ohne die Patches?

bis dann LordZodiac

Zitat

Original von Riscool
Mir fällt gerade ein, dass ich evtl. den IRQ des TT-FF von 11 auf 5 umstellen könnte, um die interne Priorität zu erhöhen. Vielleich wird dann der Ringbuffer schneller geleert.

Ähm eine Frage wie stellst du die IRQ um ? Wird das nicht immer automatisch zugewiesen ? Oder legst du das im BIOS Fest ? Oder tauscht du die Karten in den Slots ? Nur das is mir bekannt aber das man das auch unter linux machen kann kenn ich nich.

Gruss,

Jörg

jackfritt
In den meisten BIOS Einstellungen gibt es die Möglichkeit die IRQs den PCI Steckplätzen zuzuordenen.
Leider gibt es hier aber meistens doppelt Belegungen z.B. wird der IRQ der AGP Grafikkarte mit dem PCI-Steckplatz 1 geshared.
Beläßt man alles auf Auto wird die Zuordnung durch das Betriebsystem vorgenommen und dieses ist oft nicht gerade Kreativ bei der Vergabe da dann meistens alles auf IRQ 9 oder 11 steht.

Hi all,

umaier:
Wenn das so ist, habe ich wohl in der Vorlesung gepennt.

LordZodiac:
Ganz ohne Patches darf ich ihn (Wegen meiner besseren Hälfte!) nicht laufen lassen.
Ich habe aber schon mal ohne AC3-Patch probiert. Da war es auch nicht besser.
Leider tritt das Problem nicht regelmäßig auf, so dass es mit dem Testen schwierig wird...
Edit:Und ohne configurableLNBshare-VDR_1.3.17 probiert.

jackfritt:
Das kann ich bei mir im BIOS relativ frei vergeben. Linux hält sich auch daran.
Nur so hatte ich es geschafft, dass sich nicht 5 Karten den gleichen IRQ teilen.

Gruß
Riscool

Genau!
Ohne dass ich mich selbst um die Vergabe kümmere, packt er bei mir alles auf Interrupt 11.

Hallo Riscool,

verwendest du irrgendwelche Plugins?

Ansonsten müßte man mal nach den Ringbuffer'n schauen.
Das erzeugt aber schöne Logausgaben.

Das Problem wird sein das er die Daten nicht wegbekommt und dadurch laufen dann die Puffer voll.

bis dann LordZodiac

Ich benutze folgende Plugins:

[list=1]
[*]autotimeredit
[*]clock
[*]dvd
[*]epgsearch
[*]femon
[*]games
[*]mp3
[*]mplayer
[*]pilot
[*]pim
[*]pluginsetup
[*]radio
[*]skincurses
[*]sleeptimer
[*]sysinfo
[*]text2skin
[*]timeline
[*]tvonscreen
[*]undelete
[*]vcd
[*]vdrcd
[*]vdrrip
[/list=1]

Wie kann man denn genauer nach den Buffern schauen?

in der ringbuffer.h gibt es eine Zeile

//#define DEBUGRINGBUFFERS

Wenn du die "//" entfernst und Vdr neu übersetzt, wird der Stauts der Puffer auf der Konsole ausgegeben.
Wenn ich mich Recht erinnere zeigt dabei ein "*" den Datenstand an.
Wenn du nur noch "*" hast ist der Puffer voll.

bis dann LordZodiac

Ich habe gerade mal die Zeile einkommentiert und neu übersetzt.
Danach habe ich den vdr manuell aus einer SSH Session heraus gestartet.

/usr/bin/vdr -L /usr/lib/vdr/plugins -Pautotimeredit -Pclock -Pdvd -Pepgsearch -Pfemon -Pgames -Pmp3 -Pmplayer -Ppilot -Ppim -Ppluginsetup -Pradio -Pskincurses -Psleeptimer -Psysinfo -Ptext2skin -Ptimeline -Ptvonscreen -Pundelete -Pvcd -Pvdrcd -Pvdrrip -v /video0 -c /etc/vdr -w 900 -E /ramdisk -s /usr/bin/poweroff.pl

Er schreibt jedoch weder ins Logs noch auf die Konsole.

Muss ich noch was beim starten beachten?

Gruß
Riscool

Nja Vdr muß im Transfermode laufen. Also zum Beispiel bei einer Aufnahme oder wenn du AC3 hören willst. Dann sollten die Ausgaben eigentlich kommen.

bis dann LordZodiac

Krass: Jetzt semmelt er, wenn ich eine Aufnahme mache, beim umschalten mit einem "Segmentation fault" ab.

...

Jetzt brauch ich nicht mal mehr umschalten und er stürzt ab...

Falls es dir hilft: Ich benutze deine FW:
Der VDR läuft jetzt mit folgenden Patches:
[list=1]
[*]vdr-1.3.16_disk_status_in_timer_menu
[*]enAIO 1.6
[*]chan_ok
[/list=1]

Gruß Riscool.
Und zwischendurch mal ein Danke für deine Hilfe.

Hä meine FW???
Du meinst Werner sein FW?

Durch die Änderung kann es sein das die Plugins auch neu übersetzt werden müssen oder einfach erstmal weglassen.

Ansonsten auf jedenfall "make plugins" machen.

bis dann LordZodiac

Hi,
da darf ich gerade mal meinen Senf dazugeben:
bei mir sieht es naemlich ganz aehnlich aus, wenn ich die CVS-Treiber verwendet.

Sobald eine Aufnahme auf der Budget laeuft brezelt's ihn hin. Reumuetig bin ich wieder zu den 2.6.9 kernel treibern zurueckgekehrt (WAF akut gefaehrdet). Ich hab's auch ohne plugins getestet. Gleiches Verhalten.

Gleich nach dem Einschalten sieht alles gut aus, aber wehe man bleibt beim Zappen kurz an einem Programm haengen.

uwe