Ich hab den alten S2API-Wrapper aufgefrischt, damit er DVB API 5.3 emulieren kann, damit kann man wieder einen lauffähigen VDR übersetzen, ohne auf Linux-3.0 upgraden zu müssen.
Also ich verwende hier openSUSE 11.4 mit Kernel 2.6.37.6.
Man muß also nicht gleich kernelmäßig auf Linux-3.0 wechseln.
Den Treiber hole ich mir mit
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untarKlaus
Alles anzeigenHallo kls,
ist das so gewollt?
dvbdevice.c1133
Code#if DVB_API_VERSION > 5 || DVB_API_VERSION_MINOR >= 5
Wäre nicht das besser:
Code#if (DVB_API_VERSION << 8 | DVB_API_VERSION_MINOR) >= 0x0505
Im Prinzip hast du natürlich Recht, aber in dvbdevice.h wird ja bereits gefordert, daß DVB_API_VERSION mindestens 5 ist.
Deine Notation gefällt mir aber auch gut, werde sie wohl übernehmen.
Klaus
Super mit der Version gehen jetzt bei mir alle 4 Karten über Unicable, was bisher nicht funktioniert hat.
hi
ok ok 
falsch gefragt .
was ist "device bonding" im zusammenhang mit vdr ?
ich keine bonding vom ethernet aber ich gehe davon aus das das damit nix zu tun hat.
holger
Man muß also nicht gleich kernelmäßig auf Linux-3.0 wechseln.
Den Treiber hole ich mir mit
Hat das irgendwelche Vorteile? Die alten Treiber sind dort doch auch nicht besser als die im Kernel. Und vermutlich holt man sich dann nur zusätzliche Probleme ins Haus (z.B. Fernbedienung).
Was spricht denn dagegen den Patch von Urig mit in den VDR zu übernehmen?
cu
PS: Gut das man als SD User von dem Treiberblödsinn verschont bleibt 
media_build_experimental# ./build
<....>
Preparing to compile for kernel version 2.6.35
File not found: /lib/modules/2.6.35.3-0.22.digitainer/build/.config at ./scripts/make_kconfig.pl line 33, <IN> line 4.
make[1]: *** [allyesconfig] Fehler 2
make[1]: Leaving directory `/root/bbbbbbbbbbb/media_build_experimental/v4l'
make: *** [allyesconfig] Fehler 2
can't select all drivers at ./build line 379.Moin!
was ist "device bonding" im zusammenhang mit vdr ?
Bevor es in den vdr integriert wurde, war es der "LNB-Sharing-Patch".
Die Idee dahinter: Zwei (oder mehr) Tuner teilen sich ein Kabel, aber der LNB kann kein Unicable/SCR. Einer der Tuner wird der "Master", der die Diseqc-Kommandos an den LNB schickt, die anderen können dann alle Sender auf der gleichen Sat-Ebene empfangen.
Dadurch kann man in einer "limitierten" Umgebung schon ein bisschen mehr aufnehmen als mit nur einem Tuner.
Lars.
Ich habe Probleme mit der neuen Version.
Eines meiner Devices kann DVB-T, DVB-T2 und DVB-C - genauer jeweils exakt eines davon, da nur ein Antennenanschluß vorhanden ist. Mein System empfängt DVB-C und DVB-T.
Da nun DVB-C als supported delivery system gemeldet wird, versucht VDR das Gerät als DVB-C zu benutzen, was natürlich nicht an einer DVB-T Antenne funktioniert.
Umgekehrt würde beim Antennenanschluss ans Kabelnetz versucht werden, das Gerät ebenso als DVB-T/T2 zu benutzen.
VDR fehlt seit der Implementierung der neuen Device Philosophie eine Möglichkeit je Device die möglichen Delivery Systems zu begrenzen.
Klaus, könntest du das bitte als Feature Request aufnehmen? So ist VDR ohne Patch nicht mehr nutzbar.
#if (DVB_API_VERSION << 8 | DVB_API_VERSION_MINOR) >= 0x0505
Ginge übrigens auch so, fall minor jemals größer als 9 sein sollte und man hex Zahlen vermeiden möchte.
Zitat#if (DVB_API_VERSION *100 + DVB_API_VERSION_MINOR) >= 505
Hallo kls,
Zitat- Fixed bonding more than two devices.
die Live-Darstellung mit meinen 3 Tunern geht jetzt.
Beim Aufnehmen mit unterschiedlicher Polarisation oder Band stellt sich jetzt folgende Situation dar:
- Die Aufnahme startet ordnungsgemäß auf dem 2. Tuner
- Das Live-Bild auf dem 1. Tuner bleibt jetzt einfach stehen (klar, kann ja auch nicht mehr gehen)
- Nach Beenden der Aufnahme kommt das Live-Bild ohne explizites Umschalten nicht wieder
Beim bisherigen LNB-Sharing-Patch war es so, das mit Beginn der Aufnahme ein "Kanal nicht verfügbar" eingeblendet wurde und die Live-Übertragung auf den Aufnahmekanal geschaltet hat, das fand ich eigentlich OK.
Zumindest sollte hier aus meiner Sicht vielleicht noch ein definierter Zustand (eigeblendete Meldung oder der nächste verfügbare Kanal) für die Live-Übertragung hergestellt werden, sonst könnte man durchaus Denken, der VDR ist abgestürtzt.
Zitat- Fixed handling symbolic links in cRecordings::ScanVideoDir() (reported by Sundararaj Reel).
- Fixed a memory leak in cRecordings::ScanVideoDir() in case there are too many
Symbolische Links werden bei mir jetzt gar nicht mehr angezeigt.
Meine Konfiguration sieht so aus, das ich im Aufnahmeverzeichnis mehrere Links auf Ordner, die sich über nfs auf einem NAS befinden, liegen habe.
Diese wurden bisher ohne Probleme bei aktivem NAS angezeigt, bei inaktivem NAS ignoriert.
Außerdem wird jetzt bei den Aufnahmen ein Ordner "video" angezeigt, der so eigentlich nicht vorhanden sein sollte.
Es gibt zwar einen symbolischen Link /video.ori-->/server/home/video, in dem die Ordner video0, video1, video2 liegen. Davon werden in der Aufnahmenliste unter video aber nur die Ordner video0 und video1 angezeigt.
Das Ganze ist ein wenig verwirrend. Das Aufnahmeverzeichnis liegt bei mir unter /home/video0, dieses wurde mit "-v /home/video0" dem VDR bekannt gegeben. In diesem Ordner liegen die oben genannten Links. Der VDR sollte also die Orner /video oder /video.ori normalerweise nicht kennen.
Soweit ich das jetzt probieren konnte, tritt das Problem mit der alten recording.c aus 1.7.22 nicht auf.
Karl.
Moin!
VDR fehlt seit der Implementierung der neuen Device Philosophie eine Möglichkeit je Device die möglichen Delivery Systems zu begrenzen.
Klaus, könntest du das bitte als Feature Request aufnehmen? So ist VDR ohne Patch nicht mehr nutzbar.
Das fiel mir nachts auch ein, dass ich nachsehen wollte, ob das berücksichtigt wurde.
Als Vorschlag: eine "Device-Nr."-Zeile in der source.conf?
Lars.
Alles anzeigenSymbolische Links werden bei mir jetzt gar nicht mehr angezeigt.
Meine Konfiguration sieht so aus, das ich im Aufnahmeverzeichnis mehrere Links auf Ordner, die sich über nfs auf einem NAS befinden, liegen habe.
Diese wurden bisher ohne Probleme bei aktivem NAS angezeigt, bei inaktivem NAS ignoriert.
Außerdem wird jetzt bei den Aufnahmen ein Ordner "video" angezeigt, der so eigentlich nicht vorhanden sein sollte.
Es gibt zwar einen symbolischen Link /video.ori-->/server/home/video, in dem die Ordner video0, video1, video2 liegen. Davon werden in der Aufnahmenliste unter video aber nur die Ordner video0 und video1 angezeigt.
Das Ganze ist ein wenig verwirrend. Das Aufnahmeverzeichnis liegt bei mir unter /home/video0, dieses wurde mit "-v /home/video0" dem VDR bekannt gegeben. In diesem Ordner liegen die oben genannten Links. Der VDR sollte also die Orner /video oder /video.ori normalerweise nicht kennen.
Soweit ich das jetzt probieren konnte, tritt das Problem mit der alten recording.c aus 1.7.22 nicht auf.
Kannst du testweise bitte mal diese Änderung rückgängig machen?
--- recording.c 2011/12/04 13:51:44 2.39
+++ recording.c 2011/12/10 14:12:55 2.40
@@ -1105,7 +1105,7 @@
if (strcmp(e->d_name, ".") && strcmp(e->d_name, "..")) {
char *buffer = strdup(AddDirectory(DirName, e->d_name));
struct stat st;
- if (stat(buffer, &st) == 0) {
+ if (lstat(buffer, &st) == 0) {
int Link = 0;
if (S_ISLNK(st.st_mode)) {
if (LinkLevel > MAX_LINK_LEVEL) {Klaus
Das fiel mir nachts auch ein, dass ich nachsehen wollte, ob das berücksichtigt wurde.
Als Vorschlag: eine "Device-Nr."-Zeile in der source.conf?
Halte ich für keine gute Idee.
Das sind aber auch "dämliche" Devices
Hat denn vielleicht der Treiber eine Option, um das jeweils nicht verwendete System zu deaktivieren?
Oder einfach in der channels.conf keine Einträge für das nicht verwendete System machen. Dann
kommt VDR auch nicht auf die Idee, es zu benutzen.
Klaus
Hallo, und es geht VDR mässig immer weiter - Danke an Klaus. 
Es fehlt, wie schon erwähnt, der ext. Patch für diese Version.
Für mich wäre nur der Graphtft-Patch wichtig.
mfg Rudi
Sorry - gerade erst gesehen dort : Gen2VDR extension Patch.
sollte passen
Hat das irgendwelche Vorteile?
Da ist z.B. der Treiber für die TT-S2 6400 mit drin
Zitat
Was spricht denn dagegen den Patch von Urig mit in den VDR zu übernehmen?
Ich möchte halt nicht ewig alle möglichen alten Treiberversionen unterstützen müssen.
Klaus
Halte ich für keine gute Idee.
Das sind aber auch "dämliche" Devices
Hat denn vielleicht der Treiber eine Option, um das jeweils nicht verwendete System zu deaktivieren?
Das war auch meine erste Idee. Leider nein.
Zitat
Oder einfach in der channels.conf keine Einträge für das nicht verwendete System machen. Dann
kommt VDR auch nicht auf die Idee, es zu benutzen.
Das macht bei einem System mit Kabel *und* Terrestrisch keinen Sinn - wer wirft freiwillig die Hälfte aller Sender weg..
Moin!
Halte ich für keine gute Idee.
Das sind aber auch "dämliche" Devices
Hat denn vielleicht der Treiber eine Option, um das jeweils nicht verwendete System zu deaktivieren?
Oder einfach in der channels.conf keine Einträge für das nicht verwendete System machen. Dann
kommt VDR auch nicht auf die Idee, es zu benutzen.
Das hilft nicht, wenn man eine DVB-C- und eine DVB-T-Karte hat und die DVB-C-Karte ein Hybridmodell ist.
Die Treiber haben so eine Option leider auch meistens nicht (hätte ich mir schon vor der API-Änderung gewünscht).
So langsam wird die Device-Verwaltung im vdr sehr anspruchsvoll... Ich würde mir eine Konfiguration über udev wünschen, aber ich weiß nicht, was du von einer Abhängigkeit von libudev hälst.
Das hätte dann aber auch den Vorteil, dass eine Änderung der Reihenfolge der Karteninitialisierung nicht gleich den ganzen vdr aus der Bahn wirft.
Lars.
Kannst du testweise bitte mal diese Änderung rückgängig machen?
Ich habe diese Änderung rückgängig gemacht.
Ja, damit sieht es wieder so aus wie bisher.
Karl.
Klaus, vielen Dank für Deine Mühen 
Super mit der Version gehen jetzt bei mir alle 4 Karten über Unicable, was bisher nicht funktioniert hat.
Da wir ja alle noch mit SCR/Unicable® lernen, was hat sich von "was" auf "was" und/oder von "wann" auf "wann" geändert?
Läuft SCR nun besser als mit 1.7.22 oder besser als eine der vorherigen Versionen mit Unicable-Patch?
Regards
fnu
Alles anzeigenMoin!
Bevor es in den vdr integriert wurde, war es der "LNB-Sharing-Patch".
Die Idee dahinter: Zwei (oder mehr) Tuner teilen sich ein Kabel, aber der LNB kann kein Unicable/SCR. Einer der Tuner wird der "Master", der die Diseqc-Kommandos an den LNB schickt, die anderen können dann alle Sender auf der gleichen Sat-Ebene empfangen.
Dadurch kann man in einer "limitierten" Umgebung schon ein bisschen mehr aufnehmen als mit nur einem Tuner.
Lars.
hi
danke fuer die erklaerung .
aehm kann man sowas nicht auch in verbindung mit dem ci slot machen ?
ich selber habe 2x dvb-c ( TT 1501 ) karten mit einem y-kabel ( naja ist eingentlich ein atennenverstaerker mit 1x in 2x out ) laufen aber nur 1x ci slot mit cam und smart card.
da ich das ding zum fernsehen und zum aufnehmen gleichzeitig nutzen moechte waehre es schon das die infos des ci slot fuer beide karten gueltig waehren .
irgendwie hat das auchmal zu .1.6 er zeiten funktioniert.( bie gleicher hardware ausstattung )
holger
Moin!
Das hilft nicht, wenn man eine DVB-C- und eine DVB-T-Karte hat und die DVB-C-Karte ein Hybridmodell ist.
Die Treiber haben so eine Option leider auch meistens nicht (hätte ich mir schon vor der API-Änderung gewünscht).
Genau da gehört diese Einstellung aber, finde ich, hin.
Wenn die Karte der Applikation meldet, daß sie DVB-C oder DVB-T kann, dann muß sie dieses "Versprechen" auch halten.
Wenn es von der Hardware her nicht möglich ist, beide Antennenkabel gleichzeitig anzuschließen (man also sowieso nur *eine* der beiden Varianten nutzen kann), dann macht es wenig Sinn, wenn der Applikation gesagt wird, daß beide Systeme empfangen werden können.
Ich schlage also vor, in den jeweiligen Treiber eine entsprechende Option einzubauen.
Zitat
So langsam wird die Device-Verwaltung im vdr sehr anspruchsvoll... Ich würde mir eine Konfiguration über udev wünschen, aber ich weiß nicht, was du von einer Abhängigkeit von libudev hälst.
Wenig - um nicht zu sagen *gar nichts*
Zitat
Das hätte dann aber auch den Vorteil, dass eine Änderung der Reihenfolge der Karteninitialisierung nicht gleich den ganzen vdr aus der Bahn wirft.
Wieso müsste hierfür denn VDR von libudev "abhängig" sein?
Ich dachte, mit UDEV-Regeln wird bestimmt, in welcher Reihenfolge die Devices erzeugt werden. VDR benutzt sie halt dann in der vorgefundenen Reihenfolge (ohne irgend etwas von "UDEV" zu wissen).
Klaus
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
