Beiträge von Ramirez

Ich hatte fast den kompletten Sonntag das Timer Menü geöffnet, dann das Timer Edit Menü und einen Timer gelöscht. Mit nOpacity komme ich auf eine Absturzquote von 99%. Daher hatte ich es ursprünglich louis als Bug gemeldet.

Ich konnte den Absturz allerdings auch mit LCARS erzeugen. Habe einfach mal 4-5 Timer angelegt und diese in schneller Weise auch so gelöscht.

Das Problem ist eben, dass der VDR auf das osBack hin zum aufrufenden Menü zurück springt. Das geht eben überall gut, außer im Timer Menü. Das Löschen passiert, wie louis geschrieben hat, nicht synchron. Diese kleine Verzögerung sorgt eben manchmal dafür, dass der Skin einen Menüpunkt zeichnen will, der einem Timer zugeordnet ist, der inzwischen gelöscht ist. Daher hatte ich den Gedanken, dass man dem VDR doch einfach nur sagen müsste, dass er das Timer Menü neu aufbauen soll.

Meine Lösung war, wie in dem Bugreport geschrieben, aber etwas kurz gedacht. Als ich dann den VDR wieder produktiv genutzt habe, habe ich mal einen Timer aus dem Programm Menü gelöscht. Dann springt er natürlich auch beim osBack ins Timer Menü, was dann natürlich nicht gewollt ist.

Was ich eigentlich als Patch dann erstellen wollte, war den Konstruktor von cMenuMyEditTimer um einen Parameter bool isCalledFromTimerMenu zu erweitern, um dann an dieser Stelle eben selektiv osBack bzw. osTimers zurückgeben zu können. Aber wie man dann diesen Parameter füllen kann, da bin ich nun ein wenig überfordert. So tief bin ich leider weder im VDR Code noch im epgsearch Code.

Mit Grundsystem meint er, glaube ich, den Hypervisor selber. Da man den ESXi ja jederzeit neu installieren kann, sollte das mit dem Stick kein Problem sein. Die wichtigen Daten sind ja woanders. Ich finde das sogar ganz geschickt, wenn eben auf den Platten nichts liegt.
Auf meinem Server liegt die ESXi Installation auf einer SDCard.

Seit 5.1 U1 ist das it dem Durchreichen der Karten eigentlich kein Problem. Aber ich kann natürlich nicht für alle Systeme sprechen.

Erst dachte ich, dass es ein Bug ist und die neuen Farben für die Nachrichten nicht genommen werden. Aber eigentlich ist das Problem, dass ich den "Bug" beim Aufruf aus dem Menü warnahm.

D.h. die neuen Farben clrMessageFontStatus & Co werden nur für nicht menübasierte Nachrichten verwendet.

Der Code sollte hier am besten gleich gezogen werden. Außerdem wird ja dann wieder eine Theme Farbe frei

Habe mal den aktuellen Stand zum Testen und Anpassen meines Themes auf meinen Test VDR gezogen.

Was mir dabei aufgefallen ist:

Kanalanzeige (nicht schlagen):

Du recycelst mal wieder einen Farbwert. Und zwar gibt es clrRecNowFont, clrRecNext und clrRecNextFont. Leider aber keine clrRecNow. Hier nimmst Du einfach die bereits vorhandene Farbe clrChannelRecActive.
Eigentlich wollte ich überall für den Button Rot und Aufnahmen auch ein und dasselbe Rot nehmen. Aber da bei mir channelsymbols.png rot ist, sah rot auf rot einfach schlecht aus. Daher habe ich clrChannelRecActive auf grün gesetzt. In dieser anderen Ansicht hätte ich es aber gerne rot.
Schlimm, ich weiß

Timer im Hauptmenü:

Hier stimmt wohl noch einiges beim Zeichnen nicht. Die Texte werden irgendwie ausgefranzt dargestellt. Außerdem hatte ich clrTimersBack eine Transparenz mitgegeben, die wohl ignoriert wird. Fehler oder geht es technisch nicht anders?
Für den gerade aktiven Timer werden leider auch wieder einige Farben zusammengemischt. Eigentlich wolllte ich die Texte weiß auf dem aktiven Timer haben und schwarz auf den inaktiven. Da entweder das eine oder das andere nicht so gut lesbar ist.

