[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.

## opt-52_hard_link_cutter.dpatch by udo_richter at gmx.de
## http://www.udo-richter.de/vdr/patches.html#hlcutter
##
## Frank Jepsen <vdr_at_jepsennet.de>:
##   - adapted to VDR-1.6.0
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: The hard link cutter patch changes the recording editing algorithms
## DP: of VDR to use filesystem hard links to 'copy' recording files whenever
## 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... ???

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.

Starting Linux Video Disk Recorder: vdr
Searching for plugins (VDR 1.6.0-1/1.6.0) (cache miss):*** glibc detected *** /usr/bin/vdr: double free or corruption (!prev): 0x00000000007560c0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2ad971bd401d]
/lib/libc.so.6(cfree+0x76)[0x2ad971bd5d26]
/usr/lib/libcxxtools.so.5[0x2ad97812b95f]
/lib/libc.so.6(__cxa_finalize+0x85)[0x2ad971b98f75]
/usr/lib/libcxxtools.so.5[0x2ad978118b93]
======= Memory map: ========
00400000-0053b000 r-xp 00000000 08:01 278324                             /usr/bin/vdr
0073a000-0073d000 rw-p 0013a000 08:01 278324                             /usr/bin/vdr
0073d000-0076c000 rw-p 0073d000 00:00 0                                  [heap]
2ad9703a9000-2ad9703c4000 r-xp 00000000 08:01 91152                      /lib/ld-2.7.so
2ad9703c4000-2ad9703c7000 rw-p 2ad9703c4000 00:00 0
2ad9705c3000-2ad9705c5000 rw-p 0001a000 08:01 91152                      /lib/ld-2.7.so
2ad9705c5000-2ad9705e6000 r-xp 00000000 08:01 20918                      /usr/lib/libjpeg.so.62.0.0
2ad9705e6000-2ad9707e6000 ---p 00021000 08:01 20918                      /usr/lib/libjpeg.so.62.0.0
2ad9707e6000-2ad9707e7000 rw-p 00021000 08:01 20918                      /usr/lib/libjpeg.so.62.0.0
2ad9707e7000-2ad9707fd000 r-xp 00000000 08:01 91169                      /lib/libpthread-2.7.so
2ad9707fd000-2ad9709fc000 ---p 00016000 08:01 91169                      /lib/libpthread-2.7.so
2ad9709fc000-2ad9709fe000 rw-p 00015000 08:01 91169                      /lib/libpthread-2.7.so
2ad9709fe000-2ad970a02000 rw-p 2ad9709fe000 00:00 0
2ad970a02000-2ad970a04000 r-xp 00000000 08:01 91158                      /lib/libdl-2.7.so
2ad970a04000-2ad970c04000 ---p 00002000 08:01 91158                      /lib/libdl-2.7.so
2ad970c04000-2ad970c06000 rw-p 00002000 08:01 91158                      /lib/libdl-2.7.so
2ad970c06000-2ad970c09000 r-xp 00000000 08:01 398627                     /lib/libcap.so.1.10
2ad970c09000-2ad970d09000 ---p 00003000 08:01 398627                     /lib/libcap.so.1.10
2ad970d09000-2ad970d0a000 rw-p 00003000 08:01 398627                     /lib/libcap.so.1.10
2ad970d0a000-2ad970d0b000 rw-p 2ad970d0a000 00:00 0
2ad970d0b000-2ad970d13000 r-xp 00000000 08:01 91171                      /lib/librt-2.7.so
2ad970d13000-2ad970f12000 ---p 00008000 08:01 91171                      /lib/librt-2.7.so
2ad970f12000-2ad970f14000 rw-p 00007000 08:01 91171                      /lib/librt-2.7.so
2ad970f14000-2ad970f8c000 r-xp 00000000 08:01 20931                      /usr/lib/libfreetype.so.6.3.16
2ad970f8c000-2ad97118c000 ---p 00078000 08:01 20931                      /usr/lib/libfreetype.so.6.3.16
2ad97118c000-2ad971191000 rw-p 00078000 08:01 20931                      /usr/lib/libfreetype.so.6.3.16
2ad971191000-2ad9711bf000 r-xp 00000000 08:01 20972                      /usr/lib/libfontconfig.so.1.3.0
2ad9711bf000-2ad9713bf000 ---p 0002e000 08:01 20972                      /usr/lib/libfontconfig.so.1.3.0
2ad9713bf000-2ad9713c1000 rw-p 0002e000 08:01 20972                      /usr/lib/libfontconfig.so.1.3.0
2ad9713c1000-2ad9713c2000 rw-p 2ad9713c1000 00:00 0
2ad9713c2000-2ad9714b2000 r-xp 00000000 08:01 16548                      /usr/lib/libstdc++.so.6.0.10
2ad9714b2000-2ad9716b2000 ---p 000f0000 08:01 16548                      /usr/lib/libstdc++.so.6.0.10
2ad9716b2000-2ad9716b8000 r--p 000f0000 08:01 16548                      /usr/lib/libstdc++.so.6.0.10
2ad9716b8000-2ad9716bb000 rw-p 000f6000 08:01 16548                      /usr/lib/libstdc++.so.6.0.10
2ad9716bb000-2ad9716ce000 rw-p 2ad9716bb000 00:00 0
2ad9716ce000-2ad97174c000 r-xp 00000000 08:01 91159                      /lib/libm-2.7.so
2ad97174c000-2ad97194b000 ---p 0007e000 08:01 91159                      /lib/libm-2.7.so
2ad97194b000-2ad97194d000 rw-p 0007d000 08:01 91159                      /lib/libm-2.7.so
2ad97194d000-2ad971963000 r-xp 00000000 08:01 403021                     /lib/libgcc_s.so.1
2ad971963000-2ad971b63000 ---p 00016000 08:01 403021                     /lib/libgcc_s.so.1
2ad971b63000-2ad971b64000 rw-p 00016000 08:01 403021                     /lib/libgcc_s.so.1
2ad971b64000-2ad971b65000 rw-p 2ad971b64000 00:00 0
2ad971b65000-2ad971ca3000 r-xp 00000000 08:01 91155                      /lib/libc-2.7.so
2ad971ca3000-2ad971ea3000 ---p 0013e000 08:01 91155                      /lib/libc-2.7.so
2ad971ea3000-2ad971ea6000 r--p 0013e000 08:01 91155                      /lib/libc-2.7.so
2ad971ea6000-2ad971ea8000 rw-p 00141000 08:01 91155                      /lib/libc-2.7.so
2ad971ea8000-2ad971ead000 rw-p 2ad971ea8000 00:00 0
2ad971ead000-2ad971ec3000 r-xp 00000000 08:01 471479                     /usr/lib/libz.so.1.2.3.3
2ad971ec3000-2ad9720c3000 ---p 00016000 08:01 471479                     /usr/lib/libz.so.1.2.3.3
2ad9720c3000-2ad9720c4000 rw-p 00016000 08:01 471479                     /usr/lib/libz.so.1.2.3.3
2ad9720c4000-2ad9720e4000 r-xp 00000000 08:01 20928                      /usr/lib/libexpat.so.1.0.0
2ad9720e4000-2ad9722e4000 ---p 00020000 08:01 20928                      /usr/lib/libexpat.so.1.0.0
2ad9722e4000-2ad9722e7000 rw-p 00020000 08:01 20928                      /usr/lib/libexpat.so.1.0.0
2ad9722e7000-2ad9722ea000 rw-p 2ad9722e7000 00:00 0
2ad9722ea000-2ad9774fb000 r--p 00000000 08:01 60795                      /usr/lib/locale/locale-archive
2ad97750c000-2ad977513000 r-xp 00000000 08:01 91162                      /lib/libnss_compat-2.7.so
2ad977513000-2ad977712000 ---p 00007000 08:01 91162                      /lib/libnss_compat-2.7.so
2ad977712000-2ad977714000 rw-p 00006000 08:01 91162                      /lib/libnss_compat-2.7.so
2ad977714000-2ad977728000 r-xp 00000000 08:01 91161                      /lib/libnsl-2.7.so
2ad977728000-2ad977927000 ---p 00014000 08:01 91161                      /lib/libnsl-2.7.so
2ad977927000-2ad977929000 rw-p 00013000 08:01 91161                      /lib/libnsl-2.7.so
2ad977929000-2ad97792b000 rw-p 2ad977929000 00:00 0
2ad97792b000-2ad977934000 r-xp 00000000 08:01 91166                      /lib/libnss_nis-2.7.so
2ad977934000-2ad977b34000 ---p 00009000 08:01 91166                      /lib/libnss_nis-2.7.so
2ad977b34000-2ad977b36000 rw-p 00009000 08:01 91166                      /lib/libnss_nis-2.7.so
2ad977b36000-2ad977b40000 r-xp 00000000 08:01 91164                      /lib/libnss_files-2.7.so
2ad977b40000-2ad977d3f000 ---p 0000a000 08:01 91164                      /lib/libnss_files-2.7.so
2ad977d3f000-2ad977d41000 rw-p 00009000 08:01 91164                      /lib/libnss_files-2.7.so
2ad977d41000-2ad977ee8000 r-xp 00000000 08:01 269301                     /usr/lib/vdr/plugins/libvdr-live.so.1.6.0
2ad977ee8000-2ad9780e7000 ---p 001a7000 08:01 269301                     /usr/lib/vdr/plugins/libvdr-live.so.1.6.0
2ad9780e7000-2ad9780f0000 rw-p 001a6000 08:01 269301                     /usr/lib/vdr/plugins/libvdr-live.so.1.6.0
2ad9780f0000-2ad9780f1000 rw-p 2ad9780f0000 00:00 0
2ad978101000-2ad978153000 r-xp 00000000 08:01 21263                      /usr/lib/libcxxtools.so.5.0.0
2ad978153000-2ad978352000 ---p 00052000 08:01 21263                      /usr/lib/libcxxtools.so.5.0.0
2ad978352000-2ad978355000 rw-p 00051000 08:01 21263                      /usr/lib/libcxxtools.so.5.0.0
2ad978355000-2ad978356000 rw-p 2ad978355000 00:00 0
2ad978356000-2ad9783c1000 r-xp 00000000 08:01 21267                      /usr/lib/libtntnet.so.6.0.1
2ad9783c1000-2ad9785c0000 ---p 0006b000 08:01 21267                      /usr/lib/libtntnet.so.6.0.1
2ad9785c0000-2ad9785c4000 rw-p 0006a000 08:01 21267                      /usr/lib/libtntnet.so.6.0.1
2ad9785c4000-2ad978601000 r-xp 00000000 08:01 21265                      /usr/lib/libcxxtools.so.4.0.1
2ad978601000-2ad978801000 ---p 0003d000 08:01 21265                      /usr/lib/libcxxtools.so.4.0.1
2ad978801000-2ad978804000 rw-p 0003d000 08:01 21265                      /usr/lib/libcxxtools.so.4.0.1
2ad978804000-2ad97880b000 r-xp 00000000 08:01 470895                     /usr/lib/libltdl.so.3.1.6
2ad97880b000-2ad978a0a000 ---p 00007000 08:01 470895                     /usr/lib/libltdl.so.3.1.6
2ad978a0a000-2ad978a0b000 rw-p 00006000 08:01 470895                     /usr/lib/libltdl.so.3.1.6
2ad97c000000-2ad97c021000 rw-p 2ad97c000000 00:00 0
2ad97c021000-2ad980000000 ---p 2ad97c021000 00:00 0
7fff3a6eb000-7fff3a701000 rw-p 7fff3a6eb000 00:00 0                      [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]
.

