Hi,
Epgsearch muss eben auf die neuen Gegebenheiten angepasst werden, damit es wieder so funktioniert wie vorher (aber eben ohne die Abhãngigkeiten) . Winnie hat sich die Sache schon angesehen und wird es einbauen, das ist nur eine Frage der Zeit 
Ciao Louis
Kann man eigentlich das vdr-interne egp so einstellen, dass es mit running now losläuft, und nicht mit dem jeweiligen Kanal-Programm?
Du kannst dir ein Keymacro machen, das "Schedules" und dann "Green" macht.
Klaus
Da man ja eh schon epgsearch patchen muss
Warum muß man das patchen?
Zitat
(soviel zu "Nichtabhängigkeit" von Plugins untereinander(*)),
Was für eine Abhängigkeit ist das denn?
Wieso muß "nOpacity" etwas von "epgsearch" wissen (oder umgekehrt)?
Das eine ist doch ein EPG-Plugin, und das andere eine Skin?!
Zitat
kann man nicht epgsearch gleich so anpassen, dass man es wieder als Ersatz für die verkümmerte VDR-eigene Funktion einsetzen kann?
Was heißt denn "verkümmert"?
Zitat
(*) @Klaus: ja, ich weiss, dass das genau das ist, was Du Dir nicht wünschst. Und nachdem ich in der letzten Woche gelesen habe, was Du alles einstecken mußtest, darfst Du mich jetzt gerne verbal lang machen - ich kanns ab, und Du willst ja vieleicht auch mal...
Was hätte ich denn davon? 
Klaus
Verkümmert war nicht bös gemeint. Mir ist auch erst bei der Abwesenheit von epgsearch aufgefallen, wie sehr ich es benutze.
Guck Dir nopacity mal an. Das ist einfach nur schön, was Louis da mit der Aufbereitung der Listen gemacht hat!!! Aber dazu muss man halt wiseen in welcher Liste man gerade ist. Bitte, lass den vdr-Entwickler mal draußen vor der Wohnzimmertür, und sieh es Dir mit Kinder-/Frauen-/Benutzeraugen ganz unvoreingenommen an. Ich würde den vdr immer auch ohne nopacity jedem anderen diskrecorder vorziehen, aber nopacity trägt die innere Schönheit nach außen... (kein smiley, weil sehr ernst gemeint!)
Gruß, Ingo
P.S.: Was Du davon hättest? Ich habe in den letzten Tagen gelernt, dass beleidigen nicht nur den Entwicklungsprozess beschleunigt, sondern auch den build-Vorgang reibungsloser macht...
Guck Dir nopacity mal an.
Ich hatte bereits versucht, es zu compilieren, aber anscheinend gibt es (zumindest auf openSUSE 12.2) keine 32-bit-Variante von ImageMagick. Mein Arbeitsrecher hat openSUSE 12.2 64-bit, aber mein VDR läuft noch unter 11.4 32-bit. Da das dann nicht "out of the box" geklappt hat, habe ich es wieder beiseite gelegt...
Zitat
Das ist einfach nur schön, was Louis da mit der Aufbereitung der Listen gemacht hat!!! Aber dazu muss man halt wiseen in welcher Liste man gerade ist.
Aber das weiß er doch inzwischen mit den erweiterten Kategorien, oder nicht?
Zitat
Bitte, lass den vdr-Entwickler mal draußen vor der Wohnzimmertür, und sieh es Dir mit Kinder-/Frauen-/Benutzeraugen ganz unvoreingenommen an. Ich würde den vdr immer auch ohne nopacity jedem anderen diskrecorder vorziehen, aber nopacity trägt die innere Schönheit nach außen... (kein smiley, weil sehr ernst gemeint!)
Da scheiden sich halt die Geister. Für mich ist in erster Linie die Funktion wichtig. Ich möchte nicht mit dem VDR "spielen" und mich an seinem Anblick "ergötzen", sondern einfach nur fernsehen und Aufzeichnungen wiedergeben.
Zitat
P.S.: Was Du davon hättest? Ich habe in den letzten Tagen gelernt, dass beleidigen nicht nur den Entwicklungsprozess beschleunigt, sondern auch den build-Vorgang reibungsloser macht...
Täusch' dich da mal nicht - mit sowas kann man auch sehr schnell auf einer "schwarzen Liste" landen und künftig nicht mehr ernst genommen werden...
Klaus
Wenn ich die von mir genutzten Plugin mal auf Abhängigkeiten zum Epgsearch hin prüfe, so finde ich da auf Anhieb sowohl das
EnigmaNG Skin als auch GraphTFT. Nopacity ist hier wohl nur einem existierenden Trend gefolgt.
Der Unterschied zwischen dem integrierten EPG und EPGsearch ist IMHO schon so groß, als ob man einen Trabbi mit einem Mercedes
vergleicht. Wie wichtig den VDR Benutzern das EPG ist, kann man auch sehr schön an dem Aufsehen messen, als letzthin
Änderungen am Format gemacht wurden.
Wenn also solche Verbindungen zwischen Plugins geschaffen werden, dass ist das IMHO nur ein Beweis für die allgemeine Akzeptanz
und den Verbreitungsgrad und damit die Wichtigkeit von EPGsearch. Damit wird das Vorhandensein dieses Plugins schon fast zu einem
Standard erhoben.
Da nun schon ein Trend zur Integration diverser bisher einzeln existierender Einzelpatches existiert (z. B. Unicable), so möchte ich hier
einmal die Frage stellen, warum es nicht sinnvoll sein könnte EPGsearch als Standard in den VDR Core zu integrieren?
Damit würde sich die Frage mit den Pluginabhängigkeiten auch lösen lassen. Ich sehe hier durchaus auch das Problem, dass dann verschiedene Leute am Core weiter arbeiten müssten. Etwas das Klaus sich bisher exklusiv vorbehalten hat. Aus diesem Grund wurde
die Plugin Schnittstelle ja erst geschaffen. Bleibt die Frage nach einem Kompromiss zwischen beidem?
Auch wenn diese Fragestellung hier untergehen sollte, bin ich mir sicher das es nicht das letzte Mal sein wird, dass jemand diese
Frage so oder in ähnlicher Form aufwirft. 
Gruss und ein schönes neues Jahr, Thomas
Wenn ich die von mir genutzten Plugin mal auf Abhängigkeiten zum Epgsearch hin prüfe, so finde ich da auf Anhieb sowohl das
EnigmaNG Skin als auch GraphTFT. Nopacity ist hier wohl nur einem existierenden Trend gefolgt.
Ich warte eigentlich immer noch darauf, daß mir jemand erklärt, was das denn für eine Abhängigkeit ist...
Ich verstehe einfach nicht, warum eine Skin von einem anderen Plugin abhängig sein sollte.
Klaus
Ich warte eigentlich immer noch darauf, daß mir jemand erklärt, was das denn für eine Abhängigkeit ist...
Ich verstehe einfach nicht, warum eine Skin von einem anderen Plugin abhängig sein sollte.
Klaus
Ich versuche das einmal runter zu brechen.
Plugins sollen den Funktionsumfang erweitern. Warum sollte es dann nicht vorkommen können, dass Plugins auch untereinander diese Mehrwerte nutzen um ihren eigenen zu steigern? Kaskadierung eben. Wenn man ein Haus baut, dann kann zwar jeder ein Zimmer auf
das Fundament bauen, aber richtig gut wird es doch erst mit mehreren Stockwerken, oder?
Bei EPGsearch ist es sogar noch extremer. Es schickt sich an, das Fundament teilweise ersetzen zu wollen.
Solche Durchgriffe treten IMHO bei Skin Plugins am ehesten auf, weil man Funktionen aus dem VDR Core zusammen mit welchen aus beliebigen Plugins unter einer Oberfläche zusammen fassen möchte. Aus meiner persönlichen Erfahrung kann ich da die Verbindung zwischen skinelchi und dem Avards Plugin nennen. Da wurde über Avards das aktuelle Seitenverhältnis ermittelt und dargestellt
(4:3, 16:9 usw.).
Bei EnigmaNG und hier wird das u. a. zur korrekten Darstellung von Progressbars und Integration von Logos, sowie zur Teilung des Bildschirms benutzt.
Ich hoffe das hilft weiter. ![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude"){kind=small}
Ich warte eigentlich immer noch darauf, daß mir jemand erklärt, was das denn für eine Abhängigkeit ist...
Ich verstehe einfach nicht, warum eine Skin von einem anderen Plugin abhängig sein sollte.
Klaus
.. wieso diskutiert ihr da noch? louis hat eh schon bestätigt, daß die abhängigkeiten rausfliegen/schon sind - abgesehen von den patches im nopacity/src, die (noch) separat gepflegt werden.
ciax
Hi,
Epgsearch muss eben auf die neuen Gegebenheiten angepasst werden, damit es wieder so funktioniert wie vorher (aber eben ohne die Abhãngigkeiten) . Winnie hat sich die Sache schon angesehen und wird es einbauen, das ist nur eine Frage der Zeit
Ciao Louis
Ups, die Antwort hatte ich übersehen. Das ist doch mal ein Wort! Super. Auch schonmal vorab Danke an Winnie.
Gruß, Ingo
Euch allen ein Frohes und Gesundes Neues Jahr!
Ich habe die Diskussionen in letzter Zeit auch einigermassen verfolgt und habe den Scaling Patch fuer nOpacity nun den daraus neu gewonnenen Erkentnissen (dank Kls und Johns) angepasst, hier kommt nun die 5-te Version. Fuer Softhddevice braucht man ja nun keinen Patch mehr, den YaEPG-HD Scaling Patch habe ich nun auch angepasst und mit vdr-1.7.35 ausprobiert und er funktioniert. Andere Scaling-Patches werde ich noch in diesem Thread aktualisieren.
Ciao, Lucian
Edit: Wegen Rejects V6 weiter unten .
Da nun schon ein Trend zur Integration diverser bisher einzeln existierender Einzelpatches existiert (z. B. Unicable), so möchte ich hier
einmal die Frage stellen, warum es nicht sinnvoll sein könnte EPGsearch als Standard in den VDR Core zu integrieren?
EPGSearch ist kein Patch sondern ein (gut gepflegtes) Plugin. Ich frage mich immer wieder auf's neue, warum Leute so scharf darauf sind, dass Plugins (erst recht wenn gut gepflegt) direkt in den VDR integriert werden. Warum wollt ihr unbedingt Winnie sein Projekt wegnehmen und warum wollt ihr unbedingt Klaus die zusätzliche Arbeit aufhalsen?
Was die Abhängigkeiten angeht: Es geht, wenn ich das richtig verstanden habe, wohl im wesentlichen darum, dass das "epgsearch-Menü", welches ja das EPG-Menü vom VDR ersetzt, nun wieder so "angeglichen" werden muss dass es sich wieder analog zum VDR-eigenen Menü verhält und somit der Skin seine entsprechenden Anpassungen machen kann. Also sozusagen die von Klaus neu geschaffenen API-Funktionen auch im epgsearch-Plugin nutzen.
Moin,
genau so ist es...ist alles schon in der Mache, dauert nicht mehr lange, dann kann man mit epgsearch auch wieder das Schedules Menu ersetzen. Und alles ohne irgendwelche bösen Hacks
Zoolook: vielen Dank, werde ich bald einbauen...aktuell bin ich an einem neuen schönen Aufnahmeverzeichnis
Ciao Louis
Ich habe die Diskussionen in letzter Zeit auch einigermassen verfolgt und habe den Scaling Patch fuer nOpacity nun den daraus neu gewonnenen Erkentnissen (dank Kls und Johns) angepasst, hier kommt nun die 5-te Version.
Hi Lucian,
nochmals vielen Dank:
1. funktioniert wunderbar. (seit 6 Stunden ist er aktive - jetzt ahbe ich eine halbe Stunde aktiv getestet. Passt alles kein Flackern immer die richtoge Größe, auch bei 4:3 und wieder zurück - und stabil sowieso, aber das kann man von Louis, Jhons und Dir ja wohl auch erwarten... )
2. Läuft hier unter 1.7.35 - der Dateiname ist evtl. etwas verwirrend für jeanden, der die Scaling-Patcherei nicht verfolgt hat...
Auch Dir ein frohes Neues,
Gruß, Ingo
2. Läuft hier unter 1.7.35 - der Dateiname ist evtl. etwas verwirrend für jeanden, der die Scaling-Patcherei nicht verfolgt hat...
Meckermaeulchen, akkurat waere wohl >= 1.7.33 gewesen, wie in meinem Betreff, geht aber wohl in Dateinamen echt schlecht, je nach Dateisystem... Ja, ich schlage mich auch mit 1.7.35 'rum, und versuche gleichzeitig hd_brummy beim Packages maintainen (Gentoo, versteht sich ) zu helfen...
Ciao, Lucian
P.S. Bald kann man das auch mit vdr-xine in der neuen Variante testen, bin noch am Feinschliff...
Im SoftHdDevice Setup kann man die Bildhintergrundfarbe verstellen,
wenn man dies möchte. Bei der Transparenz habe ich noch keinen
Effekt feststellen können.
Johns
louis: Streber!
Nein, extrecmenu bekommt ein Problem mit uns Spass bei Seite...gleiches Spiel wie bei epgsearch. extrecmenu muss die neue API benutzen, dann klappt das auch mit dem ersetzen des Aufnahmeverzeichnisses...ich muss mir das mal anschauen, evtl. erstelle ich selbst einen Patch, oder ich bitte den Maintainer, das einzubauen. Bei epgsearch wird das ja auch...muss ich übrigens nur noch final testen, dann wird das auch bald online gehen.
Ciao Louis
Hi,
gerade hatte ich nOpacity neu gebaut, und stellt fest, Im Zuge der letzten Aenderungen gab es ein Reject am Scaling Patch, deswegen anbei V6.
Have phun, Lucian
Hi,
bei mir crasht es mit frisch gebauten Git-Sourcen von nOpacity, epgsearch und softhddevice, gegen vdr-1.7.35, gleich an 2 Stellen:
Bin ich wohl der Einzige dem das passiert?
Ciao, Lucian
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
