nOpacity 0.0.3

Torsten73 · 29. November 2012

Was haltet Ihr von dem Vorschlag die Breite von z.B. dem EPG Vorschau F2 konfigurierbar zu machen? Im Moment liegt die bei ca 35% und ich fände es praktischer wenn die breiter wäre.
Dann würde man den EPG Text in der Schriftgröße erhöhen können ohne Inhalt zu verlieren und und es passt besser da hinein.

Außerdem bei 90% 16/9 Sendungen sind die schwarzen Balken Platzverschwendung. Idee dazu wäre,
alternativ mit aktivem Video scaling auf z.b. 50% setzen und unten den überflüssigen Platz für die EPG Info des gewählten Eintrages zu nutzen:

Also:

Code

---------------------------------------------------------------
|                            	                                              |                                     	                                       |
|                            	                                              |                                                                            	|
|      EPG Liste      	|                                         |
|                            	|              TV Bild           	|
|                            	|                                         |
|                            	|                                         |
|------------------------------------------------- ------------|
|                   	EPG Info                                    |
|                                                                      	|
--------------------------------------------------------------

Alles anzeigen

Verständlich? Und noch in der Größe alles einstellbar das ganze ...
Ich werde das dann als Featurewunsch einstellen, wenn die Idee Anklang findet.

Taipan · 29. November 2012

louis · 29. November 2012

torsten: die Breite des schmalen Menüs ist schon konfigurierbar (Unter "VDR Menü" die Option "Breite der schmalen Menüleiste").

Den Rest habe ich nicht so ganz verstanden...nur eine Anmerkung: an dieser Stelle Detailinfos über die Sendungen anzuzeigen ist nicht ganz so einfach, da die Event ID nicht bekannt ist. Der VDR liefert hier einfach einen Text für die Menübuttons. Um die Event ID herauszufinden, damit man die Detailinfos erhalten könnte, müsste man den VDR patchen oder anderweilig fummeln, das wäre aber nicht wirklich zuträglich für die Performance, insb. beim schnellen scrollen durch die Liste.

Ciao Louis

rookie1 · 29. November 2012

Zitat von louis

torsten: die Breite des schmalen Menüs ist schon konfigurierbar (Unter "VDR Menü" die Option "Breite der schmalen Menüleiste").

Aber vielleicht wäre es möglich eine getrennte Einstellung für die Breite bei Main Menu und EPG Liste zu haben. Da die Texte doch schon recht Lang sind.

rookie

Torsten73 · 29. November 2012

Zitat von louis

Um die Event ID herauszufinden, damit man die Detailinfos erhalten könnte, müsste man den VDR patchen oder anderweilig fummeln, das wäre aber nicht wirklich zuträglich für die Performance, insb. beim schnellen scrollen durch die Liste

Performanceprobleme beim srollen könnte man vermeiden, indem man die event ID erst verzögert anzeigt und während der Verzögerungsphase auch keine Abfrage erzeugt. Denn während des Scrollens braucht man das nicht zu aktualisieren, aber sobald man auf einem Eintrag stehen bleibt, z.b. nach 0,5s
bekämst Du die event ID nicht wenn Du eine gleiche Abfrage wie bei der Taste "i" machst? Das funktioniert ja bereits an der Stelle, nur dass halt kein Fenster sich mit den Detailinfos öffnet, sondern dass der Platz unten im Bild genutzt wird.
Wenn dafür wirklich ein Patchen erforderlich wäre, würde dies natürlich wenig sinnvoll sein, Da stimme ich Dir auch zu.

Leider sieht die Strichzeichnung sehr dürftig aus. Sie sollte nur die Einteilung des Bildschirms verdeutlichen.

nvertigo · 29. November 2012

Zitat von rookie1

Aber vielleicht wäre es möglich eine getrennte Einstellung für die Breite bei Main Menu und EPG Liste zu haben. Da die Texte doch schon recht Lang sind.

rookie

Die Idee finde ich sehr gut!

Gruß, Ingo

louis · 29. November 2012

Zitat von rookie1

Aber vielleicht wäre es möglich eine getrennte Einstellung für die Breite bei Main Menu und EPG Liste zu haben. Da die Texte doch schon recht Lang sind.

Jo das habe ich mir auch schon gedacht...das macht wohl sinn. Ich werde das mal einbauen...und das Setup Menü wird immer länger

torsten: deine Idee finde ich prinzipiell gut...leider ist man im Skin schon recht beschränkt, ich würde mir die Skin Schnittstelle insgesamt flexibler wünschen. Klaus hat da auch einige Kommentare im Code, um das flexibler zu gestalten...gerade an dieser Stelle. Aber es steht wohl weiter unten auf seiner todo Liste Ich werde bei Zeit mal schauen, was sich da machen lässt.

Ciao Louis

nvertigo · 29. November 2012

Zitat von louis