vg, 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.

Quote

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

Display More

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

Quote

Originally posted by TomG

:
:
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

Display More

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

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?

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

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

Quote

Original von TomG

:
:
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

Display More

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

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

steht!!!
Gruesse,
Thorsten

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

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

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

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:

Apr 24 14:04:10 vdr1 vdr: [1352] buffer usage: 70% (tid=1351)
Apr 24 14:04:10 vdr1 vdr: [1352] buffer usage: 80% (tid=1351)
Apr 24 14:04:11 vdr1 vdr: [1352] buffer usage: 90% (tid=1351)
Apr 24 14:04:11 vdr1 vdr: [1351] clearing transfer buffer to avoid overflows
Apr 24 14:04:11 vdr1 vdr: [1352] buffer usage: 0% (tid=1351)
Apr 24 14:04:15 vdr1 vdr: [1352] buffer usage: 70% (tid=1351)
Apr 24 14:04:15 vdr1 vdr: [1352] buffer usage: 80% (tid=1351)
Apr 24 14:04:16 vdr1 vdr: [1352] buffer usage: 90% (tid=1351)
Apr 24 14:04:16 vdr1 vdr: [1351] clearing transfer buffer to avoid overflows
Apr 24 14:04:16 vdr1 vdr: [1352] buffer usage: 0% (tid=1351)
Apr 24 14:04:19 vdr1 vdr: [1352] buffer usage: 70% (tid=1351)
Apr 24 14:04:20 vdr1 vdr: [1352] buffer usage: 80% (tid=1351)
Apr 24 14:04:20 vdr1 vdr: [1352] buffer usage: 90% (tid=1351)
Apr 24 14:04:20 vdr1 vdr: [1351] clearing transfer buffer to avoid overflows
Apr 24 14:04:20 vdr1 vdr: [1352] buffer usage: 0% (tid=1351)
Apr 24 14:04:25 vdr1 vdr: [1352] buffer usage: 70% (tid=1351)
Apr 24 14:04:25 vdr1 runvdr: restarting VDR

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

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

