Warum braucht UpdateOsdSize viele Sekunden?

Hallo,
bei der Suche warum VDR oft die FB-Befele stark verzögert verarbeitet, habe ich einige Log-Einträge in vdr.c hinzugefügt.
Damit kann ich sehen, dass cOsdProvider::UpdateOsdSize viele Sekunden benötigt (oft 4..6, manchmal auch länger).
Eigentlich ist es dieser Aufruf in der Funktion:
cDevice::PrimaryDevice()->GetOsdSize(Width, Height, Aspect);
Der wird in das dvbsddevice weitergeleitet (Tuner ist abgeschaltet). Dort habe ich bisher noch keine Log-Einträge eingebaut.

Version ist 2.01 (yaVDR dirty).

Hat jemand eine Idee warum solche langer Verzögerungen entstehen?

Hallo Steffen,
patch kann ich machen, ist allerdings Q'n Dirty (halt wegwerf Code). Im Prinzip funktionierts wie die MaxLatency. Die ist übrigens ein guter Indikator dass das Verhalten auftritt und zeigt es ebenfalls an. Maxlatency steht ja schon in den logs.

Es tritt sporadisch auf, hatte schon alles mögliche im Verdacht (EPG-Scan, externe Tools wie Mediatomb. Backuppc usw). Öfters kurz nach dem Starten des VDR (des Programms, nicht des PC).
Wenn ich die Cine C2 ausbaue tritt es nicht mehr auf. Die hat aber nichts mit dem OSD zu tun... IRQ-Konflikte könnten noch sein. Ein Wechsel des PCI-Slots hat allerdings nichts am Verhalten geändert. Leider müssen sich beide PCI-Slots den IRQ mit anderen Geräten teilen (einmal USBs und Sound, der andere AHCI).

Es gab schon öfters Anfragen hier wegen verzögerter Verarbeitung der Tastendrücke (aber keine Lösung). Ob es immer dieser Effekt ist, kann man sicher nicht sagen.

Das Ganze ist nur damit ich endlich auf HD umstelle....

Hallo,
hier kommt der Patch zur VDR 2.0.1 yaVDR sources.
In der Hauptschleife (vdr.c) werden Logeinträge hinzugefügt.(über Funktion: void LogTime(int position, time_t start)).
Jeder Stelle bekommt eine eindeutige Nummer, so dass man vom log auf den Quelltext schliesen kann.
Es wird nur ins log geschrieben wenn die Zeit zwischen den Aufrufen mehr als 4 Sekunden ist. Oder wenn die Zeit vom Anfang der Schleife (now) mehr als 12 Sekunden ist.
Bei mir kommt dfPos6 (vdr.c) und davor dfPos1000 (osd.c). Beide sagen das Gleiche aus.
Die Nummern sind aus historischen Gründen etwas chaotisch. Habe mich an die Stelle herangetastet....

Der Patch enthalt auch logs und eine Verbesserung in lirc.c. Damit ignoriert der VDR nicht mehr Wiederholungscodes von lirc wenn mal ein/zwei Codes verschluckt werden (war anderes Problem, dafür gibt es einen extra Thread). Wirkt sich nur aus wenn lirc Codes verschluckt.

Hallo,
mit weiteren log Einträgen steht fest, daß der V4L2-Layer beteiligt ist. Vermutlich geht es Richtung Treiber.
Der ioctl braucht sehr lange (4 Sekunden oder mehr).

void cDvbSdFfDevice::GetOsdSize(int &Width, int &Height, double &PixelAspect)
{
  if (fd_video >= 0) {
     video_size_t vs;
     LogTime(2000);
     if (ioctl(fd_video, VIDEO_GET_SIZE, &vs) == 0) { //  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
     LogTime(2010);
........

Ich werde jetzt den Treiber etwas instrumentieren ....

ok, nun habe ich den Code des Treibers für die SDFF-Karte angeschaut. Der ioctl macht nur ein kurzes memcpy (sind nur 3 int) und kehrt zurück.
Da wären schon 100ms langsam. Das V4l2 ioctl-handling kann es eigentlich auch nicht sein, das habe ich schon vor einiger Zeit mal näher angeschaut.
Hat jemand eine Idee wo ich noch schauen könnte?

Hallo Ufo,
das hatte ich auch schon im Versacht.
Dann müsste ja alles ok werden wenn ich die Ausgabe mit SoftHDDevice mache.
Das hatte sich allerdings etwas gesträubt bei meinen letzten Versuchen (konnte nicht mit X verbinden, aber das ist OT).