Sorry, hatte nicht genau geguckt. Erst mit dem Patch aus #59 tut es richtig, danke.
[ANNOUNCE] VDR developer version 1.7.27
- Uwe
- Geschlossen
-
-
@Keine_Ahnung
dein sndctl ist gegen vdr 1.7.27 ohne Fehler durchgelaufen und funzt wunderbar, danke dafür.
ciao -
gda meinte mein Edit oben wird leicht uebersehen, darum nochmal extra und wenn ich schon dabei bin als kompletter patch, damit tut osdteletext 0.9.2 mit vdr 1.7.27 ohne corruptions.
Danke nox & gda, damit klappt es nun.
fnu: es wurde doch nachgefragt, aber er nutzt noch vdr-1.7.26, weil es mit der kommenden Version weitere Änderungen geben wird .... Siehe hier! -
weil es mit der kommenden Version weitere Änderungen geben wird ....
Hmm, ich gewinne eher den Eindruck Klaus steht kurz vor 2.0. Die 1.7.26 hat sich für mich schon wie ein Realease Candidate angefühlt, was sich mit dem Abwurf von Altlasten bei 1.7.27 eher noch untermauert hat. Aber das ist nur mein persönlicher Eindruck ...Regards
fnu -
Hier hat mit vdr-1.7.27 sich wieder ein Problem bemerkbar gemacht, welches eigentlich schon gelöst wurde von Klaus (prio).
Es hat vielleicht was mit dem Bonding von Device 1 und Device 2 der FF HD 6400 zu tun?
Zusätzlich zur FF HD 6400 ist noch eine Dual S2 DVB karte eingebaut, hier aber bekommt Device 3 und Device 4 jeweils ein eigenes DVB Kabel.
Wenn der Vdr nun wegen einem Timer startet und eine Aufnahme startet (Device2), dann bleibt das Live Bild stehen (Standbild), erst wenn ich umschalte funktioniert wieder alles.
Der VDR ist ungepatcht und es sind die gleichen Plugins aktiviert wie bei vdr-1.7.26. Das Problem konnte ich die ganze Woche, jeden Tag nachvollziehen.
Hat jemand eine Idee bzw kann das bestätigen. Im Log konnte ich nichts auffälliges finden. -
Könnte mir vorstellen das mit dem Standbild wäre evtl. works as designed oder aber ein Folgefehler. Ich finde es schon nicht richtig das die Aufnahme auf Device 2 startet und nicht Device 3 oder 4.
Ansonsten würde ich bei Mischbelegung, 4 DVB Adapter und drei Kabel, das ebenso wie Du verkabeln, die "Frontend" Adapter per DB bündeln und die "Background" Adapter mit eigenen Kabeln versehen, weil dort ja eigentlich die Aufnahmen starten sollten, oder?
Regards
fnu -
Schon seltsam - die Umstellung auf 'gettext' fand vor gut vier Jahren statt, sogar noch vor der Version 1.6.
Wäre eigentlich genug Zeit gewesen, darauf zu reagieren...Da bin ich wohl nicht ganz unschuldig dran:
Viele Projekte haben damals mein po2i18n-System übernommen, welches für ältere VDR-Versionen automatisch die älteren Übersetzungen generiert. In diesem Übersetzungssystem steckt aber ein kleiner Fehler: In der dazu gehörigen i18n.h ist ein #if VDRVERSNUM < 10507, das aber nicht richtig funktioniert, da vorher kein #include <vdr/config.h> gemacht wurde. Bisher ließ es sich trotzdem übersetzen, und jetzt erst fällt der Fehler auf.Beheben kann man den Fehler daher ganz einfach, in dem man das #include <vdr/config.h> hinzu fügt.
Gruß,
Udo
-
Hmm, ich gewinne eher den Eindruck Klaus steht kurz vor 2.0.
Die "2.0" kommt sicherlich nicht vor dem Jahr 2018, wenn überhaupt was in dieser Richtung kommt, dann kommt so oder so erstmal die "1.8". -
Hier hat mit vdr-1.7.27 sich wieder ein Problem bemerkbar gemacht, welches eigentlich schon gelöst wurde von Klaus (prio).
Es hat vielleicht was mit dem Bonding von Device 1 und Device 2 der FF HD 6400 zu tun?
Zusätzlich zur FF HD 6400 ist noch eine Dual S2 DVB karte eingebaut, hier aber bekommt Device 3 und Device 4 jeweils ein eigenes DVB Kabel.
Wenn der Vdr nun wegen einem Timer startet und eine Aufnahme startet (Device2), dann bleibt das Live Bild stehen (Standbild), erst wenn ich umschalte funktioniert wieder alles.
Der VDR ist ungepatcht und es sind die gleichen Plugins aktiviert wie bei vdr-1.7.26. Das Problem konnte ich die ganze Woche, jeden Tag nachvollziehen.
Hat jemand eine Idee bzw kann das bestätigen. Im Log konnte ich nichts auffälliges finden.
Ich hatte das Problem mit dem Device Bonding damals auch, muss aber sagen, das es im Moment mit vdr-1.7.27 absolut problemlos bei mir geht. Ich habe allerdings 3 Tuner an nur einem Kabel angeschlossen.
Kannst Du bitte mal prüfen, ob sich bei Dir eventuell die Reihenfolge der Devices zufällig mal ändert und dann die falschen Devices gebondet sind, denn das könnte sich durchaus so auswirken.Gruß
Karl
-
Die "2.0" kommt sicherlich nicht vor dem Jahr 2018, wenn überhaupt was in dieser Richtung kommt, dann kommt so oder so erstmal die "1.8".Die kommende Stable-Version wird definitiv 2.0 sein.
Klaus sagte das auf der ML in etwa so (nicht wörtlich):
1.x ist der SD-VDR
2.x wird der HD-VDR sein
3.x wird der Netzwerk-VDR sein (?)Für mich sieht das auch langsam nach 2.0 aus.
CafeDelMar
-
Ich hatte das Problem mit dem Device Bonding damals auch, muss aber sagen, das es im Moment mit vdr-1.7.27 absolut problemlos bei mir geht. Ich habe allerdings 3 Tuner an nur einem Kabel angeschlossen.
Kannst Du bitte mal prüfen, ob sich bei Dir eventuell die Reihenfolge der Devices zufällig mal ändert und dann die falschen Devices gebondet sind, denn das könnte sich durchaus so auswirken.
Wie schon oben gesagt, ist alles wie bei vdr-1.7.26 und davor. Die Reihenfolge der Devices hat sich nicht verändert... -
Da ich nach intensiver Suche nichts konkretes finden konnte:
Ist es möglich (ohne Wrapper, z.B. von urig unter [ANNOUNCE] VDR developer version 1.7.23) den VDR >= 1.7.23 mit einem Kernel 2.6.32 (Debian squeeze) zu betreiben?
Ich habe den Tipp von Klaus ([ANNOUNCE] VDR developer version 1.7.23) schon probiert - leider meckert der VDR nach Installation immer noch nach DVB API 5.3.
Gruss
Marcus -
Was hast du gegen den API Wrapper?
Ich habe den Tipp von Klaus ([ANNOUNCE] VDR developer version 1.7.23) schon probiert - leider meckert der VDR nach Installation immer noch nach DVB API 5.3.
Hast du den Pfad dazu in make.config korrekt gesetzt?
cu
-
Hast du den Pfad dazu in make.config korrekt gesetzt?
Ich glaube ich war heute zu lang vor der Shell - das war das Problem mit den media_build_experimental Treibern. Pfad ist angepasst und VDR ist kompiliert. Danke!
Gegen den Wrapper hab ich grundsätzlich nichts - gegen 1.7.27 gibt es jedoch Rejects und wenn ich die 1.7.27 schon teste, wollte ich gleich den "richtigen" Unterbau.D.h. also aktuell gibt es folgende Optionen:
- Wrapper
- media_build_experimental (oder gibt es noch mehr Repos?)
- Umstieg auf Kernel 3.0
Marcus
-
Gegen den Wrapper hab ich grundsätzlich nichts - gegen 1.7.27 gibt es jedoch Rejects und wenn ich die 1.7.27 schon teste, wollte ich gleich den "richtigen" Unterbau.
Ohne urig's "s2apiwrapper" gäbe es kein VDR 1.7.27 in unseren yaVDR testing Repositories für 0.3/0.4 und hier gab es keine rejects ... ? Evtl. ein Problem in Verbindung mit anderen Patches?Regards
fnu -
Ohne urig's "s2apiwrapper" gäbe es kein VDR 1.7.27 in unseren yaVDR testing Repositories für 0.3/0.4 und hier gab es keine rejects ... ? Evtl. ein Problem in Verbindung mit anderen Patches?
Habe einen Plain 1.7.27 VDR genommen mit folgendem Ergebnis (Patch ist der letzte von Urigs Seite):Code
Alles anzeigen[root@macvdr /usr/local/src/installiert/vdr-1.7.27]$ patch < vdr-1.7.24-s2apiwrapper-0.8.diff patching file channels.c patching file dvbdevice.c Hunk #1 succeeded at 724 (offset 2 lines). Hunk #2 succeeded at 842 (offset 2 lines). patching file dvbdevice.h patching file Makefile Hunk #1 succeeded at 40 with fuzz 2. patching file nit.c patching file dvbsddevice.c Hunk #1 FAILED at 23. Hunk #2 FAILED at 58. 2 out of 2 hunks FAILED -- saving rejects to file dvbsddevice.c.rej patching file dvbsdffdevice.c Hunk #1 FAILED at 22. Hunk #2 FAILED at 760. 2 out of 2 hunks FAILED -- saving rejects to file dvbsdffdevice.c.rej patching file dvbsdffdevice.h Hunk #1 FAILED at 26. 1 out of 1 hunk FAILED -- saving rejects to file dvbsdffdevice.h.rej patching file s2apiwrapper.c patching file s2apiwrapper.h patching file vdr.c Hunk #1 succeeded at 54 with fuzz 2 (offset -1 lines). Hunk #2 succeeded at 219 (offset -3 lines). Hunk #3 succeeded at 266 (offset -4 lines). [root@macvdr /usr/local/src/installiert/vdr-1.7.27]$
Marcus
-
Habe einen Plain 1.7.27 VDR genommen mit folgendem Ergebnis (Patch ist der letzte von Urigs Seite):
[lots of rejects]
Ich hab den patch fuer die FreeBSD vdr ports (http://people.freebsd.org/~nox/tmp/vdr-ports-1.7.27-004.shar) genommen: http://www.udo-richter.de/vdr/….24-s2apiwrapper-0.8.diff, mit patch args -p1 rejected da nix:Code
Alles anzeigenzsh enceladus% make extract ===> License check disabled, port has not defined LICENSE ===> Found saved configuration for vdr-1.7.22 ===> Extracting for vdr-1.7.27 => SHA256 Checksum OK for vdr/vdr-1.7.27.tar.bz2. => SHA256 Checksum OK for vdr/vdr-1.7.24-s2apiwrapper-0.8.diff. zsh enceladus% ll /usr/ports/distfiles/vdr/vdr-1.7.24-s2apiwrapper-0.8.diff -rw-r--r-- 1 root wheel 19788 Feb 19 17:52 /usr/ports/distfiles/vdr/vdr-1.7.24-s2apiwrapper-0.8.diff zsh enceladus% patch -p1 -Cd work/vdr-1.7.27 < /usr/ports/distfiles/vdr/vdr-1.7.24-s2apiwrapper-0.8.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/channels.c vdr-1.7.23-s2apiwrapper/channels.c |--- vdr-1.7.23/channels.c 2011-08-26 14:44:21.000000000 +0200 |+++ vdr-1.7.23-s2apiwrapper/channels.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file channels.c using Plan A... Hunk #1 succeeded at 10. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/dvbdevice.c vdr-1.7.23-s2apiwrapper/dvbdevice.c |--- vdr-1.7.23/dvbdevice.c 2012-01-15 15:31:47.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/dvbdevice.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file dvbdevice.c using Plan A... Hunk #1 succeeded at 724 (offset 2 lines). Hunk #2 succeeded at 842 (offset 2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/dvbdevice.h vdr-1.7.23-s2apiwrapper/dvbdevice.h |--- vdr-1.7.23/dvbdevice.h 2012-01-13 12:32:45.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/dvbdevice.h 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file dvbdevice.h using Plan A... Hunk #1 succeeded at 13. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/Makefile vdr-1.7.23-s2apiwrapper/Makefile |--- vdr-1.7.23/Makefile 2012-01-14 14:09:10.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/Makefile 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file Makefile using Plan A... Hunk #1 succeeded at 40 with fuzz 2. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/nit.c vdr-1.7.23-s2apiwrapper/nit.c |--- vdr-1.7.23/nit.c 2012-01-12 09:43:52.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/nit.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file nit.c using Plan A... Hunk #1 succeeded at 11. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsddevice.c vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsddevice.c |--- vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsddevice.c 2011-08-27 13:34:58.000000000 +0200 |+++ vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsddevice.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file PLUGINS/src/dvbsddevice/dvbsddevice.c using Plan A... Hunk #1 succeeded at 23. Hunk #2 succeeded at 60. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsdffdevice.c vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsdffdevice.c |--- vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsdffdevice.c 2011-08-27 13:33:57.000000000 +0200 |+++ vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsdffdevice.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file PLUGINS/src/dvbsddevice/dvbsdffdevice.c using Plan A... Hunk #1 succeeded at 22. Hunk #2 succeeded at 750 (offset -11 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsdffdevice.h vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsdffdevice.h |--- vdr-1.7.23/PLUGINS/src/dvbsddevice/dvbsdffdevice.h 2011-08-27 13:32:42.000000000 +0200 |+++ vdr-1.7.23-s2apiwrapper/PLUGINS/src/dvbsddevice/dvbsdffdevice.h 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file PLUGINS/src/dvbsddevice/dvbsdffdevice.h using Plan A... Hunk #1 succeeded at 26. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/s2apiwrapper.c vdr-1.7.23-s2apiwrapper/s2apiwrapper.c |--- vdr-1.7.23/s2apiwrapper.c 1970-01-01 01:00:00.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/s2apiwrapper.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- (Creating file s2apiwrapper.c...) Patching file s2apiwrapper.c using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/s2apiwrapper.h vdr-1.7.23-s2apiwrapper/s2apiwrapper.h |--- vdr-1.7.23/s2apiwrapper.h 1970-01-01 01:00:00.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/s2apiwrapper.h 2012-01-15 21:11:14.000000000 +0100 -------------------------- (Creating file s2apiwrapper.h...) Patching file s2apiwrapper.h using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naur vdr-1.7.23/vdr.c vdr-1.7.23-s2apiwrapper/vdr.c |--- vdr-1.7.23/vdr.c 2011-12-03 16:35:09.000000000 +0100 |+++ vdr-1.7.23-s2apiwrapper/vdr.c 2012-01-15 20:09:12.000000000 +0100 -------------------------- Patching file vdr.c using Plan A... Hunk #1 succeeded at 54 with fuzz 2 (offset -1 lines). Hunk #2 succeeded at 220 (offset -2 lines). Hunk #3 succeeded at 268 (offset -2 lines). done zsh enceladus% echo $? 0 zsh enceladus%
(-C ist check, willst du also vermutlich weglassen.) -
Moin, Moin
ZitatHabe einen Plain 1.7.27 VDR
Mal ne dumme Frage, was bedeutet Plain VDR? Sind da evtl. schon diverse Patches eingespielt?
Ich nutzte auch Debian Squeeze mit Kernel 2.6.32 mit VDR Vanilla 1.7.27 + vdr-1.7.24-s2apiwrapper-0.8.diff.
Bis das mit den ext-P-NG Patch der skinelchi Plugin nicht durchlief, konnte ich ein paar Plugin Problem mit Hilfe aus den Form lösen.Ergab:
Code
Alles anzeigenpatching file channels.c patching file dvbdevice.c Hunk #1 succeeded at 724 (offset 2 lines). Hunk #2 succeeded at 842 (offset 2 lines). patching file dvbdevice.h patching file Makefile Hunk #1 succeeded at 40 with fuzz 2. patching file nit.c patching file PLUGINS/src/dvbsddevice/dvbsddevice.c patching file PLUGINS/src/dvbsddevice/dvbsdffdevice.c Hunk #2 succeeded at 750 (offset -11 lines). patching file PLUGINS/src/dvbsddevice/dvbsdffdevice.h patching file s2apiwrapper.c patching file s2apiwrapper.h patching file vdr.c Hunk #1 succeeded at 54 with fuzz 2 (offset -1 lines). Hunk #2 succeeded at 219 (offset -3 lines). Hunk #3 succeeded at 266 (offset -4 lines).
Grüße
-
-
In den Announce-Threads zu meinen Plugins sind jetzt Patches für VDR 1.7.27 verfügbar: burn-0.2.0, avards-0.2.4 und skinelchi-0.2.6
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!