Hallo mattbug64 ,
ich habe das gerade nochmal getestet und konnte keine Probleme beim Kanalwechsel in Verbindung mit tvguide feststellen.
Ich nutze hier tvguide-1.3.5 zusammen mit vdr-2.5.6. VDR-2.5.6 spezifische Änderungen in tvguide sind auch nicht nötig.
Wie genau machst Du den Kanalwechsel, da gibt es ja verschiedene Möglichkeiten.
Zum Eingrenzen solcher Fehler wäre auch ein aussagekräftiger Backtrace hilfreich.
Grüße
kamel5
Das loggen dieser Ladeversuche kannst Du im Setup vom Plugin abstellen: "Log Nachrichten beim Bilder laden erzeugen" auf "Nein".
Das es so viele Nachrichten sind, liegt daran, das erst versucht wird, ein Theme-spezifisches Icon zu finden und wenn das nicht klappt wird ein allgemeines Icon verwendet.
Das ist damals so implementiert worden.
Wo genau was geloggt wird müsste man sich im Code anschauen. Wahrscheinlich gibt es da an manchen Stellen Log-Meldungen und an anderen nicht.
Grüße
kamel5
Ich weiß zwar nicht, warum das mein Compiler, gcc-11.2.1, nicht anmeckert. Deiner hat aber recht.
Commit dazu ist jetzt im git.
Grüße
kamel5
Wenn ich den mit dem aktuellen nopacity-skin (devel) aufrufe, legt vdr einen Neustart hin.
ich habe einen Fix dazu commited, das sollte jetzt funktionieren. Bitte nochmal testen.
Grüße
kamel5
Wenn ich den mit dem aktuellen nopacity-skin (devel) aufrufe, legt vdr einen Neustart hin.
Kann ich hier nachvollziehen, schaue ich mir an.
zu dem "1 s beim ersten OSD Aufruf" Problem: ich erinnere mich dunkel, dass einige DVB Karten bzw. die Treiber sehr lange benötigen, bis die Signalinformationen der DVB Adapter gelesen sind. Deshalb tritt dieser Effekt bei manchen auf, bei manchen nicht...
Das ist mir auch schon aufgefallen.
Das koennte erklaeren, warum ich bei OSD Größe 1280x720 im dvbhddevice-Plugin so einen Effekt nicht sehe. Bei fester OSD-Aufloesung muss nicht auf ein Signal gewartet werden.
Das Problem ist hier allerdings, das dieser Effekt bei mir nur in Verbindung mit der TT6400 auftritt. Wenn ich z.B. Softhddevice als Ausgabeplugin benutze, tritt dieser Effekt nicht auf. Und dieser Effekt tritt z.B. auch bei OSD's auf, die keine Signalabfrage durchführen.
Ich muss bei Gelegenheit mal schauen, ob ich das noch eingrenzen kann.
Grüße
kamel5
Hallo Uwe ,
Nachdem ich nun einige Plugins deaktiviert hatte, konnte ich das Plugin epgsearch als Übeltäter ausmachen.
Das ist ja wirklich seltsam. Ich nutze das Plugin auch, aus der gleichen Quelle.. Bei mir tritt so ein Effekt nicht auf. Mhhh.
Sorry, dass ich erst skinnopacity im Verdacht hatte… 😉
Kein Problem. Es hätte ja sein können.
Grüße
kamel5
Ich habe im dvbhddevice-Plugin OSD Größe 1280x720 und TrueColorFormat ARGB8888 eingestellt, das hat vermutlich Einfluss...
Das könnte tatsächlich eine Ursache sein. Ich habe zwar auch ARGB8888, aber OSD-Größe auf "folge Auflösung" stehen und Auflösung auf fest 1080i.
Ich werde mal testen, ob sich da Unterschiede ergeben.
Eine Sekunde vergeht bei mir nicht, das wuerde mich wahnsinnig machen.
Man gewöhnt sich an alles
Und die nachfolgende Bedienung im Menü ist ja schneller...
Grüße
kamel5
Hallo S:oren ,
Da muss ich nicht im Sekundenbereich warten (auf der S2-6400).
das ist ja das Seltsame. Wahrscheinlich ist das auch noch stark von der restlichen Harware abhängig.
Ich habe es gerade bei mir nochmal verglichen, Bei mir vergeht bis zum erscheinen des Menüs und dazu gehört auch die EPG-Info/Aufnahme-Info (hier ist nicht die Kanal-Info beim Umschalten eines Senders gemeint), so knapp eine Sec. Und das sowohl bei der aktuellen devel, als auch der light_version. Da unterscheiden sich die Beiden nicht. Anders sollte es auch nicht sein, den ich habe den betreffenden Code quasi 1:1 übernommen.
Wenn man also in der devel-Version "Scraper...", Animationen..." und "Reiter..." auf "Nein" stellt, sollte es sich genau so wie die light_version verhalten. Zumindest bei mir ist das so.
(und werde leider auch sobald keine Zeit haben).
Das ist kein Problem, ich habe im Moment auch nicht so viel Zeit.
Im Endeffekt lässt sich aber wohl nur auf der gleichen Hardware feststellen, ob sich da ein zeitlicher Unterschied zeigt.
Ich werde als Nächtes mal ein paar Zeitmessungen in die light_version und die devel Version einbauen und schauen ob sich da ein signifikanter Unterschied ergibt.
Nachtrag:
1 Sec vergeht bei mir übrigens auch beim Skin LCARS, wenn ich das Menü aufrufe.
Grüße
kamel5
Uwe ,
Allerdings dauert der Aufruf der EPG-Details-Info aus den Aufnahmen nicht so lange, da wird sofort die Info angezeigt…
Das wundert mich ein wenig, da für Beide im Prinzip der selbe Code verwendet wird.
Auf beiden Systemen dauert der Aufruf der EPG-Detail-Info sehr lange. Mit der FFHD6400 dauert es grob 2 Sekunden und auf dem rpi3b+ ein bisschen weniger…
2 Sekunden ist doch sehr lang. Ich nutze hier auch die TT6400 und bei mir unterscheiden sich die Zeiten zwischen EPG-Info und Aufnahmen-Info unerheblich und liegen unter 1 Sekunde.
Großen Einfluss auf die Zeiten, vor allem beim Menü (dazu gehört auch die Info-Seite), bei der TT6400 hat ein aktives fade-in.
Du kannst im Setup des Plugins "Animation benutzen" auf "Nein" stellen, dann treten keine diesbezüglichen Effekte auf.
Wenn Deine Signatur stimmt, nutzt Du auch keine Scraper-Infos. Davon kann es dann auch nicht kommen.
Was kannst Du noch tun:
- Probiere mal ein anderes Theme, vielleicht verhält sich das anders.
- Im Plugin-Setup "Reiter in der Detail Ansicht benutzen" auf "Nein" stellen, dann wird im Moment anderer Code benutzt.
Wenn das alles nichts bringt, poste bitte mal Deine Plugin-Einstellungen, dann kann ich es hier mal damit testen.
Zum rpi kann ich im Moment auch nur empfehlen mit den oben genannten Einstellungen zu experimentieren.
Ich habe hier mittlerweile auch einen rpi3b+ und einen rpi4 und wollte sie mit einem VDR bestücken, das habe ich aus Zeitgründen bisher aber noch nicht geschafft. Ich werde versuchen, das mal in nächster Zeit umzusetzen, möglicherweise ergibt das dann neue Erkenntnisse.
Grundsätzliches zu den Änderungen im Branch devel bzgl. Info-Ansicht:
Die einzig wichtige Änderung ist das Deaktivieren der Threads. Das führt gefühlt zu einem etwas langsameren Aufbau der Info-Ansicht. Allerdings werden dadurch alle OSD-Elemente gleichzeitig angezeigt. Das halte ich persönlich für die bessere Lösung (auch bei der TT6400), ist aber grundsätzlich auch Geschmackssache und kann bei langsamer Hardware durchaus etwas länger dauern.
Grüße
kamel5
Danke fürs Finden.
Das sollte schon noch abwärts kompatibel sein. Ich hatte da eine API-Abfrage vergessen.
Ist im Branch devel jetzt korrigiert. Also bitte noch mal testen.
Grüße
kamel5
Leider bin ich noch nicht dazu gekommen, das auszuprobieren. Kann auch leider noch laenger dauern. Klingt aber alles schon mal gut.
Kein Problem, hat bei mir ja auch etwas länger gedauert.
Wenn die Threads so weit wie moeglich eliminiert sind, welche gibt es noch?
Im Moment gibt es noch 3 Threads:
1. fade-in und fade-out
2. Scrolling der Menüeinträge
3. Scrolling des Info-Fensters bei schmalem Menü und Video skaliert
Der erste ist soweit unabhängig, kann in allen OSD's auftreten und ist nur im kurzen Moment des fade-in bzw. fade-out aktiv.
Den zweiten und dritten gibt es nur im Hauptmenü bei Listen, wie Aufnahmen, Timern usw. Sie können einzeln und auch zusammen auftreten. Hier ist mir noch keine gute Lösung zum Synchronisieren eingefallen.
Diese 3 Threads sind für den Skin optional und können im Setup mit "Use animation" abgeschaltet werden.
Wird da auch mit mehreren Threads drauf zugegriffen? Oder passiert bei dem ersten Aufruf irgendeine Initialisierung, die vielleicht auch Hardware-Parameter abfragt?
Diese cPixmap::Lock() sind zwar in Threads, aber unabhängig davon tritt dieser Effekt auf. Wenn man z.B. in cNopacityDisplayChannel::Flush so ein cPixmap::Lock() einbaut, entsteht der gleiche Effekt. Und wenn man das cPixmap::Lock() weg läßt, dauert das erste osd->Flush() länger.
Da das bei z.B. softhddevice nicht auftritt, muss es wohl an der Kette dvbhddevice -> TT6400 liegen. Ob da eventuell schon Hardwareparameter abgefragt werden, kann ich nicht sagen, das dvbhddevice Plugin übersteigt im Moment meine Möglichkeiten.
Da sich dieser Effekt nur beim ersten Lock/Flush bemerkbar macht, ist das jetzt nicht ganz so schlimm, obwohl das OSD gefühlt durchaus etwas schneller angezeigt werden könnte.
Grüße
kamel5
Es gibt einen aktualisierten Branch devel.
Zusätzlich zu internen Anpassungen sind folgende Änderungen gegenüber der Version 1.1.8 erwähnenswert:
- Überarbeitung von fade-in in allen OSD's
-- Es werden jetzt alle OSD-Elemente berücksichtigt
-- Insgesamt etwas smoother
- Fade-out hinzugefügt
- Recording errors in detail view hinzugefügt
- skinnopacity Setup kann nur noch aufgerufen werden, wenn der Skin aktiv ist.
- Neue Setup-Optionen "Use scraper infos and pictures" und "Use animation" hinzugefügt (ist dadurch zentral abschaltbar)
- Icon für UHD hinzugefügt
- Light Version integriert (im Setup über die Option "Use tabs in detail view" konfigurierbar)
Die Integration der Light Version ist noch nicht optimiert. Das werde ich später noch machen.
Zum Setup:
Da bei diesem Skin die Parameter Theme-spezifisch abgespeichert werden, das benutze Theme aber nur bekannt ist, wenn der Skin aktiv ist, lassen sich auch nur dann Parameter fehlerfrei in die setup.conf abspeichern.
Das führte in der Vergangenheit dazu, das z.T. unsinnige Dinge in die setup.conf gespeichert wurden, wenn bei nicht aktiven Skin Änderungen im Skin-Setup gemacht wurden.
Ich habe deshalb, wenn der Skin nicht aktiv ist, jetzt das Setup-Menü vom Skin deaktiviert.
S:oren ,
beim Übernehmen von commits in die "light_version" hat sich gezeigt, das nur noch wenige Unterschiede zur "normalen" Version bestehen.
Ich habe deshalb die verbliebenen Sachen:
- weniger Threads (sind jetzt so weit wie möglich eliminiert)
- lineare Detailansicht
in die "normale" Version übernommen.
Wenn Du die 3 Optionen "Use tabs in detail view" , "Use scraper infos and pictures" und "Use animation" auf Nein stellst, sollte sich kein Unterschied zur "light_version" ergeben.
Es wäre schön, wenn Du den Branch devel mal testen könntest.
Noch was TT6400 spezifisches bzgl. Animation:
Das erste cPixmap::Lock() dauert gegenüber anderen Ausgabewegen unverhältnismäßig lange. Das erschließt sich mir nicht ganz, da an dieser Stelle die Hardware der TT6400 ja noch nicht beteiligt sein sollte. Alle nachfolgenden cPixmap::Lock() sind dann unauffällig. Möglicherweise liegt das am dvbhddevice Plugin.
Bei mir treten da Verzögerungszeiten von z.T. über einer 1/2 sec auf. Debug-Ausgabe bei Kanalanzeige:
[270948] skinnopacity: First Lock(): 565ms
Das Ganze ist abhängig von der OSD Größe und der Anzahl der OSD Elemente.
Grüße
kamel5
Hallo,
eine neue Version 0.3.6 ist im git:
- Small optical changes
- VDR-2.5.6 adjustments
- Optional display of errors in info added if "error == 0"
Grüße
kamel5
kls ,
diese Änderung scheint es zu lösen.
Bei einer Probeaufnahme wurden die errors zeitnah in der Info angezeigt.
Ich werde es mal noch ein paar Tage beobachten.
Grüße
kamel5
kls ,
ich muss das mit den errors noch mal aufwärmen.
Ich sehe hier bei meinen Aufnahmen öfters mal errors. Ich habe auch einen Skin, mit dem ich diese anzeigen kann. Dabei ist mir aufgefallen, das die errors einer laufenden oder fertigen Aufnahme erst nach einem Neustart des VDR entsprechend angezeigt werden. Vorher wird immer 0 angezeigt.
Im Log werden die errors korrekt angezeigt.
Sollte es nicht so sein, das die errors direkt nach Auftreten oder spätestens nach Beenden der Aufnahme, auch angezeigt werden können.
Grüße
kamel5
MegaV0lt
, Thank you for the compliment, I do my best. I didn't want to check every pixmap to see if it existed.
I also think that this problem should be fixed in the output device so that not every skin has to implement a workaround.
Nevertheless, I made Part 2 of the fix to make it even easier to map it in all skin functions.
See the last commit in git branch Devel.
Grüße
kamel5
Ich habe mal aus gegebenem Anlass, [ansible] vdr 2.4.7 Segmentation Fault beim Start mit softhddevice und aktivem skinnopacity oder skinflat, ein paar neue commits im Brach Devel für die "normale" Version angelegt.
Im Moment bin ich noch an der Überarbeitung des Flush() im Menü.
Wenn das fertig ist, werde ich das, soweit möglich und sinnvoll, auch in die light_version übernehmen.
Grüße
kamel5
I have added a commit (with a few others) in the skinnopacity Devel Branch.
This should fix the segfault when using the softhd* detached mode.
Grüße
kamel5
Hallo,
eine neue Version 0.3.5 ist im git:
- Add TS errors to recording info
- Add timeshift buffer to display channel
Grüße
kamel5