Ansonsten:
Großartige Arbeit. Der VDR ist wieder einen Tick schicker geworden. Danke

Wenn man das epgsearch eigene TimerEdit Menü verwendet und dort einen Timer löscht, dann crasht der VDR bei mir (verwende nOpacity als Skin).

Ich habe mir mal die Funktion cMenuMyEditTimer::DeleteTimer in menu_myedittimer.c angeschaut.

Diese liefert, falls man den Timer löscht, osBack als Rückgabewert. Daraufhin versucht nOpacity das Timer Menü neu zu zeichnen. Weil ein Menüpunkt nun zu einem gelöschten Timer gehört, geht´s schief.

Ich habe den Rückgabewert an dieser Stelle nun in osTimers geändert und alles geht gut.

Spricht etwas dagegen, dies im Plugin so zu übernehmen?

Zitat von gda

Nicht das man da jetzt Karies bekommt von den Bonbon-Farben ;).

Gerald

Eigentlich war eine der Motivationen für mich dieses Theme zu machen, dass mir bei den anderen Themes zu viele Farben verwendet wurden. Wenn man die Buttons und Messages abzieht sind es genau 5 Farben, die ich verwende: Schwarz, Weiß, ein Grau, ein Rot und (das sicherlich nicht jedermanns Geschmack) rosé als Hintergrund.

Was für meinen Geschmack manchmal nicht 100% passt ist die Tatsache, dass einige Icons blau verwenden, was sich für mich mit rot beißt. Die Motivation neue Icons zu suchen oder die vorhandenen mit meinen schlechten Graphikskills neu einzufärben war allerdings dann doch zu niedrig

Zitat von louis

cNopacityDisplayMenuView::SetMessage() ist für die Ausgabe von Messages verantwortlich, wenn das VDR Menü offen ist. cNopacityDisplayMessage::SetMessage() wird aufgerufen, wenn kein OSD offen ist. Das erklärt auch die verschiedenen Theme Farben...die Benennung ist vielleicht ein bisschen "inkontinent"

Ciao Louis

Das habe ich ja verstanden. Es war ja nur als Vereinfachungsvorschlag gedacht, um eine Farbe wegfallen zu lassen. Weil wohl jedes Theme diese beiden Einträgen den gleichen Wert zuordnet.

Da hier so viel über Farben diskutiert wird, mal eine Frage warum es zwei getrennte Arten gibt die Meldungen zu zeichen?

Sowohl in cNopacityDisplayMenuView::DrawMessage als auch in cNopacityDisplayMessage::SetMessage werden die Hintergrundfarben clrMessageStatus, clrMessageInfo, clrMessageWarning und clrMessageError genommen.

Aber der Text darauf wird einmal mit clrMenuFontMessages und einmal mit clrMessageFont.

Und hier noch die passenden Dateien für tvguide.

Nachdem ich nun nOpacity auch auf meinem Produktiv-VDR nutzen kann habe ich mir auch mal ein Theme gebastelt.

Zum einen sind die mitgelieferten bis auf IceBlue mir zu dunkel und zum anderen war ich lange Jahre das WhineRed Theme des enigmang Skins gewohnt. Also habe ich auf Basis dieser Theme Farben mein Theme gebaut.

Mein Dank geht dabei natürlich an louis für seinen schönen Skin und BooStar für das Bereitstellen der Icons an denen ich mich reichlich bedient habe.

Gerade die Transparenzeffekte finde ich persönlich ganz schön, daher habe ich meine Icons gerne ohne Rahmen.

Anmerkungen:
1. Auf den Screenshots sieht man, dass die Icons im Menü weiter rechts gezeichnet werden und man generell links neben dem Datum die Disk-Informationen sieht. Das gefällt mir einfach besser. Bei Interesse kann ich einen Patch anhängen
2. Der icons/whinered Ordner hat nun gepackt etwa 2MB. Das darf ich hier nicht anhängen. Größtenteils sind es ja die von BooStar. Wo könnte man das ablegen?

und