dpkg-gencontrol: warning: unknown information field `C Homepage' in input data in general section of control info file
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${vdr:Patchlevel}
dpkg-gencontrol: warning: unknown information field `C Homepage' in input data in general section of control info file
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${vdr:Patchlevel}
dpkg-gencontrol: warning: unknown information field `C Homepage' in input data in general section of control info file
dpkg-gencontrol: warning: unknown substitution variable ${vdr:Patchlevel}
dpkg-gencontrol: warning: unknown information field `C Homepage' in input data in general section of control info file
dpkg-gencontrol: warning: unknown substitution variable ${vdr:Patchlevel}
dpkg-gencontrol: warning: unknown information field `C Homepage' in input data in general section of control info file
dpkg-gencontrol: warning: unknown substitution variable ${vdr:Patchlevel}
dh_md5sums -a
dh_builddeb -a
dpkg-deb: Baue Paket »vdr« in »../vdr_1.6.0-1ctvdr5_i386.deb«.
dpkg-deb: Baue Paket »vdr-dbg« in »../vdr-dbg_1.6.0-1ctvdr5_i386.deb«.
dpkg-deb: Baue Paket »vdr-plugin-sky« in »../vdr-plugin-sky_1.6.0-1ctvdr5_i386.deb«.
dpkg-deb: Baue Paket »vdr-plugin-examples« in »../vdr-plugin-examples_1.6.0-1ctvdr5_i386.deb«.
dpkg-deb: Baue Paket »vdr-plugin-pictures« in »../vdr-plugin-pictures_1.6.0-1ctvdr5_i386.deb«.
 dpkg-genchanges -b
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: warning: unknown information field `Xb-Vdr-Patchlevel' in input data in package's section of control info file
dpkg-genchanges: binary-only upload - not including any source code

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

I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
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:

vdr1:~# /etc/init.d/vdr start
Starting Linux Video Disk Recorder: vdr
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
WARNING: The following plugins have been left out due to possible binary incompatibility: wirbelscan.

Den Patchlevel:

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

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