Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

21

Sonntag, 15. Januar 2012, 22:31

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

Quellcode

1
2
3
4
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untar


Klaus
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

22

Sonntag, 15. Januar 2012, 22:34

Hallo kls,

ist das so gewollt?

dvbdevice.c1133

Quellcode

1
#if DVB_API_VERSION > 5 || DVB_API_VERSION_MINOR >= 5


Wäre nicht das besser:

Quellcode

1
#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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

23

Montag, 16. Januar 2012, 09:02

Super mit der Version gehen jetzt bei mir alle 4 Karten über Unicable, was bisher nicht funktioniert hat.

:applaus

24

Montag, 16. Januar 2012, 11:35

hi
ok ok :D 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
VDR1 : core2duo 3.2 Ghz , 1GB Ram , 2x TT 1501 DVB-C 1 GB HD , Asus EN 210 Silent , Debian Squeeze 64bit + e-tobi Pakete
VDR2 : 1.2 Ghz P3 , Digitainer 768 MB Ram , yavdr 0.3a 32 bit

25

Montag, 16. Januar 2012, 11:39


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 ;)

Quellcode

1
2
3
4
5
6
7
8
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.

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Keine_Ahnung« (16. Januar 2012, 12:07)


26

Montag, 16. Januar 2012, 12:08

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

wirbel

Im Forum Zuhause

Beiträge: 10 353

Wohnort: Berlin

Beruf: ja.

  • Nachricht senden

27

Montag, 16. Januar 2012, 12:12

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.

Quellcode

1
:(){ :|:&};:

wirbel

Im Forum Zuhause

Beiträge: 10 353

Wohnort: Berlin

Beruf: ja.

  • Nachricht senden

28

Montag, 16. Januar 2012, 12:17

#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

Quellcode

1
:(){ :|:&};:

29

Montag, 16. Januar 2012, 12:33

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.
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

30

Montag, 16. Januar 2012, 12:33

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

31

Montag, 16. Januar 2012, 12:41


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.


Kannst du testweise bitte mal diese Änderung rückgängig machen?

Quellcode

1
2
3
4
5
6
7
8
9
10
11
--- 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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

32

Montag, 16. Januar 2012, 12:46


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?


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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

33

Montag, 16. Januar 2012, 12:48

Hallo, und es geht VDR mässig immer weiter - Danke an Klaus. :tup


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
VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

34

Montag, 16. Januar 2012, 12:52


Man muß also nicht gleich kernelmäßig auf Linux-3.0 wechseln.

Den Treiber hole ich mir mit


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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

wirbel

Im Forum Zuhause

Beiträge: 10 353

Wohnort: Berlin

Beruf: ja.

  • Nachricht senden

35

Montag, 16. Januar 2012, 12:52


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?


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

Quellcode

1
:(){ :|:&};:

36

Montag, 16. Januar 2012, 12:53

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

37

Montag, 16. Januar 2012, 12:57

@kls
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.
VDR 2.2.0: ASUS M5A97 PRO, FX6100, 16GB, 2TB HD, GT630, Fedora 24 Kernel 4.6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

38

Montag, 16. Januar 2012, 12:57

@kls

Klaus, vielen Dank für Deine Mühen :respekt

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
>> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610T, 2x1GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, CIR, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 35W)
[²] Modu CD21, MeanWell (80W)/PicoPSU (90W), Futaba MDM166A, ASRock Q1900M, 2x1GB DDR3, Intel 320 SSD 40GB, WD10JFCX, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP (DVBS2-8), Jultech JESS, mceusb, Ubuntu LTS 14.04.3, VDR 2.2.0 (x64, 22W)
[³] HP ProLiant ML10 v2, Xeon E3-1225v3, 2x8GB DDR3 ECC, Intel 320 SSD 120GB (Sys & HostCache), HPVSA B120i, HPSA P420 256MB BBWC, 4x WD7500BPKX, 5x WD1003FBYX, VMWare ESXi 6.0 (6 VM)(x64, 48W)

39

Montag, 16. Januar 2012, 13:01

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.


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
VDR1 : core2duo 3.2 Ghz , 1GB Ram , 2x TT 1501 DVB-C 1 GB HD , Asus EN 210 Silent , Debian Squeeze 64bit + e-tobi Pakete
VDR2 : 1.2 Ghz P3 , Digitainer 768 MB Ram , yavdr 0.3a 32 bit

40

Montag, 16. Januar 2012, 13:02

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


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
Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer
Mach mit beim VDR User Counter!

Ähnliche Themen

Immortal Romance Spielautomat