3. alles ist passend zur Version 0.1.4, ich werde aber ein neues passendes Theme File kurz nach dem nächsten Release bereitstellen

Zitat von Programie

Aber um Gottes willen, ich will Dich hier nicht zum virtualiserien bekehren. Du wolltest ja nur wissen, ob das, was Du vorhast, prinzipiell geht.
Ich will einfach das, was fuer mein Vorhaben am Besten geeignet ist. Vielleicht hast du mich sogar schon von den VMs ueberzeugt.

Was verwendest du als Hypervisor?

Ich verwende VMWare ESXi

Die aktuellen DVB Karten kann man auch um 2 oder sogar 4 Tuner erweitern. Vor- und Nachteile dürften klar sein: Die Teile belegen dann nur einen Slot, aber wenn die Karte nicht geht, dann geht halt gar nichts mehr.

Mein Server hat 7 PCI-e Slots (von denen ich sowieso nur einen für den SAS Controller brauche), daher habe ich lieber zwei getrennte Karten. Ich kann dann auch eine Karte mal von den einen VM abziehen und diese der Test VM zuordnen.

Aktuelle Hypervisor bringen kaum noch Performance Overhead mit. Das macht also fast keine Unterschied. Einzig der RAM Verbrauch steigt. Ist aber heutzutage ja fast kein Kostenpunkt mehr.

Aber um Gottes willen, ich will Dich hier nicht zum virtualiserien bekehren. Du wolltest ja nur wissen, ob das, was Du vorhast, prinzipiell geht.

Also so generell wird das funktionieren.

Nicht in den Details, aber im Prinzip habe ich das hier so teilweise laufen. Würde meinen Server nicht als NAS bezeichnen, und da ich großer Fan von Virtualisierung bin habe ich auch gerne dedizierte Maschinen für einzelne Aufgaben.

Im Server habe ich zwei L4M Twin Karten verbaut. Damit hättest Du mal 4 Tuner.

Die VM mit dem VDR läuft als headless yaVDR Installation, aber sicherlich kannst Du Dir auch alles selber bauen.

Einzig zum Abschalten der Karten bezüglich Stromsparen kann ich Dir nichts sagen. Da kenn ich mich leider nicht aus.

Also so richtig glücklich bin ich mit diesem über as Icon gepinselte x1 bis x3 auch nicht. Wollte gerade einen Feature Request aufmachen, aber da es hier ja schon was zu dem Thema gibt.

Warum nicht einfach 3 Icons draus machen? Also fwd1.png, fwd2.png, fwd3.png und fwdInactive.png (analog für rew). Dann kann jedes Theme entscheiden, wie es auszusehen hat.

Wer es wie früher mag, kann ja einfach die x1 bis x3 über seine bisherigen Icons pinseln

louis:
So alles eingestellt. Vielen Dank für die unermüdliche Arbeit

Zu den Icons, gerade für Play, Pause, etc. fällt mir da noch ein, warum das nicht evtl. wie bei den Kanalsymbolen laufen könnte. Also die 4 Icons sind transparent und man legt im Theme die aktiv/inaktiv farben fest. Nur so ein Gedanke, denn bei genauer Überlegung ist es das, was ich machen will.

Nachdem mit dem großen yaVDR stable Update nun auch mein Produktiv VDR auf 2.0.2 und ich damit dort auch nOpacity verwenden kann, habe ich mir jetzt auch mal ein Theme gemacht. Mir sind die vorhandenen (mit Ausnahme von IceBlue) irgenwie alle zu dunkel. Vielleicht habe ich auch einfach zu viele Jahre enigma mit whinered auf meinem alten SD VDR verwendet

Zunächst mal vielen Dank für die bereitgestellten Icons, ich habe die extraIcons, menuIcons und pluginIcons mit Begeisterung eingebunden. Thx

Ich bin leider in keinster Weise ein Graphiker. In der Dropbox gibt es ja ein Skript, um diese Icons mit einem Rahmen zu versehen. Die meisten Icons aus skinIcons (play, rew, ...) bestehen ja aus drei Farben (also mit leichten Verläufen):
schwarzer Hintergrund, grau für inaktiv und eine der Themefarben für aktiv

