VDR4Arch - VDR auf Archlinux

Hallo seahawk,

danke für den Tip - hab jetzt mal skinnopa... usw. runtergemacht, imagemagick 6.8.7.2-1 installiert.
Anschliessend skinnopacity gebaut und installiert. Imagemagick hab ich in der pacman.conf gesperrt.

Probieren kann ich aber erst nach dem Tatort. Trotzdem mal vielen Dank

Bernd

Also das Post vorher hat nicht geklappt - hab alles wieder Rückgängig gemacht und hatte die Nase voll !

Aber da ich nicht so schnell Aufgebe - auf meiner Desktop-Maschine läuft seit kurzem auch Arch und da hab
ich mir ImageMagick in Version 6.8.7.0-1 gekrallt und installiert.
Anschließend noch VDR 2.1.2 mit Skinnopacity gebaut und es läuft wie ein Moped - nein wie ein Ferarri !
Ich könnte das Teil alle 5 Minuten neu starten so geht das Ding ab.

Hab jetzt halt ImageMagick gesperrt und kümmere mich mal um die nächsten Baustellen - FB - Channellogos usw.

mfg. Bernd

Danke noch mal seahawk für deinen Tip !!!

Wäre das Binär-Repository eventuell eine Alternative für dich?

https://github.com/CReimer/vdr…install-vdr4arch-packages

Hallo,

ja, danke ! Da ich mich aber zur Zeit mit Arch beschäftige greife ich erst mal später darauf zurück.
VDR 2.1.2 und alles andere hab ich ja von Euch, baue es aber selbst auf meiner Desktop-Maschine !

Aber ich sage immer "learnig by doing".

Ich versuche halt immer so viel wie möglich selbst herauszufinden - hat mir schon immer geholfen !
Falls ich mal nicht weiter komme, kann ich dann hier schreiben oder soll ich neu erstellen?

mfg. Bernd

Zitat von Mreimer

Wäre das Binär-Repository eventuell eine Alternative für dich?

https://github.com/CReimer/vdr…install-vdr4arch-packages

Bin zwar damit nicht gemeint aber eine Meinung habe ich trotzdem dazu.

Ich beschäftige mich schon längere Zeit mit Archlinux und dem älteren VDR-Repository von hier https://archvdr.svn.sourceforge.net/svnroot/archvdr

Da weder dieses noch das von Copperhead mir aus verschiedenen Gründen gänzlich zusagt, baue ich die Pakete so wie ich sie gerne hätte, auch selbst. Die Dateiverteilung von VDR und Plugins auf das gesamte System, wie es in beiden Fällen gehandhabt wird, ist und bleibt für mich ein "No-Go"!

Anregungen hole ich mir von da aber gerne. Prima Arbeit von Copperhead. Seahawk1986 betreibt auch einige nützliche Repository, die man für Archlinux nutzen kann. Außerdem finde ich seinen avahi-linker sehr nützlich. So habe ich mir die Medienverteilung vorgestellt. Einfach perfekt.

Keine Ahnung wozu du Anregungen willst

Vor allem erschließt sich mir nicht, was nun genau "No-Go" für dich ist.

Es steht dir natürlich frei selber zu kompilieren. Mein Hinweis war hauptsächlich deshalb, weil es für Einsteiger wenig Sinn macht sich direkt mit dem Kompilieren zu befassen. Auch mit Binär-Repository bleibt genügend was man sich aneignen muss.

Zitat von Mreimer

Vor allem erschließt sich mir nicht, was nun genau "No-Go" für dich ist.

Muss es auch nicht. Das gelesene auch zu verstehen hilft oft bei solchen Problemen.

Zitat

Vor allem erschließt sich mir nicht, was nun genau "No-Go" für dich ist.

Na ich habe es wohl verstanden und bin da ganz auf wino seiner Seite.
Ich habe auch lieber Alles an einem Ort im Home-Verzeichins des Users "vdr".
Allerdings kann man es ja nicht der Distri anhaften , sondern ist ja ein "Problem"
vom VDR bzw. der Umstellung der make-Files.
Aber der eine will es so , der Andere so..

Zitat

Wäre das Binär-Repository eventuell eine Alternative für dich?

So noch mal kurz zum Repo - Habs jetzt mal eingebunden ! Problem ist ImageMagick - die auf dem VDR
installierte Version passt nicht zu Skinnopacity und TVguide. Auf jeden Fall meckert pacman!
Beim Scraper weiß ich nicht mehr- hab ich aber auch selbst gebaut.
EPG zum Beispiel lässt sich installieren. Also wird das was nicht geht selbst gebaut !