Jo das habe ich mir auch schon gedacht...das macht wohl sinn. Ich werde das mal einbauen...und das Setup Menü wird immer länger

Beschwere Dich doch beim Entwickler - ach, ne, der hat's ja von Anfang an so gewollt, geplant und angekündigt:

Code

Description
-----------


"nOpacity" is a highly customizable native true color skin for the Video Disc Recorder.

:lol:

Gruß, Ingo

TomJoad · 30. November 2012

Zitat von louis

Bist du dir da sicher? Was heisst "wesentlich stabiler"? Sorry für die Nachfrage, aber nach meinem Verständnis kann dein Patch nichts mit dem Absturz zu tun haben...

Wesentlich stabiler bezieht sich hauptsächlich auf den Shutdown, der bei mir immer gecrashed hat. Besser wurde es beim Abbrechen des Shutdowns. Aber du hast recht, so funktioniert es noch nicht ganz. Das Problem beim Runterfahren sind die Countdownmeldungen vom vdr. Sobald sie bei "wird in 0:00 Minuten runterfahren" angelangt sind, wird sofort eine NULL-Message hinterhergeschoben, normalerweise kommt so eine NULL-Meldung nur, wenn nach 5 Sekunden oder so die letzte Meldung vom OSD entfernt werden soll. Die NULL-Meldung führt in skins.c zur Zerstörung des Message-Objekts, dann ist aber bei aktivem Fading der Thread noch mit der 0:00-Meldung aktiv. Deshalb hänge ich einen aktualisierten Patch an, wo der Thread vor der Zerstörung der pixmap gecancelt wird.

nvertigo · 30. November 2012

...gepatcht, übersetzt, installiert und fading eingeschaltet. Sieht bisher gut aus - aber das dachte ich schon mal... Deine Erklärung klingt plausibel. Werde beobachten und berichten.

Gruß, Ingo

nvertigo · 30. November 2012

...leider war es das dann nicht:

Code