Ich würde gern für meinen Skin das Ganze so aufteilen:
Themefarbe als Hintergrund, grau für inaktiv und weiß für aktiv

Sprich könnte man ein Skript erstellen, dass aus einem Ausgangsbild und drei Farbangaben diese Symbole erstellt oder falls das nicht geht, kann mir jemand einen Tipp geben, wie man das (als Graphikerlaie) umfärbt?

Ich weiß nicht, ob das angebracht ist, daber da es hier um nOpacity Themes geht und louis mitliest, schreibe ich mal eine kleine Liste dessen, was ich nicht machen konnte:

- In allen mitgelieferten Themes fand ich diese Rahmen (hier im Packet IconBorders genannt) nicht meinem Geschmack entsprechend und habe daher einfach die src Bilder mit ihrer Transparenz genommen. Das klappt und sieht fast so aus, wie ich will. Fürs Auge ein wenig zu weit links. Der Abstand links zum Rahmen ist zu klein, der Abstand zum Text ist mir zu groß. Da as Problem links könnt ich lösen, in dem ich einfach einen transparenten Rahmen außenrum mache. Damit würde aber der Abstand zum Text noch größer werden

- Für die Buttons und die Statusmeldungen kann man leider nur den Hintergrund festlegen. Die Vordergrundfarbe ist für alle gleich. Schwarz lässt sich gut auf gelb und grün während weiß sich wiederum gut auf rot und blau lesen lässt. Eine seperate Fontangabe a la clrMenuButtonFontRed usw. währe schön

- Ein wenig verwirrt hat mich die Themefarbe clrMenuItem, da ich hier die gleiche Farbe wie clrMenuBack haben wollte. Gibt man im Theme die gleiche Farbe an, so wird diese drübergezeichnet und gibt (je nach Transparenzwert) eine völlig neue (andere) Farbe. Nach Grübeln kam ich drauf, dass der passende Wert wohl "00000000" ist. Ist das so gewollt?

- Schade ist auch, dass die Timericons im Hauptmenü wohl auch keine eigene Kombination haben und wohl clrMenuItemHigh mit clrMenuFontItemHigh übernehmen. Da diese über dem verkleinerten Bild gezeichnet werden, wollte ich sie eigentlich genau so aussehen lassen, wie ich sie in der Kanalanzeige habe (hab hier die Option, dass der Hintergrund bis zum Icon geht)

Alles Kleinigkeiten, aber es geht halt um Optik

Jepp, hoffentlich bleibt es trocken. So wie letztes Jahr muss es nun wirklich nicht sein.

Also wir reisen nun definitiv Mittwoch an, d.h. ich schau da mal am Donnerstag auf. Obwohl ich eigentlich Wacken immer zur computerlosen Zeit erklärt habe

Klingt eigentlich nach ner netten Aktion. Ich hoffe ihr habt auch noch Platz für einen Spontanentschiedenen.

TheChief
Das mit der Fernbedienung geht auf OrigenAE zurück. Ich war so mit dem Gehäuse für meinen Produktiv VDR so zufrieden, dass ich mir als Ersatz einfach (fast) alles gleich gekauft habe. Beim ersten Gehäuse war eine iMon MCE dabei, aber im Laufe der Herstellung haben sie das dann auf das iMon Pad geändert. Es gibt wohl Probleme unter Windows mit der MCE, daher haben sie auf das Pad gewechselt. Ironischerweise verhält es sich unter Linux genau umgekehrt, die MCE läuft besser als das Pad
Dämlicherweise senden die integrierten Empfänger auch noch die gleiche ID, weswegen udev die MCE immer erst als Pad erkennt und ich dann erst mal die rc_maps.cfg ändern muss.

So genug OT

louis
Gerade weil ich eben beide Reihenfolgen (je nach VDR) habe und man die Ferndienung meist blind bedient ist es eine große Denkhilfe, wenn man es im OSD sieht.
Danke fürs bei Gelegenheit implementieren

An meinem Test VDR habe ich ein iMon Pad, welches keine "normale" Reihenfolge der Farbtasten hat. In nopacity werden ja bereits die VDR Einstellungen übernommen. Wäre schön, wenn das auch in tvguide einfließen könnte.