AutoPID findet Kanäle doppelt

hi,
zu den doppelten kanälen: du kannst einstellen das der vdr NUR die pid und nicht den namen automatisch übernimmt. das sollte dein stichwort sein. zudem ist es möglich mittels "magic-value" in der channels.conf diese einstellung für alle sender getrennt vorzunehmen.

ich habs folgendermaßen gemacht.
- leere channels.conf erstellt.
- gescannt
- von hand sortiert

das hat dann leider fast eine stunde gedauert, aber dafür hab ich jetzt eine persönlich zugeschnittene channels.conf. wie man das ganze automatisch machen kann - da bin ich überfragt.

hi,.
was C,R,W bedeute steht in der readme, kann ich dir jetzt nicht direkt sagen.

das mit den kanälen doppelt meinte ich so: autopid erkennt das sich der name geändert hat und glaubt daher es ist ein neuer kanal und trägt ihn daher in die liste neu ein.
400 kanäle ... ich hab jetzt nur noch so ca. 100 drin. und wenn man das ganze veschlüsselte zeugs wegmacht bleibt halt nicht mehr soviel übrig. die 10privaten haupsender. 30x irgendwelche dritte programme, ARD+ZDF... mehr ist dann nicht mehr. das ausländige zeugs kann ich ja net wirklich kucken (außer Fashion TV), daher ist das nicht mehr in der liste drin.

worand das jetzt z.B. mit DW-TV liegt, da bin ich leider überfagt. das werden wohl nur die richtigen werte für pid, frequenz, ... sein.

Hm leere Channels.conf. Wie erzeug ich die denn. Reicht es aus einfach alle Zeilen zu löschen oder muss ich einige Einträge drinnlassen damit der autopid arbeitet ?

mfg Leika

Hallo

Hab mich gerade gefragt warum ich damals den AutoPid Patch nicht installaiert habe, doch dann viel es mir wieder ein.

Zitat

Original von JK1974
Nur tauchen nach dem Scan am Ende ein paar Kanäle doppelt auf, gerade Premiere-Channels sind in der Original-channels.conf klein geschrieben, während der neu gefundene Kanal groß geschrieben ist. Dachte eigentlich, dass Kanal-Namen aktualisiert werden, aber das scheint in diesem Fall nicht zu funktionieren.

Zitat

Original von JK1974
Das mit den doppelten Kanälen und nur PID verstehe ich nicht. Dachte, wenn sich der Name ändert, dass er direkt in die channels.conf eingetragen wird (ebenso wie die PIDs) und nicht der Sender erneut hinten drangehängt wird.

Genau wegen dieser Sache, ist das immer noch so?

MfG

Hallo

Ich bin es nochmal
Hab nun vdr-1.2.4 mit vdr-1.2.0-autopid-1.diff gepatcht (gibt es ein aktuelleren Patch?), raus kam folgendes:

vdr:/usr/local/src/vdr-1.2.4 # cat vdr-1.2.0-autopid-1.diff | patch -p1
patching file Makefile
Hunk #1 succeeded at 34 (offset 1 line).
patching file PLUGINS/src/hello/Makefile
patching file PLUGINS/src/osddemo/Makefile
patching file PLUGINS/src/scanner/COPYING
patching file PLUGINS/src/scanner/HISTORY
patching file PLUGINS/src/scanner/Makefile
patching file PLUGINS/src/scanner/README
patching file PLUGINS/src/scanner/dvbscanner.c
patching file PLUGINS/src/scanner/dvbscanner.h
patching file PLUGINS/src/scanner/i18n.c
patching file PLUGINS/src/scanner/i18n.h
patching file PLUGINS/src/scanner/scanner.c
patching file PLUGINS/src/sky/Makefile
patching file PLUGINS/src/status/Makefile
patching file README.autopid
patching file channels.c
patching file channels.conf
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file channels.conf.rej
patching file channels.h
patching file config.c
Hunk #1 succeeded at 272 (offset 1 line).
Hunk #2 succeeded at 426 (offset 2 lines).
Hunk #3 succeeded at 478 (offset 3 lines).
patching file config.h
Hunk #3 succeeded at 293 (offset 5 lines).
patching file dvbdevice.c
Hunk #6 succeeded at 661 (offset 14 lines).
Hunk #7 succeeded at 672 (offset 14 lines).
Hunk #8 succeeded at 697 (offset 14 lines).
Hunk #9 succeeded at 773 (offset 14 lines).
Hunk #10 succeeded at 791 (offset 14 lines).
Hunk #11 succeeded at 802 (offset 14 lines).
patching file dvbdevice.h
Hunk #4 succeeded at 119 (offset 1 line).
patching file eit.c
patching file eit.h
patching file i18n.c
Hunk #1 succeeded at 3739 with fuzz 1 (offset 34 lines).
patching file keymacros.conf
patching file keys.c
patching file keys.h
patching file libdtv/libsi/si_debug_services.c
patching file libdtv/libvdr/libvdr.c
patching file libdtv/libvdr/libvdr.h
patching file menu.c
Hunk #1 succeeded at 584 (offset 1 line).
Hunk #2 succeeded at 640 (offset 2 lines).
Hunk #3 succeeded at 741 (offset 2 lines).
Hunk #4 succeeded at 2122 (offset 4 lines).
Hunk #5 succeeded at 2522 (offset 6 lines).
Hunk #6 succeeded at 2614 (offset 6 lines).
Hunk #7 succeeded at 2633 (offset 6 lines).
Hunk #8 succeeded at 2680 (offset 6 lines).
patching file osd.h
patching file osdbase.h
patching file recording.c
Hunk #1 succeeded at 704 (offset 1 line).
patching file sections.c
patching file sections.h
patching file thread.c
patching file thread.h
patching file tools.h
patching file transponders.conf
patching file vdr.c
Hunk #1 succeeded at 549 (offset 5 lines).

