[UPDATE vdr-experimental] vdr 1.6.0

  • Hallo,


    Quote

    Original von DrSat
    vielen Dank für Deinen Patch! Habe ihn bei mir in den vdr eingebaut und finde ihn ausgesprochen nützlich.Die Schnittpunkte zu finden geht jetzt Ruck-Zuck. Nebenwirkungen sind mit bis jetzt noch keine aufgefallen.
    Super Arbeit!


    Danke, freut mich.


    Da ich gerade so im Fluss war, habe ich auch gleich den Hard Link Cutter Patch angepasst.

    Code
    1. ## opt-52_hard_link_cutter.dpatch by udo_richter at gmx.de
    2. ## http://www.udo-richter.de/vdr/patches.html#hlcutter
    3. ##
    4. ## Frank Jepsen <vdr_at_jepsennet.de>:
    5. ## - adapted to VDR-1.6.0
    6. ##
    7. ## All lines beginning with `## DP:' are a description of the patch.
    8. ## DP: The hard link cutter patch changes the recording editing algorithms
    9. ## DP: of VDR to use filesystem hard links to 'copy' recording files whenever
    10. ## DP: possible to speed up editing recordings noticeably

    Kompilieren tat er schon mal gleich ohne Probleme. Im Setup unter Einstellungen/Aufnahme muss er aktiviert werden und die maximale Videodateigröße sollte runtergesetzt werden. (In weiser Voraussicht habe ich dies schon vor ein paar Wochen gemacht). Ich habe gerade mal ein paar Testschnitte gemacht und es scheint wunderbar zu klappen. Also schon mal Mutige vor und viel Spaß damit. ;)


    Da ich den Thread hier nicht hijacken wollte habe ich einen neuen Thread angelegt.


    Tschüß Frank

  • Bei mir funktioniert unter vdr-multipatch das director-plugin nicht mehr. Es erscheint nach drücken der zugeordneten Taste nur der Name des eingeschalteten Portal-Kanals aber nicht wie noch aus vdrdevel-1.5.x gewohnt die Optionskanäle :-(


    Das syslog gibt leider auch nichts her. Weder beim Umschalten auf den Portalkanal noch beim Drücken auf @director


    "Einstellungen > DVB > Kanäle aktualisieren" steht auf "neue Transponder"


    EDIT:
    Keine Ahnung was ich jetzt gemacht habe, aber jetzt geht es wieder, nachdem es seit Tagen nicht ging.


    Ich habe gerade mal alle Optionskanäle von Hand durchgezapt. Außerdem die Rechte der channels.conf von vdr:vdr rw-r--r-- auf rw-rw-r-- gesetzt... ???

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

    The post was edited 2 times, last by HolgerAusB ().

  • Hallo,


    noch ist für meine Patches anscheinend in der /etc/default/vdr PLUGIN_CHECK_PATCHLEVEL="no" einzutragen.


    Tobi :
    Gibt es eigentlich einen Trick Patches für Plugins als unrelevant zu kennzeichnen?


    Tschüß Frank

  • habe hier noch einen Fehler beim Starten (alle Plugins deaktiviert), werde alleine aber nicht so ganz schlau daraus - der VDR läuft.
    n.b.: Was bedeutet das "(cache miss)"?


    EDIT: es hängt mit dem live-Plugin zusammen, das sich wohl nicht wirklich in der order.conf deaktivieren lässt.
    Trage ich dort "-live" ein, so startet es nicht, aber ich erhalte den Fehler.
    Entferne ich es ganz mit apt-get remove, so kommt der Fehler nicht.



    vg, aragorn

    vdr3: yavdr-ansible | MSI B150M Mortar| Celeron 3930 | GT 630 passiv | DD Cine C/T/T2 (V7) | Noctua NH-L12 | Seasonic SS-300TGW (semi-passiv) | targavfd | Atric v5 | im Revox B-226 Gehäuse

    The post was edited 2 times, last by aragorn ().

  • Quote

    Original von FrankJepsen
    Gibt es eigentlich einen Trick Patches für Plugins als unrelevant zu kennzeichnen?


    Wenn der Patch nicht opt-NN_name.dpatch, sondern opt-<nn>-x_<patch name>.dpatch heißt, wird er nicht in den Patchlevel aufgenommen, so dass der Patchlevelcheck (PLUGIN_CHECK_PATCHLEVEL=yes) keine Probleme feststellen kann. Das steht übrigens auch in der README im Abschnitt "Optional Patches" (/usr/share/doc/vdr/README.Debian.gz).


    Bei deinen beiden Patches ist das aber keine so gute Idee. Als Faustregel gilt: Wenn der Patch Plug-in-Schnittstellen ändert, sollte er in den Patchlevel aufgenommen werden und alle Plug-ins neu übersetzt werden. Verdächtig ist immer schon, wenn *.h-Dateien gepatcht werden.


    Je nachdem was geändert wird und welche Plug-ins man verwendet, kann das natürlich auch gut gehen. Manchmal treten die Probleme aber auch nur sehr sporadisch auf, so dass man erst denkt, die Änderungen der Plug-in-Schnittstellen sind harmlos.


    Zum Beispiel fügt der hard-link-cutter-Patch zwei neue Komponenten in die cSetup-Klasse ein (config.h). Wenn nun ein Plug-in eine cSetup-Komponente direkt anspricht, die dahinter liegt, erwischt es die falsche Komponente. Die Adresse der Komponente ist ein Offset und der stimmt nicht mehr mit dem Wert überein, den er beim Übersetzen des Plug-ins hatte.


    Es ist also immer das Beste, alle Plug-ins neu zu übersetzen. So viel Arbeit ist es ja auch nicht, für jedes verwendete Plug-in "fakeroot apt-get source -b vdr-plugin-..." aufzurufen und dann die Pakete mit "sudo dpkg -i vdr-plugin*deb" zu installieren.


    Tom

  • Hallo,


    Quote

    Original von TomG
    Wenn der Patch nicht opt-NN_name.dpatch, sondern opt-<nn>-x_<patch name>.dpatch heißt, wird er nicht in den Patchlevel aufgenommen, so dass der Patchlevelcheck (PLUGIN_CHECK_PATCHLEVEL=yes) keine Probleme feststellen kann. Das steht übrigens auch in der README im Abschnitt "Optional Patches" (/usr/share/doc/vdr/README.Debian.gz).


    Danke für den Hinweis.



    Ja, das macht Sinn. In diesem Fall scheinen dahinter keine Komponenten zu sein, die von Plugins benötigt werden (oder zumindest nicht von den von mir installierten ;)).


    Ich wollte nur nicht immer nur fordern, sondern dir und Tobi mal ein bisschen zuarbeiten, in der Hoffnung, dass ihr die Patches für genauso nützlich wie ich und viele andere befindet und sie mit in eure Releases aufnimmt.


    Tschüß Frank


  • Nur leider besteht dann apt-get upgrade bei mir immer darauf die "von Hand" per dpkg installierten Pakte wieder durch die aus Tobis Rep zu ersetzen. Und um der Sache Druck zu machen weigert sich apt auch andere Sachen upzugraden bevor er hier nicht seinen Willen bekommt ;). Kann man das irgendwie abstellen wenn man sich denn entschieden hat die Sache selber zu kompilieren?


    thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Quote

    Original von gandalf
    Nur leider besteht dann apt-get upgrade bei mir immer darauf die "von Hand" per dpkg installierten Pakte wieder durch die aus Tobis Rep zu ersetzen. Und um der Sache Druck zu machen weigert sich apt auch andere Sachen upzugraden bevor er hier nicht seinen Willen bekommt ;). Kann man das irgendwie abstellen wenn man sich denn entschieden hat die Sache selber zu kompilieren?


    Sieh mal hier: Debian FAQ Abschnitt 2.6 - Wie setze ich noch mal ein Paket auf hold?

    VDR1: AMD Duron-1300, 512mb RAM, Nexus-S rev2.1, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    VDR2: Athlon XP-M-2600+, 512mb RAM, TT Prem 1.3 DVB-S, Skystar2, Airstar 2, Debian Lenny, kernel: 2.6.28-etobi.3, VDR 1.6.0-17 experimental/extensions von Tobi
    Extern: Activy300, Gen2VDR V2

  • Quote

    Originally posted by geeg07


    Sieh mal hier: Debian FAQ Abschnitt 2.6 - Wie setze ich noch mal ein Paket auf hold?


    Genau das! DANKE
    thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Quote

    Original von gandalf
    Nur leider besteht dann apt-get upgrade bei mir immer darauf die "von Hand" per dpkg installierten Pakte wieder durch die aus Tobis Rep zu ersetzen. Und um der Sache Druck zu machen weigert sich apt auch andere Sachen upzugraden bevor er hier nicht seinen Willen bekommt ;). Kann man das irgendwie abstellen wenn man sich denn entschieden hat die Sache selber zu kompilieren?


    Ich verwende immer aptitude und setze solche Pakete mit der Taste "=" auf "Hold".


    Tom


  • Und dem kann ich inzwischen nur zustimmen. Ich habe von der Neuerstellung der Plugins zunächst abgesehen und mein vdr hängt sich nun sporadisch komplett auf. Nicht mal von der Konsole kommt man mehr auf den Rechner :(
    Ich sehe mal von ner Ursachenforschung ab, da ein Wechsel auf Tobi´s Version sofort wieder einen stabilen Zustand herstellte, und werde also jetzt den langen Weg der Komplettkompilierung gehen. In dem Zusammenhang eine Frage ist dies

    Quote

    Original von TomG
    [...] "fakeroot apt-get source -b vdr-plugin-..." [...]


    bereits die volle Anleitung, und für was stehen dann insbesondere die drei '.' ;)? Keine Angst werde versuchen mich auf deinen Seiten auch ohne deine Hilfe schlauzumachen.


    [Wunsch an Tobi]
    Könntest du prüfen die beiden Patches in die Multi-Patch Variante aufzunehmen? Ist schon ne enorme Arbeitserleichterung
    [/Wunsch an Tobi]


    Und in dem Zusammenhang nochmal der Rat auf jeden Fall darauf zu achten dass in der /etc/default/vdr

    Code
    1. # Set this to load only plugins with the correct patch level
    2. PLUGIN_CHECK_PATCHLEVEL="yes"

    steht!!!
    Gruesse,
    Thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Hmm,


    Mit den Anregungen auf Tobis Seite und im Wiki habe ich kein Glück, die erzeugten plugins werden noch immer rejected beim vdr start. Ich habe es mit

    Code
    1. fakeroot apt-get source -b vdr-plugin-remote


    einmal unter /usr/src direkt, einmal unter /usr/src/vdr-1.6.0/PLUGINS/src versucht, die Erzeugung lief auch durch, alleine das erzeugte, und installierte, Paket wurde auch vom selbst-erzeugten vdr mit Franks patches zurückgewiesen :) Was mache ich falsch, bzw. wie bringe ich das plugin auf denselben Patchlevel?


    Thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Quote

    Original von gandalf
    Mit den Anregungen auf Tobis Seite und im Wiki habe ich kein Glück, die erzeugten plugins werden noch immer rejected beim vdr start. Ich habe es mit

    Code
    1. fakeroot apt-get source -b vdr-plugin-remote


    einmal unter /usr/src direkt, einmal unter /usr/src/vdr-1.6.0/PLUGINS/src versucht, die Erzeugung lief auch durch, alleine das erzeugte, und installierte, Paket wurde auch vom selbst-erzeugten vdr mit Franks patches zurückgewiesen :) Was mache ich falsch, bzw. wie bringe ich das plugin auf denselben Patchlevel?


    Was ... bedeutet, hast du anscheinend inzwischen rausbekommen. ;)


    Ich vermute, das Problem liegt darin, dass du nach dem Übersetzen des VDR-Pakets vdr-dev installieren musst ("dpkg -i vdr-dev").


    Die Plugins verwenden die Schnittstellen (*.h-Dateien) des installierten vdr-dev und erhalten deshalb auch genau den Patchlevel dieses vdr-dev-Pakets. Die Patchlevels der installierten Pakete werden übrigens mit "dpkg -s <paktname>" angezeigt.


    Tom

  • Quote

    Original von FrankJepsen
    Ich wollte nur nicht immer nur fordern, sondern dir und Tobi mal ein bisschen zuarbeiten, in der Hoffnung, dass ihr die Patches für genauso nützlich wie ich und viele andere befindet und sie mit in eure Releases aufnimmt.


    Über Mitarbeit freuen wir uns immer. :) Ich will mir die Patches auch ansehen, hab nur zur Zeit mit anderen Problemen zu kämpfen.


    Wenn sich der Hard-Link-Cutter-Patch wirklich vollständig(!) abschalten lässt, spricht eigentlich nichts dagegen, ihn einzubauen und im Multipatch zu aktivieren.


    Beim Edit-Marks-Patch stört mich, dass er viele Tasten umdefiniert. Wenn man sich daran gewöhnt hat, dass Grün und Gelb eine Minute springen, muss man sich ziemlich umgewöhnen, wenn das nicht mehr stimmt. Der Patch macht einige Tastenmanipulationen des liemikuutio-Patches wieder rückgängig und führt neue ein. Das heißt, es ist sehr wahrscheinlich, dass er beim nächsten liemikuutio-Patch nicht mehr passt. Die bessere Lösung wäre, wenn Rolf diesen Patch in den liemikuutio-Patch einbaut. Hat schon jemand versucht, ihm den Patch schmackhaft zu machen?


    Tom

  • Hallo,

    Quote

    Original von TomG
    Über Mitarbeit freuen wir uns immer. :) Ich will mir die Patches auch ansehen, hab nur zur Zeit mit anderen Problemen zu kämpfen.


    Wenn sich der Hard-Link-Cutter-Patch wirklich vollständig(!) abschalten lässt, spricht eigentlich nichts dagegen, ihn einzubauen und im Multipatch zu aktivieren.


    Das wäre natürlich das beste.


    Quote


    Beim Edit-Marks-Patch stört mich, dass er viele Tasten umdefiniert. Wenn man sich daran gewöhnt hat, dass Grün und Gelb eine Minute springen, muss man sich ziemlich umgewöhnen, wenn das nicht mehr stimmt. Der Patch macht einige Tastenmanipulationen des liemikuutio-Patches wieder rückgängig und führt neue ein. Das heißt, es ist sehr wahrscheinlich, dass er beim nächsten liemikuutio-Patch nicht mehr passt. Die bessere Lösung wäre, wenn Rolf diesen Patch in den liemikuutio-Patch einbaut. Hat schon jemand versucht, ihm den Patch schmackhaft zu machen?


    Tom


    Habe ich auch schon dran gedacht. Aber es ist etwas schwer an ihn ranzukommen. Ich habe weder hier im Portal noch auf der Mailinglist einen Ankündigungsthread für den aktuellen Patch gefunden. Ich habe auch gesehen das es mit der Sprungtastenbelegung einiges hin und her gegeben hat. Erst war grün/gelb mit der binären Sprunggeschichte belegt, dann hat er wieder andere Tasten genommen, die aber nicht auf jeder Fernbedienung drauf sind. Den 20s Sprung hat er auch mehrmals rein und rausgenommen. Wofür man jetzt drei verschiedene Sprungtastenkombinationen brauchen soll, leuchtet mir nicht ein. Gelb/Grün mit +/-60 Sekunden und bei Richtungsänderung halbierter Schrittweite 30,15,7 Sekunden wäre kompatibel und deckt alles ab. Leider weiß ich nicht auf welche Zurufe er da reagiert, denn in der Mailinglist les ich nicht so oft mit und hier ist er anscheinend nicht vertreten.


    Wichtig war mir vor allem das stoppen beim Schnittmarke setzen und das Schnittmarke schieben um +/-5 Sekunden.


    Deshalb habe ich erstmal einen eigenen Patch gemacht und da dieser ja mit Sicherheit den Patchlevel nicht verändert kann man ihn auch nachträglich schnell reinkompilieren. Ich muss ihn nur mal opt-21_x_edit_marks.dpatch nennen.


    Tschüß Frank

  • Quote

    Original von TomG


    Was ... bedeutet, hast du anscheinend inzwischen rausbekommen. ;)


    In der Tat ;)


    Quote

    Original von TomG


    Ich vermute, das Problem liegt darin, dass du nach dem Übersetzen des VDR-Pakets vdr-dev installieren musst ("dpkg -i vdr-dev").


    Gut geraten, du kennst deine Pappenheimer


    Quote

    Original von TomG
    Die Patchlevels der installierten Pakete werden übrigens mit "dpkg -s <paktname>" angezeigt.
    Tom


    Wieder was gelernt. Leider habe ich wohl kein Glück. Ich habe alles durch den Compiler gedreht, keine Beschwerden. Alles über dpkg -i installiert und den vdr gestartet. Soweit so gut. Ausgabe über xineliboutput lief schonmal nicht, Ausgabe im log:


    Bei Drücken der "Menu" Taste dann der VDR restart.


    Habe keine Idee was das soll, merke aber natürlich dass wir vom Thema des Threads abweichen!


    Hab also wieder zurückgedreht!


    Irgendwelche Ideen?


    Gruss,
    Thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Quote

    Original von FrankJepsen
    Habe ich auch schon dran gedacht. Aber es ist etwas schwer an ihn ranzukommen. Ich habe weder hier im Portal noch auf der Mailinglist einen Ankündigungsthread für den aktuellen Patch gefunden. Ich habe auch gesehen das es mit der Sprungtastenbelegung einiges hin und her gegeben hat. Erst war grün/gelb mit der binären Sprunggeschichte belegt, dann hat er wieder andere Tasten genommen, die aber nicht auf jeder Fernbedienung drauf sind. Den 20s Sprung hat er auch mehrmals rein und rausgenommen. Wofür man jetzt drei verschiedene Sprungtastenkombinationen brauchen soll, leuchtet mir nicht ein. Gelb/Grün mit +/-60 Sekunden und bei Richtungsänderung halbierter Schrittweite 30,15,7 Sekunden wäre kompatibel und deckt alles ab. Leider weiß ich nicht auf welche Zurufe er da reagiert, denn in der Mailinglist les ich nicht so oft mit und hier ist er anscheinend nicht vertreten.


    Doch, ist er, unter dem Namen rofafor. Aber besser ist sicher per Mail, seine Mailadresse steht ja in den READMEs seiner Plug-ins.


    Alle Änderungen der Tastenkombinationen kamen von verschiedenen Patches, die er in den liemikuutio aufgenommen bzw. wieder entfernt hat. Anscheinend sucht er auch noch nach dem besten Patch.


    Quote

    Wichtig war mir vor allem das stoppen beim Schnittmarke setzen und das Schnittmarke schieben um +/-5 Sekunden.


    Deshalb habe ich erstmal einen eigenen Patch gemacht und da dieser ja mit Sicherheit den Patchlevel nicht verändert kann man ihn auch nachträglich schnell reinkompilieren. Ich muss ihn nur mal opt-21_x_edit_marks.dpatch nennen.


    Soweit ich mich erinnere, bekommt eine Methode einen zusätzlichen Parameter. Der Patch sollte also auf jeden Fall in den Patchlevel. Übrigens muss das Zeichen vor dem 'x' ein '-' sein. opt-21_x_edit_marks.dpatch wäre ein Patch, der als 'x_edit_marks' in den Patchlevel aufgenommen wird.


    Tom

  • Quote

    Original von gandalf
    Ausgabe über xineliboutput lief schonmal nicht


    Mit xineliboutput kenne ich mich nicht aus.


    Werden denn jetzt wenigstens die richtigen Patchlevel angezeigt, wenn du die Pakete mit "dpkg -s <paktname>" durchgehst?


    Quote

    Irgendwelche Ideen?


    Nicht wirklich. Es könnte sein, dass du beim Selbstübersetzen andere Libraries verwendest. Ist das ein Etch-System?


    Tom

  • Quote

    Original von TomG


    Mit xineliboutput kenne ich mich nicht aus.


    Werden denn jetzt wenigstens die richtigen Patchlevel angezeigt, wenn du die Pakete mit "dpkg -s <paktname>" durchgehst?


    "Lustigerweise" hat das selbst erzeugte Paket vdr überhaupt keinen patch level, erstaunlich. Installiere ich wieder das von dir erzeugte Paket dann bringt "dpkg -s vdr" eine Liste von Namen.


    Ich denke das hängt hiermit zusammen


    Das einzige was im vorangehenden Ablauf vielleicht auffällig ist ist:

    Code
    1. I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
    2. debian/vdrdbg-buildpackage.1.xml:18: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"


    Ein vdr Start ergibt die folgenden zu ladenden Plugins:

    Code
    1. vdr1:~# /etc/init.d/vdr start
    2. Starting Linux Video Disk Recorder: vdr
    3. Searching for plugins (VDR 1.6.0-1/1.6.0) (cache hit): live skinenigmang mplayer dvd dvdswitch femon epgsearchonly osdteletext undelete tvonscreen streamdev-server screenshot conflictcheckonly skinsoppalusikka text2skin quickepgsearch epgsearch remote menuorg sysinfo newsticker timeline xineliboutput mp3
    4. WARNING: The following plugins have been left out due to possible binary incompatibility: wirbelscan.


    Den Patchlevel:

    Code
    1. Vdr-Patchlevel: liemikuutio jumpplay ttxtsubs audioindexer syncearly-audioindexer disableDoubleEpgEntrys noepg iptv rotor yaepg sourcecaps graphtft cuttime

    haben:

    • skinenigmang
    • mplayer
    • dvd
    • dvdswitch
    • femon
    • osdteletext
    • tvonscreen
    • skinsoppalusikka
    • text2skin
    • remote
    • menuorg
    • sysinfo
    • newsticker
    • timeline
    • xineliboutput
    • mp3


    Keinen Patchlevel haben der vdr selbst sowie die plugins:

    • live
    • epgsearch
    • undelete
    • streamdev-server
    • screenshot


    Plugin wirbelscan hat zwar den korrekten patchlevel wird aber wegen was, ach ja, "due to possible binary incompatibility" nicht geladen.


    Quote

    Nicht wirklich. Es könnte sein, dass du beim Selbstübersetzen andere Libraries verwendest. Ist das ein Etch-System?


    Tom


    Ja, Etch.


    Sehr merkwürdig...
    Thorsten

    --------------------------------------------------------------------------
    HW: AMD Athlon(tm) 7850, 2 GB RAM, Gainward G210 (NVidia GF 210), nvidia 195.36.31, 640+750GB internal HD, 1TB +(2*1TB) NAS (WD My Book World Edition I&II), Hauppauge FF Rev. 2.1, Budget: AVerTV DVB-T 771, WinTV HVR-4000 DVB-S(2)
    VDR: 1.7.15, Plugins: xineliboutput osdteletext dvbsddevice epgsearch streamdev-server vnsiserver skinsoppalusikka tvonscreen live fritzbox menuorg externalplayer dvd text2skin

  • Quote

    Original von gandalf
    "Lustigerweise" hat das selbst erzeugte Paket vdr überhaupt keinen patch level, erstaunlich.


    Das liegt daran, dass du die Datei debian/patches/00list nicht angepasst hast. Im Sourcepaket liegt sie immer so, wie sie für das Standard-Paket benutzt wird. Das heißt, von den optionalen Patches sind gar keine aktiviert.


    Du musst also 00list editieren, indem du bei allen Patches, die aktiv sein sollen, das Kommentarzeichen entfernst. Zusätzlich musst du noch die beiden neuen Patches eintragen.


    Oder du lädst dir die 00list-Datei runter, die Tobi beim Erstellen der Multipatch-Pakete verwendet hat:
    http://www.e-tobi.net/vdr-expe…chlists/multipatch.00list
    kopierst sie als 00list nach debian/patches/ und fügst die beiden neuen Patches hinzu.


    Tom