Jetzt hab ich aber noch ein Problem bei dem ich nicht weiter komme ! Mache dafür einen Thread auf.

mfg. Bernd

Wo die Konfigurationsdateien liegen, entscheidet doch der Distributor.
Wenn einem das nicht gefällt, muss man eben eine andere Distribution verwenden oder selbst eine erstellen.
Ich verstehe nicht, warum das hier ein Thema ist.

Lars.

Zitat

Naja. Ich habe die aktuelle festgesetzt. Klar mit nOpacity ist die defekt. Ich hatte eigentlich schneller mit einem Fix gerechnet.

Hab mir das auch gedacht - aber ich kann mit deiner "Guten Vorarbeit Super Leben" und wenn das
mal gefixt ist kann ich ja wieder vom Repo beziehen!

Noch mal vielen Dank für den Ferrari - aaah VDR

Macht schon Spaß und die Baustellen schließe ich mit der Zeit schon !

Bernd

Graphicsmagick ist wohl definitiv der richtige Weg.

Imagemagick ist ja ganz praktisch, aber mir scheint es so, als wäre es am besten, sich auf Verwendung der bei Imagemagick mitgelieferten Tools zu beschränken. Es ist wohl keine gute Idee gegen deren Libraries zu binden. Das zeigt sich schon dadurch, dass man dagegen gelinkte Programme mit fast jedem Release von Imagemagick neu bauen muss.

Vermutlich wäre das einen eigenen Thread wert, ich werfe aber trotzdem mal ein paar Erkenntnisse hier ein.

Zunächst empfiehlt man bei Imagemagick.org für "C" die Verwendung der "MagickWand"-API. Dazu zwei Fragen: Verwendet nopacity und tvguide diese API (die wohl am ehesten für "externe Programme" gedacht ist) oder doch die "MagickCore"-API, die von Imagemagick für deren eigene Verwendung gedacht ist? Bleibt natürlich die Frage: Ist "MagickWand" wirklich stabiler, bzw. so stabil, dass man nicht jedes darauf basierende Programm alle Nase lang neu bauen muss?

Bei nopacity ist wohl ein einziges Feature dafür verantwortlich, dass auf Imagemagick bestanden wird. Und zwar die "sparseColor"-Funktion. Hier ist die Preisfrage, ob man dieses nicht, ggf. über mehrere Schritte, auch mit GraphicsMagick umsetzen kann. Die Funktion ist nur an zwei Stellen im Einsatz und alles was sie macht sind einfache Farbverläufe! Würde mich doch stark wundern wenn sowas nicht auch auf anderem Wege zu erreichen wäre. Wo findet man denn in nopacity solche Effekte?

Und zuletzt noch ein Fund aus einer anderen Ecke:
http://lists.xastir.org/piperm…/2010-January/002919.html

Moin,

da es hier um "meine" Plugins geht, gebe ich auch mal meinen Senf dazu...

Zitat von Mreimer

Zunächst empfiehlt man bei Imagemagick.org für "C" die Verwendung der "MagickWand"-API. Dazu zwei Fragen: Verwendet nopacity und tvguide diese API (die wohl am ehesten für "externe Programme" gedacht ist) oder doch die "MagickCore"-API, die von Imagemagick für deren eigene Verwendung gedacht ist? Bleibt natürlich die Frage: Ist "MagickWand" wirklich stabiler, bzw. so stabil, dass man nicht jedes darauf basierende Programm alle Nase lang neu bauen muss?

Ich verwende die MagickCore API. MagickWand habe ich mir noch nicht angeschaut.

Zitat von Mreimer

Bei nopacity ist wohl ein einziges Feature dafür verantwortlich, dass auf Imagemagick bestanden wird. Und zwar die "sparseColor"-Funktion. Hier ist die Preisfrage, ob man dieses nicht, ggf. über mehrere Schritte, auch mit GraphicsMagick umsetzen kann. Die Funktion ist nur an zwei Stellen im Einsatz und alles was sie macht sind einfache Farbverläufe! Würde mich doch stark wundern wenn sowas nicht auch auf anderem Wege zu erreichen wäre. Wo findet man denn in nopacity solche Effekte?

