You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

21

Sunday, January 15th 2012, 10:31pm

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

Source code

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

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

22

Sunday, January 15th 2012, 10:34pm

Hallo kls,

ist das so gewollt?

dvbdevice.c1133

Source code

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


Wäre nicht das besser:

Source code

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

23

Monday, January 16th 2012, 9:02am

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

:applaus

mark05

Intermediate

Posts: 351

Location: Köln

  • Send private message

24

Monday, January 16th 2012, 11:35am

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

Monday, January 16th 2012, 11:39am


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

Source code

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

This post has been edited 3 times, last edit by "Keine_Ahnung" (Jan 16th 2012, 12:07pm)


mini73

Moderator

Posts: 6,213

Location: Flensburg

  • Send private message

26

Monday, January 16th 2012, 12:08pm

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

Posts: 9,944

Location: Berlin

  • Send private message

27

Monday, January 16th 2012, 12:12pm

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.

wirbel

Im Forum Zuhause

Posts: 9,944

Location: Berlin

  • Send private message

28

Monday, January 16th 2012, 12:17pm

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

Quoted

#if (DVB_API_VERSION *100 + DVB_API_VERSION_MINOR) >= 505

29

Monday, January 16th 2012, 12:33pm

Hallo kls,

Quoted

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

Quoted

- 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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.17.2 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

mini73

Moderator

Posts: 6,213

Location: Flensburg

  • Send private message

30

Monday, January 16th 2012, 12:33pm

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

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

31

Monday, January 16th 2012, 12:41pm


Quoted

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

Source code

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

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

32

Monday, January 16th 2012, 12:46pm


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

rudirabbit

Professional

Posts: 1,357

Occupation: Kfz Elektroniker

  • Send private message

33

Monday, January 16th 2012, 12:48pm

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

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

34

Monday, January 16th 2012, 12:52pm


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

Quoted


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

wirbel

Im Forum Zuhause

Posts: 9,944

Location: Berlin

  • Send private message

35

Monday, January 16th 2012, 12:52pm


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.

Quoted


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

mini73

Moderator

Posts: 6,213

Location: Flensburg

  • Send private message

36

Monday, January 16th 2012, 12:53pm

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

Monday, January 16th 2012, 12:57pm

@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.1.6: ASUS M5A97 PRO, FX6100, 16GB, 800GB HD, GT630, Fedora 20 Kernel 3.17.2 X86_64, Devicebonding 2 x 1 auf 2, TT6400, Hauppauge Nova HD-S2, SkyStar HD2

fnu

Moderator

Posts: 8,466

Location: Böblingen

  • Send private message

38

Monday, January 16th 2012, 12:57pm

@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
Gib HD+/CI+ keine Chance! >> HowTo: APT Pinning <<

>>click<< for my VDR stuff

[¹] Modu CD21, MeanWell (80W)/LC-Power (75W), Futaba MDM166A, Intel DH77EB, G1610, 4GB DDR3, Intel 313 SSD 24GB, WD20EFRX 2TB, Zotac GT630 ('GK208'), SHDD, L4M Twin S2 (V5.6)/FlexS2 (4x DVB-S2), rt Unicable®, CIR, Ubuntu LTS 12.04.4, VDR 2.1.6 (x64, 44W)
[²] Modu CD21, MeanWell (80W)/PicoPSU (90W), Futaba MDM166A, ASRock Q1900M, 2GB DDR3, Intel 320 SSD 40GB, WD10JFCX, Palit GT630 ('GK208'), SHDD, Octopus Net SAT>IP, rt Unicable®, mceusb, Ubuntu LTS 14.04, VDR 2.1.6 (x64, 22W)
[³] Cooler Master Elite 360, Xilence SPS-XP250.SFX (250W), Intel DH77KC, Xeon E3-1245v2, 8GB DDR3, Intel 313 SSD 24GB (Sys & HostCache), HP SA P400 256MB BBWC, 4x WD7500BPKX@Backplane, VMWare ESXi 5.5 (6 VM)(x64, 38W)

mark05

Intermediate

Posts: 351

Location: Köln

  • Send private message

39

Monday, January 16th 2012, 1:01pm

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

kls

Master

Posts: 2,683

Location: Mettenheim

  • Send private message

40

Monday, January 16th 2012, 1:02pm

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.

Quoted


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

Quoted


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

Similar threads