es sei denn, irgendwer sonst uebernimmt die Wartung, ist alles GPL.
Anmerkung noch dazu:
Wenn jemand die Wartung fuer den saa716x-Treiber (u.a. fuer die HD-FF) uebernehmen will: ich bin nicht in der Lage, die mir vorliegenden Unterlagen und Design-Files zu der S2-6400 und zum SAA7160/1/2 weiterzugeben, da ich das alles nur unter NDA (Verschwiegenheitsvereinbarung) erhalten habe.
Gruss,
S:oren
Was auch immer jemand unternehmen will, mir soll alles recht sein.
Nochmal:Wenn jemand die linux-media-"Maintainer" ueberzeugt, dass die Treiber fuer die SD-FullFeatured-Karten in Linux drin bleiben, dann baue ich die erforderliche Konvertierung zu vb2, auch die saa7146-Budget-Karten bleiben dann unterstuetzt.
Ich werde in diesem Fall auch in der Lage sein, den Treiber fuer die HD-FF (TT S2-6400) und die saa7160-Budget-Karten weiter zu pflegen (was ich seit fast 10 Jahren mache - am Anfang nur nebenbei mit Andreas Regel als Hauptverantwortlichem - und was ganz sicher mehr Aufwand ist als mal ein einzelner Patch).
Mal als ein Zitat meines Angebots, mehr Details oben.
Je öfter ich mir diesen Thread und Deine Beiträge durchlese, desto rätselhafter wird mir, was eigentlich Deine Absicht ist.
Meine Absicht ist, die FF-Karten und deren Treiber fuer die Community am Leben zu erhalten. Ich bin bereit, alle technische Arbeit dafuer zu tun, wenn die Mainline-Unterstuetzung bleibt, und das von linux-media auch klar anerkannt wird. Ansonsten bleibt es bei dem perfiden Spiel, was hier gerade im Gange ist: die Treiber schnell nach staging verschieben, dann ueber die Feiertage komplett entfernen, offenbar in der Hoffung, dass so schnell niemand reagiert. Eine Vorwarnzeit von 3 (?) Wochen zwischen dem staging-Release linux-6.1 und dem Entfernungs-Patch finde ich mehr als unverschaemt.
Du schreibst, dass Du Tester suchst, die eine Mail mit Tested-by tag an die mailing list schicken, lieferst aber bis heute keinen einzigen Patch.
Die Reihenfolge ist
- die Community ueberzeugt linux-media, dass die FF-Karten benutzt werden und die Treiber inkl. DVB-API vollstaendig in mainline bleiben
- linux-media erkennt das offiziell an
- ich baue saemtliche erforderlichen Patches zur vb2-Konvertierung
- ich teste diese auf meiner FF und stelle sie auf der Mailingliste vor
- Nutzer von Budget-Karten testen sie auch und geben entsprechend Rueckmeldung
Alle unterstuetzten saa7164-Karten funktionieren dann weiterhin problemlos und das vb1-API kann aus mainline entfernt werden (was ein absolut verstaendliches Ziel ist, was ich auch unterstuetze).
Alternativ kann von mir aus saemtliche Analog-Video-Funktionalitaet fuer saa7164-Analog(?)/Hybrid-Karten entfernt werden, macht die vb2-Konvertierung einfacher (insbesondere weil es vermutlich keine Tester dafuer gibt). Fuer FF-Karten soll es bleiben, wenn immer machbar (ist ansonsten schade, aber keine Kernfunktionalitaet). Wenn Hans (einen Teil) der Konvertierungen selber machen will, von mir aus gerne.
Fliegt die Unterstuetzung der SD-FF aus mainline 'raus (oder auch nur die fuer saa7110 oder den output/osd-Teil des DVB-API), dann gilt:
Fliegt der ttpci/av7110-Treiber und der Output-Teil des DVB-API aus mainline raus, dann ist das halt weg. Ich werde nicht weiter versuchen, dies am Leben zu erhalten. Ich habe lange genug auf einsamem Posten gekaempft, ich habe keine Kraft mehr fuer politische sinnfreie Diskussionen. Das betrifft dann auch die HD-FF.
und:
Mein Angebot an die Community steht. Ob es angenommen oder abgelehnt wird, mir beides recht.
Ich verlange nichts von der Community, ausser selbst fuer den Erhalt der FF-Karten zu kaempfen, wenn die Community das will. Bleiben nur saa7164-Budget-Karten im mainline unterstuetzt, fein, ich goennne das jedem Nutzer dieser Karten. Fliegt FF-Unterstaezung 'raus, auch OK fuer mich. Dann werde ich fuer mich selbst die SD- und HD-FF-Treiber solange und in dem Umfang patchen, wie das fuer mich selbst sinnvoll und notwendig ist. Oeffentliche Releases gibt es dann nicht mehr, es sei denn, irgendwer sonst uebernimmt die Wartung, ist alles GPL.
Nochmal: ich verlange nichts, biete Alternativen an (die zum Teil Arbeit fuer mich in meiner Freizeit beinhalten), die Community moege entscheiden, was sie daraus macht.
Gruss,
S:oren
Wenn fuer die Grab-Funktion eine vb2-Konvertierung notwendig ist, wuerde ich die gerne machen. Natuerlich nur, wenn der av7110 aktiv bleibt und irgendwas decodiert, was man auch grabben kann.
Besser wäre es jedenfalls, den Grabbing-Teil im Plugin rauszunehmen um Fehler zu vermeiden.
Ich finde es besser, bestehende Funktionen drin zu lassen, wenn sich jemand darum kuemmert, der es auch testen kann und wird (unter den genannten Randbedingungen).
Und ich finde es einfach nur armselig, wenn ein erklaerter Nicht-Nutzer der FF-Karten andauert versucht, den Nutzern dieser Karten ihr Hobby madig zu machen.
Gruss,
:Soren
Reicht auch noch bei der naechsten Mail, oder wann immer es konkret wird...
Und das Plugin (das seit Jahren obsolet ist und nicht mehr Teil des vdr-Codes)
Das dvbsddevice-Plugin ist nicht mehr Teil des vdr selber, so wie alle Ausgabeplugins und viele, viele andere Plugins auch. Daraus ergibt sich in keinster Weise, dass dieses Plugin obsolet oder unbrauchbar oder nicht gewartet, oder was auch immer in dieser Art ist. Wenn Du keine SD-FF als Ausgabedevice nutzt, dann brauchst Du das Plugin nicht. Andere Leute nutzen es und sind sehr zufrieden damit.
Wenn fuer die Grab-Funktion eine vb2-Konvertierung notwendig ist, wuerde ich die gerne machen. Natuerlich nur, wenn der av7110 aktiv bleibt und irgendwas decodiert, was man auch grabben kann. Andere Analog/Hybrid-Funktionen des saa7164 benutze ich nicht, kann ich nicht testen, koennen von mir aus gerne entfernt werden.
Wie schon oben steht, wenn jemand irgendwas zu dem Thema an die Mailingliste schreibt, mich bitte auf Cc: setzen.
Gruss,
S:oren
Mit einer Reihe von Patches sind nun also nicht nur die Treiber für die SD-FF-Karten aus dem Kernel geflogen, sondern auch die saa7164-basierten Budget-Karten, [...] Im Kernel 6.2, für den gerade am rc3 gearbeitet wird, werden sie wohl noch enthalten sein.
Kommt nur mir diese Logik "seltsam" vor?
Danach fürchte ich, wird diese Patch-Serie akzeptiert und eingepflegt.
Wenn niemand Einspruch erhebt, wird das sicher so sein.
Bei der alten FF-Karte kann ich es ja noch verstehen, denn es war nicht nur die Umstellung von vb auf vb2 zu erledigen, sondern auch eine Umstellung von der alten DVB API.
Das wird nicht dadurch wahrer, dass Du es immer wiederholst.
Bei den Budget-Karten, wo es "nur" um eine Umstellung von vb auf vb2 ging, ist das schon ärgerlich.
Auch "seltsam", dass derjenige am meisten jammert, der hier im Thread an vorderster Front die noch bestehenden Moeglichkeiten kleinredet und jeden aufkommenden Enthusiasmus sofort versucht, im Keim zu ersticken.
Ein paar (mehr) Leute mit dieser Einstellung:
Wir dürfen das nicht passiv über uns ergehen lassen, sondern müssen aktiv werden und uns dort zu Wort melden. Ansonsten fliegen die raus.
koennten schon etwas bewirken, denke ich.
Da habe ich sehr viele Fragen:
Welche Version des Treibers ist das genau, ist es eine Kernel-Version aus meinem Repository oder irgendwie verbastelt?
Welche Firmware?
verbose=3 ist heftig, klappt es ohne besser?
Welche Aufloesungen (OSD und Output) sind eingestellt? Geht es mit 720p?
Was sagt 'lspci -vvv' ?
Geht es mit der alten originalen VDR-Installation (inklusive Linux) auf dem neuen Board?
Ist das primaer ein I2C-Fehler oder PTE-Prefetch (was heisst FPTE im Titel)?
Brauchst Du das video_capture wirklich, im "Normalbetrieb"?
Gruss,
S:oren
Ach ja:
Ist das neueste BIOS auf dem Board?
Funktioniert die Karte in einem andern PCIe-Slot? Oder nachdem man sie 3x herausgezogen und wieder eingesteckt hat? Oder wenn man sie nicht ganz bis zum Anschlag in den Slot steckt (Abstand zum Anschlag halber Millimeter maximal)?
Kann man im BIOS auf eine kleinere PCIe-Version umschalten (Gen 1), oder irgendwelche Extensions abschalten?
Ist der memtest OK? Und das Linux sonst stabil? Prozessorkuehler korrekt montiert (Temperatur gecheckt)?
Mir faellt bestimmt noch mehr ein, soll aber erstmal reichen...
Eins noch: Ist das Netzteil stark genug fuer das neue Board?
S:oren, ist das so richtig?
Ja. Aber einfach nur irgendwas an die Mailingliste zu schicken, ist fast schon eine Garantie, ignoriert zu werden. Man sollte entweder auf irgendwas an alle antworten, oder zumindest alle relevanten Maintainer und sonstige (potentiell) interessierten Personen mit auf cc: setzen.
Eine Verständnisfrage noch, was hat das mit den HD-FF-Karten zu tun?
Auch die HD-FF basiert auf dem selben DVB-API wie die SD-FF. Schon jetzt gibt es erheblichen Zusatzaufwand, weil das in-tree-API nicht mehr vollstaendig ist (AUDIO_GET_PTS). Der Aufwand, das alles zu warten, wird noch steigen, wenn der ganze Output-Teil des DVB-API extern gepflegt werden muss. Waere schon machbar, aber:
Von Anfang an habe ich so viel Aufwand in den Treiber gesteckt, weil ich immer noch eine Perspektive fuer die Aufnahme in den Kernel gesehen habe. Das wuerde fuer alle Beteiligten (User, Developer, Distris) das Leben erheblich vereinfachen. Selbst fuer mich, auch wenn ich - wie mehrfach angeboten - den Treiber weiter in-tree pflegen muesste/duerfte. Einen Nachteil fuer den Kernel kann ich dabei nicht erkennen.
Ohne diese Perspektive und mit noch mehr Zusatzaufwand wird das Verhaeltnis aus Aufwand, Nutzen und Spass fuer mich immer unguenstiger. Ja, neben der Freude, wenn irgendwas funktioniert, gibt es immer wieder Gelegenheit, etwas zu lernen. Aber in anderen Kernel-Subsystemen gibt es Zusammenarbeit und eine gemeinsame Suche nach guten technischen Loesungen. Bei linux-media wird man zur externen Entwicklung verdammt. Mauro hat meiner Ansicht nach die tatsaechliche Arbeit eingestellt nachdem er vor Jahren vom "alten Linus" ordentlich auf's Dach bekommen hat, jetzt wird nur noch mit ewigem Hin- und Herschieben von Code Arbeit vorgetaeuscht, und mit starken Worten und FUD Entwickler abgeschreckt, um die eigene Unfaehigkeit zu verstecken. Die Frage bleibt, ob es mit Hans besser laufen koennte (der hat ja die merkwuerdigen TODOs eingebracht, so vielleicht eher nicht).
Ich freue mich schon, dass ich einigen anderen Leuten Unterstuetzung bieten konnte, es gibt ja auch immer wieder Dank dafuer. Aber es gibt auch Leute, die mir vorwerfen, irgendwelche Lizenzen zu verletzen, sowieso alles falsch zu machen, und eh keine Ahnung zu haben. Oder welche, denen man wochenlang hilft, eine Anpassung fuer eine neue Budget-Karte einzubauen, und die dann kurz bevor es perfekt laeuft (oder danach?) ploetzlich das Handtuch werfen und keinen Patch einbringen. Sowas ist dann auch frustrierend.
Meines Erachtens hat die Konvertierung der saa7146-basierten Treiber für "Budget"-Karten auf vb2 Vorrang
Mag so sein. Fuer jeden hat das Vorrang, was er selbst benutzt.
S:oren, wenn Du das machen würdest, würdest Du der Community sicher einen großen Dienst erweisen. Dazu sind auch gar keine ideologischen Grabenkämpfe oder "Unterstützer-Bekundungen" auf der linuxtv-Mailinglist erforderlich.
Mein Angebot an die Community steht. Ob es angenommen oder abgelehnt wird, mir beides recht.
Anders sieht es aus mit dem dvb-ttpci-Treiber für die alten FF-Karten. Sie enthalten den av7110 mit seinem Decoderteil und den vielen ioctls aus der deprecated DVB API 3. Dessen vollständige Konvertierung erscheint mir nahezu unmöglich, denn leider gibt es nicht für alle 36 von vdr (dvbsddevice-Plugin) genutzten ioctls geeigneten Ersatz aus der V4L2-API.
[...]
Ob man auf dem gleichen Wege dort auch av7110-spezifische ioctls definieren könnte und das durchkriegt - keine Ahnung.
Es gibt im Kernel bereits das perfekte API fuer FF-Karten: das DVB-API. Dieses ist auch immer noch aktuell und wird von hunderten Karten und Treibern benutzt.
Teile davon abzukuendigen ohne adäquaten Ersatz zeugt fuer mich nur von der Unfaehigkeit der verantwortlichen Person. Es gibt keinen technischen Grund (nur den oben von mir vermuteten anderen). Oder was soll bitte so eine API-Konversion bringen, ausser den oben beschriebenen Nebenwirkungen? Die Fragen habe ich auch linux-media schon gestellt und keine Antwort bekommen.
Die Abkuendigung kann man leicht zurueck nehmen, ist (fast) alles noch da. Sogar jemand, der sich um API und Treiber kuemmern wuerde.
Für die Beurteilung, ob sich der Aufwand lohnt, wäre die Frage nun m.E., wieviele Leute die FF-Karten noch wofür benutzen: [...]
Bin mir nicht sicher, was ich aus diesem Text lesen soll.
Ob und wofuer jemand eine FF-Karte benutzt, entscheidet man ja selber. Wie das generelle Interesse der Community ist, ist ja gerade Gegenstand der Diskussion hier. Welchen Aufwand ich wofuer in meiner Freizeit aufbringe, ist meine Entscheidung.
Ich fand es fair, meine Beweggruende und die sich daraus ergebenden Optionen klar anzusprechen. Ich selbst werde sicher noch eine Weile meine FF-Karten nutzen. Ansonsten ist von meiner Seite alles zu diesem Thema hier gesagt, denke ich.
Gruss,
S:oren
Was auch immer jemand unternehmen will, mir soll alles recht sein.
Nochmal:
Wenn jemand die linux-media-"Maintainer" ueberzeugt, dass die Treiber fuer die SD-FullFeatured-Karten in Linux drin bleiben, dann baue ich die erforderliche Konvertierung zu vb2, auch die saa7146-Budget-Karten bleiben dann unterstuetzt.
Ich werde in diesem Fall auch in der Lage sein, den Treiber fuer die HD-FF (TT S2-6400) und die saa7160-Budget-Karten weiter zu pflegen (was ich seit fast 10 Jahren mache - am Anfang nur nebenbei mit Andreas Regel als Hauptverantwortlichem - und was ganz sicher mehr Aufwand ist als mal ein einzelner Patch).
Fliegt der ttpci/av7110-Treiber und der Output-Teil des DVB-API aus mainline raus, dann ist das halt weg. Ich werde nicht weiter versuchen, dies am Leben zu erhalten. Ich habe lange genug auf einsamem Posten gekaempft, ich habe keine Kraft mehr fuer politische sinnfreie Diskussionen. Das betrifft dann auch die HD-FF.
Auch hier scheinen einige Leute der Meinung zu sein, dass das alles altes unnuetzes Zeug ist (niemand wird gezwungen, es zu nutzen). Oder gar, dass man die FF-Treiber vom DVB-API auf V4L2 konvertieren sollte (wie es Mauro gerne haette). Es gibt in meinen Augen keinen groesseren Unsinn:
DVB-API und V4L-API existieren in linux-media von Anfang an parallel. Niemand ist je auf die Idee gekommen, den Input-Teil des DVB-API (Budget-Karten, DVB-Sticks) nach V4L(2) zu konvertieren. Es gibt hunderte DVB-Treiber und -Karten im aktuellen mainline. Aber weil es nur einen Mainline-Treiber gibt, der den Output-Teil des DVB-API implementiert, geht das natuerlich gar nicht. Warum auch immer, konnte niemand erklaeren. Auch nicht, wie genau das dann gedacht ist. Der Input-Teil der FF-Karten (tuner, demod, demux) wird wie bei allen anderen DVB-Karten mit dem DVB-API benutzt, der Output-Teil (Dekoder) mit V4L2-API? Damit man ein API-Mischmash im Treiber hat und die exitierenden Anwendungen fuer FF-Karten (VDR, Enigma2) nicht mehr funktionieren?
Weil es keine 2 APIs fuer Video-Dekoder geben darf, obwohl Settop-Boxen (VDR) und Video-Player (kaffeine) total unterschiedliche Anwendungen mit ganz anderen Anforderungen und Hardware-Implementierungen sind? Und die beiden APIs keineswegs neu sind, sondern schon immer da (schon vor linux-media und Mauro)? Gut, nach der Logik muessten z.B. aber auch alle seriellen Treiber aus Linux verschwinden, weil man ja Bootmeldungen auch in einem Framebuffer darstellen kann. Wie gesagt, der groesste denkbare Unsinn fuer mich.
DVB-API ist alt, V4L2 is 'current API'. Nur nicht fuer DVB-Sticks, komisch.
DVB-Output-API ist 'different API' als DVB-input-API. Klar, wenn man das gesamte DVB-API nie verstanden hat, obwohl man seit Jahrzehnten auch dafuer bezahlt wird, es zu warten.
Anscheinend habe _ich_ keine Ahnung. Mag irgendwer uebernehmen, der es besser kann und mehr Durchblick hat. Ist alles GPL.
Tschuess,
S:oren
Was für eine Unterstützung willst du denn haben?
Welcher Teil meines Angebots an die Community genau ist denn unklar?
Hat doch erst Sinn, wenn ein Patch da ist, oder?
Äh, nein. Es geht hier nicht um technische Fragen (die immer loesbar sind).
Falls du einen Patch für die Umstellung machst, und der nicht akzeptiert würde, könnte man den aber immer noch als Selbstkernelbauer anwenden, oder?
Selbstverstaendlich. Nur wenn ich keinerlei, exakt Null, Unterstuetzung fuer die FF-Karten bei linux-media bekomme, warum sollte ich so einen Patch bauen und veroeffentlichen? Passende Budget-Karten habe ich nicht, und auch keine Langeweile.
Well, the question is what they mean when saying "Cleanup patches"?
The whole purpose of a TODO file in a staging driver is to tell what needs to be done to get this out of staging.
They already accepted patches for other cards.
Great, linux-media is not completely dead. A little bit of work is still be done. What a great achievement, for payed maintainers/supporters.
So I am not sure, if your concern, just from reading a comment, is justified. But who knows ...
Well, not all TODO files have this content. But the file for my card's driver has.
So you tell me, I'm to dumb to understand the subtleties here!? Thanks!
It would be great, if you would do the the videobuf2 conversion.
I would be willing to test on a budget card and also to provide a Tested-by tag.
So you ask me to to do the work for your card, while not supporting to keep my card alive!? What I great incentive to spend my holiday time...
Some discussions here, at least.
For me, the videobuf2 conversion itself is not a big problem. A can do that, and test that on a SD-FF (AV7110) card. For SAA7146 budget cards I would need other testers, who also will provide Tested-by tags to the media mailing list.
Technically that is just work where I probably can do the programming part over the Christmas holidays.
The real problem - as always with linux-media - is political, see drivers/staging/media/deprecated/saa7146/av7110/TODO (v6.1-rc8):
- This driver is too old and relies on a different API.
Drop it from Kernel on a couple of versions.
- Cleanup patches for the drivers here won't be accepted.What the "different API" is, what the problem with old but used and maintained hardware+drivers is, and how this relates to
If someone is interested in doing this work, then contact the
linux-media mailinglistin the same file probably can only understand linux-media "maintainers".
For me "patches won't be accepted" is the opposite of maintenance.
If somebody else wants to discuss this on the linux-media mailing list, I'm happy to join this discussion (please cc: me). As it stands now, doing all the work with the clear prospect of not being accepted makes no sense at all for me.
Besides that, last time I fought for these drivers, exactly nobody from the VDR community supported me on the mailing list. And this is not about 'programming or reviewing these patches is too complicated for me'. Just 'I use this and plan to do so as long as possible', 'I'm happy to see this driver upstream and supported in distribution xy', or 'I would even be more happy to also see the related saa716x driver upstream' would counter the usual 'this is old and irrelevant anyway'.
Yes, this also relates to the HD-FF (saa716x) cards. videobuf2 conversion will be necessary here too (but this makes sense for linux overall), further crippling the DVB API upstream instead will make live increasingly complicated for this driver, without any technical reason.
I always liked to maintain these drivers and to adapt everything required for modern linux versions. But I'm really tired of all the political discussions. Without at least a little bit of help from the community at linux-media, I cannot promise to continue support.
Regards,
S:oren
Hallo FireFly,
bei dem cleanup_case_fall_through war ich mir nicht sicher, die restlichen ergeben tatsaechlich nur in der Gesamtheit Sinn - und sollten dann auch ohne Rejects passen.
Gute Frage, was die Probleme urspruenglich ausgeloest hat. Muss dann ja eigentlich irgendwas sein, was in dem vanilla-5.14 noch nicht drin war. Das spricht dann eher gegen einen Backport. Andererseits sollten die Patches auch nichts kaputt machen, betreffen ja komplett "Innereien" des Treibers und der Hardware. Aber wer weiss, angeblich hat man schon Pferde kotzen sehen...
Fuer openSuse15.4 hast Du das Problem mit Deinem Paket ja geloest und gut getestet. Dann lasse ich meinen 5.14er Branch erstmal, wie er ist. Kann ich ja immer noch aendern, wenn jemand das gerne anders haette und dann auch den Branch selber testet.
Vielen Dank, dass Du den Treiber immer fuer SuSe anpasst, leider hat da jede Distribution andere Anforderungen.
Gruss,
S:oren
und seitdem keinerlei Probleme mehr.
Klingt gut. Ich habe seit diesem Treiber-Update im April auch keine I2C-Probleme mehr bei mir gehabt (mit verschiedenen neueren Kernel-Versionen).
Kann ich das als Test der 5.15er Patches (welche genau?) fuer den 5.14er Zweig werten und diese getesteten Patches dann rueckportieren?
Ich fuege auch gerne Dein Tested-by-Tag hinzu, wenn Du mir eins schickst...
Gruss,
S:oren
Apparently nobody else here is interested in keeping the full-featured DVB cards alive for VDR!?
If so, I will not waste my time investigating and fixing this problem - or maybe only for myself.
Regards,
S:oren
Bei mir ist alles aehnlich. Ich benutze auch transparente Hintergruende, weil skinnopacity den Hintergrund separat (nach Theme) laden kann. Bei dem default-Theme ist dort die Standard-Logogroesse bei 720p-Wiedergabe ohne Overscan am Fernseher 184x130, somit erzeuge ich mir die Logos gleich passend, da muss zumindest fuer die groessten vorkommenden Logos nicht mehr zur Laufzeit skaliert werden. Mehrfaches Skalieren erzeugt eben (manchmal?) Ueberraschungen mit einem Pixel(?) Versatz (Rundungsfehler?). Da der Rand bei mir 3 Pixel gewaehlt ist, faellt das dann auf.
Gut zu wissen, dass es aktuell immer noch mehrere gepflegte Logo-Repositories gibt, wenn doch mal irgendwas nicht mehr aktuell gehalten wird. Das Skript zur Konvertierung auf die Namen der channels.conf finde ich richtig gut. Ich habe sowieso nur 40 Sender (2 Seiten im EPG) in meiner channels.conf, nicht die ueber 1000 bei Astra 19.2E oder ein paar Hundert bei KD-DVB-C, die ich sowieso nie anschaue.
Vielen Dank nochmal fuer die Skripte, ich habe seit langer Zeit wieder paasende aktuelle Logos, sehr schoen!
Gruss,
S:oren
Du verwendest Picons2VDR.sh. Hier geht es um Picon.cz2VDR.
Oh, wie bin ich denn da hin gekommen? Ist mir nicht aufgefallen, dass es da 2 verschiedene Varianten mit subtilem Namensunterschied gibt. Dann bitte meine unpassenden Anmerkungen ignorieren.
Was sind denn die Vor- und Nachteile der beiden Skripte?
Hast Du eventuell mal zum Vergleich zwei Logos mit den Einstellungen aus dem original Skript und Deinen Änderungen?
Besonders aufgefallen war mir das beim Logo fuer Kabel1. Wenn ich mir jetzt nochmal die generierten Logos mit Vorgabe-Geometrie ansehe, da gibt es zwar einen Unterschied mit und ohne meinen Patch, aber beides sieht nicht unbedingt falsch aus. Nach nochmaligem Skalieren in skinnopacity sieht man eine leichte Verschiebung nach rechts, das kann aber auch eher Zufall abhaengig von der exakten Skin-Logogroesse sein. Ich hatte Versionen mit weniger Rand als bei der Vorgabe-Geometrie ausprobiert, weiß aber die exakten Einstellungen nicht mehr. Jetzt benutze ich "LOGO_CONF=(184x130 176x124 dark transparent)" (Warnungen zum fehlenden exakten Hintergrund ignoriert, kein Problem weil transparent), da ist der Patch nicht unbedingt noetig. Von mir aus kannst Du den alten Code so lassen, auch wenn der einfachere Code mit Patch fuer mich mindestens genau so gut funktioniert. Diese Diskussion ist ja sowieso im falschen Thread, weil ich ja das Skript ohne .cz benutzt habe.
Habe auch leider erst jetzt Deine Antwort sehen, es gibt anscheinend wieder mal keine Mail-Benachrichtigungen vom Portal mehr.
Gruss,
S:oren
Erstmal: Vielen Dank fuer das Script!
Die korrekte Zuordnung der offenbar aktuellen picon-Logos zu den tatsaechlich vorhandenen Sendern in der channels.conf finde ich wirklich gelungen.
Leider scheinen die Logos nicht perfekt zentriert zu sein. Hab das nicht genauer untersucht oder verstanden, folgender Quick-Hack macht es fuer mich richtiger:
diff --git a/Picons2VDR.sh b/Picons2VDR.sh
index 0ead2e1..6ccb265 100755
--- a/Picons2VDR.sh
+++ b/Picons2VDR.sh
@@ -381,7 +381,7 @@ for logoname in "${logocollection[@]}" ; do
# Erstelle Logo mit Hintergrund
convert "${location}/build-source/backgrounds/${resolution}/${background}.png" \
- \( "$logo" -background none -bordercolor none -border 100 -trim -border 1% -resize "$resize" -gravity center -extent "$resolution" +repage \) \
+ \( "$logo" -background none -resize "$resize" -gravity center -extent "$resolution" \) \
-layers merge - 2>> "$logfile" \
| "$pngquant" - 2>> "$logfile" > "${LOGODIR}/logos/${logoname}.png"
((N_LOGO++))Der "Rand" wird ja durch die beiden Geometrien fuer Gesamt- (Hintergrund) und (eigentliche) Logogroesse definiert. Ich brauche die Logos allerdings fuer skinnopacity, evt. sind die Raender und Aspect-Ratios dort anders als bei SkinFlatplus.
Ansonsten, oder auch damit im Zusammenhang, scheinen ein paar Einstellungen zu LOGO_CONF zusammengefasst zu sein.
LOGO_TYPE -> Hintergrund (Vorgabe transparent)
LOGO_SIZE -> Logogröße (Vorgabe: 220x132)
LOGO_PACKAGE -> Empfangsart (Vorgabe: 19.2E) Beispiel bei Empfang von 2 Satelliten: LOGO_PACKAGE=(19.2E 9.0E)
scheint es so nicht mehr zu geben. Was an sich nicht schlimm ist, eher im Gegenteil, nur passt die Doku nicht mehr ganz.
Ich hoffe es gefällt den einen oder anderen.
Ja, sehr. Hatte mich lange nicht darum gekuemmert, aber jetzt habe ich wieder aktuelle Logos gleich mit richtigem Namen, sehr schoen!
Gruss,
S:oren
Das Updaten der Menüeinträge hat folgenden Grund:
Wenn man z.B. den Eintrag 10 aktiv hat und sich dann mit der 4 die Aufzeichnungen anzeigen läßt und dann mit der Zurück-Taste wieder in das Hauptmenü zurück springt, ist dann der Menüeintrag 4 aktiv (das ist auch die Erwartungshaltung).
Das klappt aber auch so, wenn ich das Update unterdruecke (vor dem Schliessen des Menues und oeffnen des neuen), wie jetzt hier.
Ist halt nicht optimiert, aber ohne Absturz ist das dann auch nicht so schlimm.
Gruss,
S:oren
Ohne Patch funktionierte das letzte auch mit skinnopacity.
Mir ging es nicht darum, was man aufrufen kann oder nicht. Ich wollte wissen, ob man beim Standard-VDR ohne Patches auch so einen Absturz provozieren kann.
Das scheint mir eigentlich ein Problem des Core-VDR zu sein. Warum sollte man einen Menueeintrag (sichtbar oder nicht) updaten (die Darstellung auf ausgewaehlt aendern), wenn das Menue sowieso durch die Auswahl geschlossen wird? So ein Update verlangt aber der VDR-Core. Und das ist eigntlich nur sinnvoll, wenn gescrollt werden soll, nicht bei einer Auswahl mit Zifferntasten.
Aber mein Workaround sollte den Absturz auch fixen.
Gruss,
S:oren