[Thread debugging using libthread_db enabled]
Core was generated by `/usr/bin/vdr --localedir=/etc/vdr/locale -u root -w 60 --config=/etc/vdr --shut'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000010005 in ?? ()
(gdb) bt
#0  0x0000000000010005 in ?? ()
#1  0x00007fd5332d6007 in cNopacityDisplayChannel::Action (this=0x24b7ae0) at displaychannel.c:501
#2  0x00000000005435ff in cThread::StartThread (Thread=0x24b7af0) at thread.c:262
#3  0x00007fd5391df344 in ?? () from /usr/lib64/libGL.so.1
#4  0x00007fd540670f26 in start_thread () from /lib64/libpthread.so.0
#5  0x00007fd53f2a84ed in clone () from /lib64/libc.so.6

Alles anzeigen

Schade. Zur Situation: habe einfacht 7x schnell die ok-Taste auf der FB gedrückt. Fade-Time war 500 ms. Finde das Fading nämlich sehr schön.

Allzeit bereit zum testen.
Gruß, Ingo

EDIT: Sehe gerade, dass ich das falsche - sprich ungepatchte - Fading getestet habe. Werde den Patch morgen früh mal für alle fünf Fadings anwenden, und berichten - ich finde die Erklärung nämlich immernoch plausibel!

louis · 30. November 2012

Hi,

sowas ähnliches habe ich auch schon in der cSkinnopacityDisplayMenu() (Datei displaymenu.c) eingebaut, weil das dort auch gecrasht hat, wenn man das Menü beendet hat, bevor das Fading beendet ist. Weil dort reativ viele Pixmaps eingeblendet werden, war der Effekt auffälliger.

Wenn ich allerdings sehr schnell mit der Tab Taste das Menü ein- und ausblende, stürzt der VDR trotzdem ganz selten noch ab. Deshalb habe ich das auch noch nicht in die anderen Klassen eingebaut, weil es eben noch keine 100% Lösung ist.

Testen kann man es wohl am besten mit dem Hauptmenü, der Fehler ist analog zu dem in der MessageBox...

Ciao Louis

nvertigo · 1. Dezember 2012

Guten Morgen und einen geheiligten 1. Advent,

ersteinmal vielen Dank an Louis und TomJoad für ihre Versuche mir meine Backtraces zu erklären. Und ich möchte gleich voran schicken, dass meine Versuche hier zu helfen keinesfalls von c++-threadsafe-Programmierungs-Fachwissen getrübt sind. Daher: selbst wenns nicht hilft, hat es für den ein oder anderen zumindest einen gewiseen Unterhaltungswert. Der angehängte Patch ist also nicht für Produktionssysteme, oder ein TV-Wochenende mit dem Schatz geeignet...

So, ich habe mir (mehrfach) gründlich die Erläuterung von TomJoad durchgelesen und mir dann Luois Code angesehen. Was Louis in displaymenu.c macht, ist ja ähnlich, wie das was TomJoad vorschlägt. Ich habe mal versucht das Ganze so paranoid wie möglich auszulegen. Der angehängte Patch bezieht sich ersteinmal auf menu, nachrichten, wiedergabe, und kanalwechsel.

Bisher läuft es damit hier stabil - aber das denke ich ja immer zuerst...

Gruß, Ingo

Siedu · 1. Dezember 2012

Hi Ingo,

[off Topic an]
Ich will ja nicht meckern, aber der 1. Advent ist morgen
[off Topic aus]

Gruß SieDu

3PO · 1. Dezember 2012

Zitat von Siedu

Hi Ingo,

[off Topic an]
Ich will ja nicht meckern, aber der 1. Advent ist morgen
[off Topic aus]

Gruß SieDu

Manche sind halt ihrer Zeit weit voraus.

louis · 1. Dezember 2012

Ingo: der Patch schaut ok aus...Danke.

@all: wer es mal testen will...den VDR z.B. mit gedrückter OK Taste stressen, damit dauern das Kanalwechselmenü ein- und ausgeblendet wird bzw. mit Tab das Menü schnell ein- und wieder ausblenden. Der VDR muss dabei stabil bleiben.

Wenn es erfolgreich getestet ist, würde ich das ins GIT aufnehmen. Ich bin gerade an einer anderen Baustelle (epgsearch Integration neu und ordentlich machen, das ist recht aufwändig) und entwickle am master branch, also kann ich das GIT gerade schlecht aktualisieren

Ciao Louis

Zitat von 3PO

Manche sind halt ihrer Zeit weit voraus.

Ich geh nachher Ostereier kaufen

nvertigo · 1. Dezember 2012

...gestern beim Einkaufen haben mir alle einen schönen ersten Advent gewünscht... Ihr habt natürlich recht...

louis: irgendwas stimmt immer noch nicht. Ich habe die tab-Taste heute morgen mit Zahnstochern blockiert - eben nachgeschaut: nach knapp 2h gabs den typischen segfault. Also mir reicht das fürs erste, bedeutet aber, dass die Baustelle immer noch offen ist. Und noch eine Frage: Cancel() macht alles zu - Cancel(int) nur die ebene int, richtig?

Gruß, Ingo

louis · 1. Dezember 2012

Zitat von nvertigo

louis: irgendwas stimmt immer noch nicht. Ich habe die tab-Taste heute morgen mit Zahnstochern blockiert - eben nachgeschaut: nach knapp 2h gabs den typischen segfault. Also mir reicht das fürs erste, bedeutet aber, dass die Baustelle immer noch offen ist.
Gruß, Ingo

Nach 2 Stunden??? Na das sollte doch ausreichend sein Zumindest kann man damit schonmal arbeiten...der Absturz beim automatischen Shutdown ist aber weg?

Zitat von nvertigo

Und noch eine Frage: Cancel() macht alles zu - Cancel(int) nur die ebene int, richtig?

Nein...read the source luke

Code

void Cancel(int WaitSeconds = 0);
       ///< Cancels the thread by first setting 'running' to false, so that
       ///< the Action() loop can finish in an orderly fashion and then waiting
       ///< up to WaitSeconds seconds for the thread to actually end. If the
       ///< thread doesn't end by itself, it is killed.
       ///< If WaitSeconds is -1, only 'running' is set to false and Cancel()
       ///< returns immediately, without killing the thread.

mini73 · 1. Dezember 2012

Moin!

Ich hab mir die Geschichte mit dem Fade-Thread noch nicht angesehen... Aber warum startet und stoppt ihr den denn, wenn das so Probleme bereitet?
Kann der nicht einfach schlafen, bis der nächste Fade gebraucht wird? Man könnte ihn mit cCondWait etc. entsprechend ausrüsten. Am besten aber mit einem Timeout bzw. beim Beenden des vdr muss der Thread natürlich schon geschlossen werden.

Nur mal so als Denkanstoß, hab leider gerade keine Zeit, das mal selbst zu testen.

Lars.

TomJoad · 1. Dezember 2012

Zur Ergänzung zum Cancel:
Soweit ich den Ablauf in thread.c verstehe, heißt Cancel(-1) running auf falsch zu setzen, was mit Running() abgefragt werden kann im Action-Loop. Weiter wird mit dem Thread nichts gemacht, der muss sich schon selber beenden. Bei Cancel() = Cancel(0) wird zusätzlich ein pthread_cancel auf den Thread abgesetzt. Deshalb habe ich Cancel(2) verwendet, da wird nach dem Setzen des running-Flags maximal 2 Sekunden gewartet, ob der thread sich beendet hat und alle 10 ms der Status überprüft, bevor der Thread abgeschossen wird. Einen eigenen Loop um den Cancel zu bauen, ist m.E. nicht sinnvoll, weil immer nach dem 1. Durchlauf Running() falsch ist.

nOpacity 0.0.3

Jetzt mitmachen!

Teilen