Hat das patchen nun geklappt? Was bedeuten die ganzen "Hunk"?

MfG

Hi,

ja so lange dort "succeeded" steht, ist alles OK. Einmal steht bei Dir "FAILED", aber das ist nur bei der "channels.conf", von der Du wahrscheinlich ja eh Deine eigene nimmst. Die hunks bedueten nur, dass beim patchen die Zeilen etwas versetzt sind.

mat

Die diffs haben funktioniert, bis auf die Anpassung der Channels.conf.

Mal grundsätzlich

Im diff file steht
1. welches File verändert werden soll
2. an welcher Zeilenummer
3. ein "Kontext" also drei Zeilen vor und nach der Änderung

Wenn Patch genau den Kontext in dem angegebenen File an derangegebender Stelle findet schreibt er:
"patching file bla/bla/bla.cpp" >> OK
Wenn er den Kontext nicht in der z.B. Zeile 33 findet sondern auf Zeile 34 schreibt er
"Hunk #x succeded at 34 ( offset 1 line)" >>OK

Für die versuche die richtige stelle zu finden benutzt er verschiedene Verfahren
daher kann da noch etwas von "fuzz" o.ä. stehen.

Wenn er die stelle für die Änderung nicht findet schreibt er
"Hunk #1 FAILED at 123.
1 out of 3 hunk FAILED -- saving rejects to file blabla.cpp.rej" == NICHT OK

Dann gibt folgende Files:
blabla.cpp ==>file mit den änderunge die geklappt haben
blabla.cpp.org ==> orginal-File ohne änderungen
blabal.cpp.rej ==> nur die Änderung die patch nicht unterbringen konnte.

Jetzt kann man versuche herauszufinden wo die Änderung in blabla.cpp.rej hingehören und sie in blabla.cpp eintragen.
Dafür muss man evtl. programmieren können, evtl geht es garnicht weil der Patch nicht kompatible ist.

Fragt patch nach "File to patch: ?" hat man meist den Parameter "-p" nicht richtig übergeben. Meistens sollte es "-p 1" sein, d.h. schneide 1 Pfadangabe vom Pfad im diff ab und suche dort die Files zum verändern.

Fragt patch "Assume -R [n] ?" bedeutet meistens dass der Patch schon installiert war.

Durch mehrere Patch-versuche kann man die Dateien in einen undefinierbaren Zustand bringen. Dann hilft nur löschen und nochmal die orginal Dateinen auspacken und neu versuchen ( evtl. bei mehreren patches in einer anderen Reihenfolge ).

<sendung_mit_der_maus_modus>
Und morgen erklär' ich euch warum "rm -rf /" ein ganz böser Befehl ist
</sendung_mit_der_maus_modus>

Danke, jetzt weiß ich wenigstens auch was ich da mache

Kannst ja mal in einen patch reinschauen ( ist ASCII Text ) dort steht als erstes mit welchem Befehl und Parameter der Patch erstellet wurde.

Also ich nehme
"diff -Nru"