Ich verwende ImageMagick zum einen für das Laden und konvertieren der ganzen externen Graphiken, das könnte wohl problemlos durch GraphicksMagick ersetzt werden...zum anderen verwende ich es, um mit der angesprochenen "sparseColor" Funktion die Hintergrundgraphiken on the fly aus vordefinierten Theme Farben zu erzeugen. Das wird bei allen "blending" Themes benutzt (darkred, darkgrey, ...). Beim "freestyle" Theme werden fertige Graphiken für die Hintergründe und sonstigen Skin Elemente benutzt, hierbei wird die SparseColor Funktion nicht benutzt, ebenso nicht bei den Flat Themes, bei denen es ja eh keine Farbverläufe gibt. Für den tvguide gilt das selbe (wobei es da das freestyle Theme (noch) nicht gibt).

Ich sehe zwei Möglichkeiten, um auf ImageMagick verzichten zu können: entweder ich schmeisse die "blended" Themes ganz raus, prinzipiell könnten die ja auch durch "freestyle" Themes ersetzt werden, wenn jemand die Themes mit Graphiken nachbauen würde. Oder es gäbe ohne die SparseColor Funktion die Möglichkeit, einen ähnlichen Effekt zu erzeugen wie aktuell mit ImageMagick und der SparseColor Funktion.

Generell habe ich keinen Druck, "meine" Distribution (Gentoo) benutzt nicht immer gleich die neueste "stable" Version von ImageMagick...da scheint ArchLinux ein bisschen zu forsch zu sein. Ich sehe aber schon das generelle Problem mit ImageMagick, wenn also jemand eine vernünftige Alternative bietet, bin ich gerne bereit umzustellen.

Vielleicht sollte ein Mod dieses Thema (wie schon von Mreimer vorgeschlagen) aus dem Thread heraustrennen, hat ja nicht wirklich was mit Copperheads VDR4Arch zu tun...

Ciao Louis

Zitat von louis

Moin,
Ich verwende die MagickCore API. MagickWand habe ich mir noch nicht angeschaut.

Wie schon angedeutet ist die Frage, ob "MagickWand" wirklich besser ist.

Wenn man mal über die Paketliste bei Archlinux läuft, dann findet sich dort auch das eine oder andere "Rebuild" zeitgleich zum Imagemagick-Release. Die haben also wohl auch das Problem. Wenn man als "kleiner Bastler" aber nicht ständig seine Pakete neu bauen will, dann muss etwas mit stabiler API her.

Zitat

Ich sehe zwei Möglichkeiten, um auf ImageMagick verzichten zu können: entweder ich schmeisse die "blended" Themes ganz raus, prinzipiell könnten die ja auch durch "freestyle" Themes ersetzt werden, wenn jemand die Themes mit Graphiken nachbauen würde. Oder es gäbe ohne die SparseColor Funktion die Möglichkeit, einen ähnlichen Effekt zu erzeugen wie aktuell mit ImageMagick und der SparseColor Funktion.

Hilft dir das was:
http://www.imagemagick.org/Usage/canvas/#sparse_blur

Ich wollte mich eigentlich selber dran versuchen, aber da du in dem Thema tiefer drin bist, kannst du wahrscheinlich schneller eine Aussage treffen ob diese Lösung eine Alternative ist.

Zitat von Mreimer

Hilft dir das was:
http://www.imagemagick.org/Usage/canvas/#sparse_blur

Ich wollte mich eigentlich selber dran versuchen, aber da du in dem Thema tiefer drin bist, kannst du wahrscheinlich schneller eine Aussage treffen ob diese Lösung eine Alternative ist.

Hm...keine Ahnung ob man damit etwas ähnliches bauen könnte. Die MagickCore API ist auch so besch**** dokumentiert, dass das (zumindest bei mir) immer ein ziemlich planloses rumgeeiere ist. Ich war froh, das überhaupt so irgendwie hinzubekommen. Aber wenn du das mal testen willst, sehr gerne Dazu musst du im nOpacity Code gar nicht tief drinn sein, du must lediglich die Funktion

void cImageMagickWrapper::CreateBackground(tColor back, tColor blend, int width, int height, bool mirror)

in der Datei imagemagickwrapper.c ab Zeile 90 anpassen, die erzeugt die Hintergrundbilder. Du musst an keiner anderen Stelle Code anfassen. Die Funktion CreateBackgroundReverse arbeitet sehr ähnlich, wenn die erste Funktion passt, sollte das dann auch kein Problem sein.

Ciao Louis