Beiträge von olebowle

    fc-list |grep VDROpen

    Der Befehl findet nix, da ja nur OpenSans* installiert ist. Es wurde ja aber konfiguriert, um als Ersatz zu dienen.


    In vdr4arch wird momentan VDROpen Sans durch Open Sans mittels 99-skindesigner.conf ersetzt (bzw. als alias konfiguriert). Das eigentliche Ersetzen im Skin klappt auch, allerdings meckert skindesigner beim Cachen (cFontManager::CacheFonts), dass es die VDROpen Sans Fonts nicht gäbe (nachfolgende Ausgabe kommt 288 mal):

    Code
    "skindesigner: font VDROpen Sans Light:Light not available, skipping"


    Fc-match funktioniert allerdings wie erwartet.

    Code
    $ fc-match 'VDROpen Sans Light:Light'
    OpenSans-Light.ttf: "Open Sans" "Light"


    Soweit ich das sehe benutzt skindesigner hierbei auch nur die Core Funktionalität vom vdr, in dem Fall cFont::GetAvailableFontNames(). Auch bei folgendem Aufruf wird VDROpen Sans nicht angezeigt. Es scheint mir, als würde FcFontList() aus fontconfig die aliase nicht auflösen.


    Wie kann man das am besten lösen? Wenn das eher nach VDR Core passt, bitte verschieben.

    Der E-Mail Kontakt mit DVBSky ist allerdings auch sehr bescheiden. Oftmals bekommt man gar keine Antwort. Das letzte Mal habe ich Max einen Patch zukommen lassen, der die C2800E wieder in das aktuelle Treiberpaket integriert. Dazu habe ich weder eine Antwort bekommen, noch wurde der Patch aufgenommen.

    Wird vom Kernel bei den Hybrid auch wirklich der dvb-c Teil im mainline unterstützt? Weil der bedingte meines Wissens nach wie gesagt immer closed src Module...

    Ich habe keine persönliche Erfahrung mit den Hybriden von DVBSky. Das ist der entscheidende Commit, in dem explizit angesprochen wird, dass von den Objectfile abgeguckt wurde und dass das von Herstellerseite auch ok ist. Für eine Bestätigung eines Nutzers dieser Karten wäre ich auch dankbar.


    Gibt es eigentlich grundsätzlich eine Empfehlung, ob PCI(e) oder USB besser ist?
    Auf mich wirkt so eine Steckkarte ja irgendwie... vertrauenserweckender.

    Gefühlt würde ich PCI(e) Karten auch bevorzugen.

    Falls es jemanden interessiert: Ich hab es jetzt folgendermaßen mit einem systemd Timer gelöst.


    Der Timer läuft jetzt alle 10 Minuten. Durch das Persistent=true wird das Skript unverzüglich nach Start des vdr ausgeführt, wenn der Rechner länger als 10 Minuten aus war. Somit wird der customtoken Wert in den meisten Fällen direkt am Start zur Verfügung gestellt.

    Hallo louis,


    soweit ich das sehe kann man customtokens ja nur per svdrpsend/dbus2vdr setzen. Da du ja ohnehin schon <vdrlibdir>/plugins/skindesigner/scripts/{vdrstats,temperatures} ausführst und die Werte aus <OUTPUTFLDR>/vdr{cpu,mem} einliest, könnte man nicht noch eine Datei pro customtoken im Ordner <OUTPUTFLDR>/customtokens/ anlegen, die der Skindesigner zur Verfügung stellt? Das Skript, welches diese Dateien erzeugt (z.B. <vdrlibdir>/plugins/skindesigner/scripts/customtokens) könnte dann immer gerufen werden, wenn customtokens ersetzt werden sollen.


    In maz Fall würde es dann also folgendermaßen ausschauen:


    Ich finde das jetzige Verhalten insofern suboptimal, als dass die Tokens nicht sofort nach Start des vdr zur Verfügung stehen, sondern erst wenn der cronjob wieder durchgelaufen ist. Man könnte das mit systemd sicherlich hintricksen, aber ich wollte erstmal deine Meinung dazu Einholen.

    Ich wollte gerade einmal testen, ob ich das Gefühl empirisch bestätigen kann. Allerdings gibt es jetzt bei mir mit ffmpeg 2.6.3 keine Artifakte mehr - also sowohl mit, als auch ohne Workaround. In der Zwischenzeit wurde bei Arch aber auch an den config flags gedreht, wobei das laut commit message nur die Vorgabewerte betraf: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/ffmpeg&id=09be7451cd235d0e7e8ef22f6d745eeeae4414cf.


    Kann jemand das Verhalten mit ffmpeg>2.6.2 bestätigen?

    Gehe ich recht in der Annahme, dass ein Skin ausschließlich aktualisiert wird, wenn man es im Menü manuell anstößt? Ich habe die Schrift bei shady à la https://raw.githubusercontent.…dy-use-opensans-font.diff angepasst und hätte auch gerne, dass das so bleibt.


    Könntest du das XML-File nicht evtl online zum Download aus dem Skindesigner zur Verfügung stellen (Skins können ja eh geladen werden, also warum nicht auch die Skin-Liste?).


    Auch hierbei wäre es mir lieb, wenn das Aktualisieren der Liste der verfügbaren Skins nicht bei jedem Start des Plugins geschehen würde, sondern meinetwegen erst wenn man ins Menü des Plugins geht bzw. manuell auf Knopfdruck in diesem Menü.

    Asus hat mit zwei Braswell mATX Motherboards nachgelegt. Jeweils zwei PCIe 2.0 x1 und ein PCIe 2.0 x16 (angebunden über nur eine Lane) klingt vielversprechend. S/PDIF fehlt mir persönlich. Da muss man sich wohl etwas anderes einfallen lassen.


    Quelle: heise

    Ich weiß zwar immer noch nicht, welches Archiv du genau nimmst, aber build_x64.sh aus media_build-bst-14-141106 sollte sit2_op.o an die richtige Stelle kopieren und dann sogar eigenständig bauen.

    Bash
    #!/bin/bash
    
    
    cp ./v4l/sit2_op.o.x64 ./v4l/sit2_op.o
    cp ./v4l/sit2_mod.dvb ./linux/drivers/media/dvb-frontends/sit2_mod.c
    make


    Verwendest du ein anderes Skript oder ein anderes Archiv?