1.0.2 - estuary4vdr flexible

Moin,

die Frage, die sich mir generell stellt: tritt dieses Verhalten generell mit SHD auf oder nur mit dem OpenGL OSD Fork? Da andere, die das "normale" SHD verwenden, auch von diesen Problemen berichten, gehe ich davon aus, dass es am SHD selbst liegt. Ich hätte auch keine Idee, was die OpenGL OSD Erweiterung direkt damit zu tun haben sollte. Was ich mir jedoch vorstellen könnte, dass die Ressourcen der GraKa mit dem OpenGL OSD mehr ausgenutzt werden und ggf. deshalb das Problem forciert wird.

Wie helau schon angedeutet hat, könnte man die Stelle, an der das "alsa-close-open-delay" zieht, etwas "intelligenter" implementieren. Aktuell schaut das so aus (audio.c ab Zeile 1223)

if (AudioAlsaCloseOpenDelay) {
	    usleep(50 * 1000);		// 50ms delay for alsa recovery
	}
	// FIXME: can use multiple retries
	if (!(handle = AlsaOpenPCM(passthrough))) {
	    return -1;
	}

Das könnte man relativ einfach so umbauen, dass so lange erneut versucht wird, bis es denn klappt. Oder zumindest mehrmals, nicht nur einmal. Vielleicht genügen die 50ms beim OpenGL OSD aus irgendwelchen Gründen nicht, da die GPU mit was anderem beschäftigt ist.

iNOB: siehts du dich in der Lage, das selbst mal so anzupassen (z.B. ne while Schleife aussenrum mit nem Counter), dass mehrere retry Versuche unternommen werden? Ansonsten könnte ich auch nen Patch zur Verfügung stellen...

Ciao Louis

PS: eine Alternative wäre natürlich auch, die 50ms mal z.B. auf 100ms zu ändern...das sollte man auch ohne C Kenntnisse hinbekommen Ob das irgendwelche Seiteneffekte hat, kann ich nicht sagen, dazu kenne ich den Code hier zu wenig

Ciao Louis

Zitat von iNOB

Nein. Bin kein Programmierer. Kann aber vorgepinselte Änderungen einbauen, compilieren und testen

Na dann...probier mal das (mal so hingepinselt, komplett ungetestet):

-       if (AudioAlsaCloseOpenDelay) {
-	    usleep(50 * 1000);		// 50ms delay for alsa recovery
-	}
-	// FIXME: can use multiple retries
-	if (!(handle = AlsaOpenPCM(passthrough))) {
-	    return -1;
-	}


+       int numRetries = 0;
+       while (!(handle = AlsaOpenPCM(passthrough)) && numRetries++ < 5) {
+           usleep(30 * 1000);
+       }
+       if (!handle)
+           return -1;

So sollte jetzt 5 * probiert (wobei das erste mal direkt ohne sleep probiert wird) werden und im Fehlerfall jeweils 30ms gewartet werden...also insgesamt maximal 150ms. Wie gesagt komplett ungetestet.

Ciao Louis

iNOB: prima, wobei du das ja schonmal gesagt hattest Ich habe mir die Patches von jrie nicht im Detail angesehen und kann deshalb nicht beurteilen, inwieweit die mit in die Audioausgabe reinspielen. Wenn es aber so sein sollte, dass es mit diesen Patches noch besser läuft, kann man ja mal einen "Gesamtpatch" erstellen, der alle wichtigen Sachen beinhaltet. Wegen mir kann ich den dann auch in meinen Fork aufnehmen, falls Johns sich ziert

PS: hier der Patch von oben mal mit Debugausgaben, dann siehst du im Log auch, beim wievielten Versuch pro Zappen es geklappt hat:

int numRetries = 0;
        while (!(handle = AlsaOpenPCM(passthrough)) && numRetries++ < 5) {
            usleep(30 * 1000);
        }
        Debug(3, "audio/alsa: needed %d attempts to init alsa\n", numRetries);
        if (!handle) {
            Error("audio/alsa: alsa init not successfull, aborting\n");
            return -1;
        }

iNOB: hast du jetzt mal getestet? Passt das jetzt mit dem Patch?

Ciao Louis

Zitat von Taipan

louis
echt toll geworden mit den Anpassungsfähigkeiten in Sachen Schrift! Wäre noch ein Wermutstropfen für mich... Kann man die Menü Icons optional machen?

Ihr macht mich fertig Was hast du denn gegen die Icons?

Ciao Louis

Hi,

Zitat von iNOB

1. Wieso werden beim Wechsel des Kanals oder der Kanalgruppe immer sämtliche Timer neu geladen? Im Hauptmenü, wo die Timer angezeigt werden, sehe ich das ja ein. Aber wieso auch bei Kanal und Kanalgruppe? Ich frag deshalb, da bei einem "lahmen" Datenlieferanten, der Umschaltvorgang so zusätzlich und unnötig verzögert wird. Mir kommt es vor, als ob die vom epgd Server geladen werden!?

Ja, die werden per Serviceinterface von epg2vdr abgeholt, der widerum holt sie aus der DB. Ich brauche die Timer, um das "Rec" Symbol bzw. die aufnahmekennzeichnung des aktuellen und nächsten Events darstellen zu können. Dabei werden sowohl die lokalen als auch die remote Timer von allen anderen VDRs im epgd Verbund berücksichtigt. Aus meiner Sicht sollte das pro VDR konfigurierbar sein, ob nur die lokalen oder auch die remote Timer angezeigt bzw. benutzt werden sollen (im Hauptmenü oder beim Umschalten). Wir sind uns nur noch nicht so ganz einig geworden, ob diese Config Option in das epg2vdr Plugin oder den Skindesigner soll.

Zitat von iNOB

2. Bei Anzeige des Hauptmenüs bekomme ich immer folgende Meldung:

Quellcode
1
May 15 08:31:34 xvdr1 vdr: [1255] [poller.c,82]: epoll_wait() failed: Unterbrechung während des Betriebssystemaufrufs

Ist das normal?

Alles anzeigen

Hm, vielleicht hat das was mit deinem 3. Problem zu tun?

Zitat von iNOB

3. Die angezeigten Werte im Hauptmenü für CPU Temp stimmen nicht mit denen überein, die vdrstats ermittelt? Ist da was im Code vom skindesigner vertauscht oder wird das mittlerweile anders ermittelt?

vdrstats ermittelt die CPU und MEM usage vom VDR. Die Temperaturen werden vom temperatures Script gelesen. Da sollte sich eigntlich nichts geändert haben?!

Ciao Louis

Zitat von utiltiy

Kann man diesen irgendwie "übernehmen" falls andere ebenfalls die Änderung als erfolgreich erachten?

Tja...die Frage ist wo. Johns scheint aktuell nicht so wirklich motiviert zu sein...

Die Patches von jrie gibt es ja auch noch...und das OpenGL OSD.

Ciao Louis