[erledigt] ct´VDR 7, wo genau befindet sich die vdr binary

  • Hallo Jungs,


    erstmal ein schönes Weihnachtfest an euch alle. Hier habe ich eine kleine Weihnachtgeschichte an euch.
    Ich habe einen Arbeitskollegen, sein Name ist „Hakan Plan“ und ist ein armes Schwein. Er wohnt in einem Mehrfamilienhaus. Der Vermieter hat ihnen „zu Weichnachten“ Satanschluss geschenkt. Ich habe ihm meinen SD-VDR geschenkt. Das Gerät wurde von mir als unverkäuflich deklariert und bei ihm ist es besser aufgehoben als bei mir auf dem Boden. Es hat sich schnell herausgestellt, dass es eine Einkabellösung ist. Kein Problem, sagte ich. So zwischen Tür und Angel habe ich das Gerät mit Tobis vdr-experimental geupdatet, die 1.6.0-er Sources geladen, gepatcht und make mit install ausgeführt. Make lief ohne Fehler durch, dennoch beim vdr-Start ist die letzte Zeile im Log: Fehler in der diseqc.conf. Nebenbei, Pinschutz hat er nicht und ich habe keine Zeit, deswegen reicht 1.6.0. Meine Vermutung ist, das trotz make … install die vdr nicht in dem Verzeichnis gelandet ist, wo es in ct´vdr vorgesehen ist. Soweit war ich gestern und dann musste ich wegen W die Sache schleunigst beenden!


    Also, wenn jemand wüsste, wo genau in ct´VDR 7 die vdr binary sich befindet, könnte meine Arbeitkollege als Weihnachtsgeschenk schon mal glotzen und ich hätte die Sache vom Hals.


    Vielen Dank im Voraus.


    Albert

    Einmal editiert, zuletzt von DaKilla ()

  • Ich führchte das einfachste ist es wenn du es gleich richtig machst ;) An der Paketverwaltung vorbeibasteln gibt nur Ärger.


    Die Quellen des VDR Pakets holen *) (apt-get source vdr), den Unicable Patch in debin/patches einfügen und das Paket per "dpkg-buildpackage -rfakeroot -sa" neu bauen. Dann das gebaute installieren. Wenn sich durch den Patch die API ändert müssen alle Plugins (die von dieser API Änderung betroffen sind) auf die selbe Weise neu gebaut werden.


    BTW: Wenn du das schonmal machst empfehe ich auch gleich noch diesne Patch: http://www.udo-richter.de/vdr/…to-compatibility-0.1.diff (damit kann der VDR dann die aktuellen Kanallisten (z.B. aus Channelpedia) lesen)


    cu


    *) Das beantwortet auch deine eigentlich Frage, hier unter debian/* steht drin wo das vdr Binary hinkopiert wird.

  • Hallo KA,


    danke für Deine Antwort. Ich war gestern mal kurz auf dem System. Die Stelle habe ich in init.d gefunden.



    Make kenne ich von früher (Kernelkompilierung, Remastering). Habe (nach Sicherung) mal kurz probiert. Fehlanzeige, war für die Katz.


    Was Du aber vorschlägst, das muss die ABI „ändern“. Vielleicht nicht den ABI Namen. Ich könnte wetten, dass wenn nur ein einziges bit in vdr geändert wird so wird lenny die schon wegen irgendwelcher hash Unterschiede bemängeln. In Umkehrschluss müsste ich eine eigene „Minidistry“ mit allen Plugins bauen. Wie also mache ich es Richtig?


    1. vdr sources laden
    2. alle verwendete Plugin-sources laden, in vdr sources PLUGINS Verzeichnis entpacken (oder lieber an separate stelle?)
    3. unicable Patch für 1.6.0 ist eine .diff Datei, wirklich in dem debin/patches Verzeichnis damit?
    4. arbeitet die channel parser mit vdr 1.6 oder 1.7.16 oder beides?
    5. compilieren und installieren
    6. apt danach tunlichst meiden?


    Dann wäre es noch zu überlegen, ob ich nicht gleich den Kernel auf 2.6.28 aktualisiere (Kernel, vlt. Modules, Treiber und Firmware auch gleich mit) und vdr auf dem Stand 1.7.16 bringe (TS-Aufnahmen und unicable mit PIN). Alternativ 2.6.32 von backports?


    Kläre mich bitte auf.


    Albert

  • Was Du aber vorschlägst, das muss die ABI „ändern“. Vielleicht nicht den ABI Namen. Ich könnte wetten, dass wenn nur ein einziges bit in vdr geändert wird so wird lenny die schon wegen irgendwelcher hash Unterschiede bemängeln. In Umkehrschluss müsste ich eine eigene „Minidistry“ mit allen Plugins bauen. Wie also mache ich es Richtig?


    Tja, richtig ist es IMHO ein eigenes Repository mit den VDR Paketen anzulegen und apt diesem die Priorität zuzuweisen. Macht anfangs etwas mehr Arbeit aber man machts so wenigstens gleich richtig.



    1. vdr sources laden


    Wie oben geschrieben
    ---
    apt-get source vdr
    apt-get build-dep vdr
    <ins vdr Unterverzeichnis wechseln>
    dpkg-buildpackage -rfakeroot -sa"
    ---
    Danach hast du die VDR Binär und Quell Pakete (die kommen später ins eigene Repository) neu gebaut (erstmal ohne was zu ändern, nur um zu sehen wie einfach sowas geht ;) ).


    Geht das VDR Packet dann unter debin/patches die Patches einfügen und das Paket nochmal bauen. Dann hast du schon das neue VDR Paket mit deinen Patches.



    Das selbe machst du dann mit allen Pluginpaketen die du nutzen willst.


    3. unicable Patch für 1.6.0 ist eine .diff Datei, wirklich in dem debin/patches Verzeichnis damit?


    Jup, so funktioniert das.


    4. arbeitet die channel parser mit vdr 1.6 oder 1.7.16 oder beides?


    Der Patch sorgt nur dafür das der 1.6er VDR das neue Kanallistenformat (wie es z.B. auf Channelpedia verbreitet wird) lesen kann. Muss nicht sein, aber es vereinfacht einiges.



    6. apt danach tunlichst meiden?


    Nein, die eigenen Pakete ins eigene Repository (schreib dir gerne Hinweise dazu wenn du soweit bist) dann kannst du das System auch weiterhin uptaten.


    Dann wäre es noch zu überlegen, ob ich nicht gleich den Kernel auf 2.6.28 aktualisiere (Kernel, vlt. Modules, Treiber und Firmware auch gleich mit) und vdr auf dem Stand 1.7.16 bringe (TS-Aufnahmen und unicable mit PIN). Alternativ 2.6.32 von backports?


    Tja, Gewissensfrage, wenn du Langewile hast dann probiere es einfach mal aus obs besser läuft.


    Den Kernel zu aktualisieren bringt nur was wenns wirklich irgendeine Verbesserung bringt. Kann auch sein das ein neuer Kernel schlechter läuft (z.B. wenn da mal wieder neue Bugs in den DVB Treibern drinne sind). Den 1.7er VDR, tja... Versuch macht klug.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!