Posts by nobanzai

    Also ich habe keinerlei Probleme mit den Intel Audio Treibern.
    Folgend snd_* Module sind bei mir geladen:

    pulseaudio scheint im Spiel zu sein:

    Und dein VDR läuft auch als "vdr"?

    Hi,

    ich bekomme immer folgende Meldungen auf einem meiner VDRs:

    tvscraper: Channel S19.2E-1-1012-6388 is not availible, skipping. Most likely this channel does not exist. To get rid of this message, goto tvscraper settings and edit the channel list.
    tvscraper: Channel S19.2E-1-1107-17503 is not availible, skipping. Most likely this channel does not exist. To get rid of this message, goto tvscraper settings and edit the channel list.
    tvscraper: Channel S19.2E-1-1201-28385 is not availible, skipping. Most likely this channel does not exist. To get rid of this message, goto tvscraper settings and edit the channel list.

    Seltsamerweise ist keiner dieser Channel in der Channelmap von tvscraper oder der channels.conf von vdr drin.
    Wo kommen denn dann diese Meldungen her?

    Danke und ciao.
    Michael.

    Die Einstellung KBUILD_MODPOST_WARN=0 ins Makefile des dddvb-0.9.39 (Git) schreiben vor dem make, und dann "make KERNEL_DVB_CORE=y" ausführen, dasselbe nochmal mit "install" am Ende.

    Hat jedenfalls hier funktioniert, mit aktuellem heruntergeladenem Kernel.

    Zwei Sachen:

    1. Wieso = 0? Ist das noch ein alter Compiler? Weil = 0 bedeutet ja bei neueren Compilern, dass sie die Warnung standardmäßig als error betrachten und rausknallen. Oder versteh ich das falsch?
    2. "KBUILD_MODPOST_WARN=0 make" geht nicht?

    Hi,

    als ich vor ca. 20 Jahren mit vdr begann, musste ich immer media drivers extra installieren. Irgendwann bin ich dazu übergegangen die Kernel Treiber zu nutzen. Gibt es aktuell eine besser gepflegte Quelle für Media Treiber?

    Ich glaube nicht, dass es eine wirkliche Notwendigkeit gibt, irgendwelche DVB-Treiber außer denen für die S2-6400 noch von woanders zu holen.

    Alle meine Karten, egal ob USB oder PCI(-E) laufen mit den Standard-Treibern im Kernel ohne Probleme.

    Ciao.
    Michael.

    Hi *,

    danke für Eure Antworten.
    Ich habe das jetzt auch mal mit getrennten repos für vdr und jedes plugin versucht - klappt bisher gut.
    Und weil ich (sinnig oder nicht) dazu neige, aus meinen Erkenntnissen immer direkt mördermäßige Scripten zu schnitzen, habe ich das hier auch getan. Ich hänge das Teil mal an - vielleicht besteht ja Interesse. Beschimpfungen, Fragen, Wünsche und Anregungen nehme ich gerne an ;)

    Das Script läuft sowohl für einen git server im lokalen Netz als auch für dahinter hängende clients. Es existiert daher einmal als "vdrgitprep" (server) und einmal als Link (oder Kopie) mit dem Namen "vdrgitbranch" (client).
    Für jeden client wird ein config file mit dem Namen des client definiert, das pro plugin für diesen client eine Zeile enthält (<plugin name>=<git url>). Die config files liegen unter <basedir>/vdr/PLUGINS/config. Irgendwann soll es noch <plugin name_post> Einträge in der config geben, über die nach dem Holen des repo ein Script definiert werden kann, das irgendwelche Nacharbeiten macht.
    Im initialen Lauf holt das Script am server den vdr (nach <basedir>/vdr/vdr) und die per config file definierten plugins (nach <basedir>/vdr/PLUGINS/src) aus ihren jeweiligen repos. Liegen für den vdr patches in <basedir>/vdr/patches vor, wird versucht, diese im passenden level per git patch einzufügen. Darüber hinaus werden alle Standardplugins bis auf skincurses und status gelöscht (das kann man aber auch gerne optional machen). Das Script verlinkt dann die plugin repo Verzeichnisse in das <basedir>/vdr/vdr/PLUGINS/src Verzeichnis.
    Danach wird für jeden client ein branch angelegt, in dem alle o.a. Links gelöscht werden, deren zugehörige plugins nicht für diesen client konfiguriert wurden.
    Ein client kann dann genau diesen branch samt aller verlinkten plugins abholen. Die Verzeichnisstruktur am client sieht genauso aus wie am server.
    Der make kann dann in <basedir>/vdr/vdr gestartet werden.
    In weiteren Läufen des Scripts sowohl am server wie an den clients wird nur noch geprüft, ob es neuere Versionen des vdr oder irgendwelcher plugins gibt und diese dann ggf. gemerged. Das Script kann also beliebig oft laufen, ohne weitere Aktionen manuell machen zu müssen.
    Wird ein plugin für einen oder alle clients aus den jeweiligen configs entfernt, werden auch die entsprechenden links aus allen client branches und/oder dem master entfernt. Die client repo Verzeichnisse bleiben derzeit am server und auch an den clients bestehen.

    ACHTUNG: Ich habe bisher nicht getestet, wie sich das Script verhält, wenn man dazwischen manuell etwas an den repos macht. Generell ist das eigentlich auch nicht für Entwickler gedacht, sondern für Nasen wie mich, die mit nur minimalem Aufwand immer die neuesten Versionen holen und dann übersetzen wollen.

    Ciao.
    Michael.

    Im Prinzip ist es auch durchaus machbar ein Submodule wieder rauszuhauen. Hatte da bisher keine Probleme mit. Zum Entwickeln ist das durchaus eine praktische Lösung das eigene Plugin-Repo (oder die Repos) als Submodul direkt in den VDR-Tree zu hängen.

    Da habe ich es nicht geschafft, branches zu erstellen.

    Meine Idee war ein lokales Repo auf einem lokalen Server mit dem vdr und allen plugins und davon dann branches für jeden eigentlichen vdr, die bei mir ja alle verschiedene plugins nutzen. Dann hätte ich auf einem vdr host nur den branch mit seinem Namen gecloned.
    Leider habe ich es nicht geschafft, submodule zu branchen - und wenn ich die Doku recht verstanden habe, geht das auch nicht.

    Hi *,

    nachdem ich mich über die Feiertage endlich mal dem Thema git ein wenig weiter nähern konnte, hatte ich direkt überlegt, auch bzgl. vdr und seinen plugins alles mit git zu machen.
    Dabei sind natürlich direkt Fragen aufgekommen.

    Ich hatte so die Idee, das vdr Repo als sog. superproject zu clonen und dann die plugins als submodules hinzuzufügen.
    Das klappt zwar, wirft aber einige Probleme auf, z.B. wenn man ein plugin nicht mehr haben will, weil das Entfernen eines submodules - naja sagen wir - eine grenzwertige Aktion ist.

    Daher die folgenden Fragen:

    • Nutzt jemand von euch submodules für sowas? Und wenn ja, wie?
    • Und wenn nein, habt ihr euch bewusst dagegen entschieden? Wenn ja, warum?
    • Wie macht ihr das sonst, um die plugins in euer git Repo zu holen? In eigene Verzeichnisse parallel zum vdr holen und dann ins PLUGINS/src Verzeichnis linken z.B.?

    Danke und noch schöne Feiertage.
    Michael.