[ANNOUNCE] VDR developer version 1.7.23

    Zitat von kamel5

    kls


    Ich habe diese Änderung rückgängig gemacht.
    Ja, damit sieht es wieder so aus wie bisher.


    OK. Ich habe die Änderung für die 1.7.24 wieder rückgängig gemacht.


    Der Patch stammte von sundararaj.reel@googlemail.com und hat auf mich eigentlich plausibel gewirkt:



    Klaus

    @Klaus: Magst du hier mal reinschauen? Tastatur im VDR ist deutsch erzeugt aber keine Umlaute


    Soweit ich das jetzt sehe ist da ganz einfach nen Bug im VDR, auf nem utf-8 System gehen bei der Tastatureingabe keine Umlaute mehr.


    Ich habs zwar auf dem 1.6er getestet, aber so wie ich das sehe ist das im 1.7.23 auch nicht anderst.


    Kannst du das besätigen/Nachvollziehen/auf die known Bugs Liste setzen?


    cu

    Moin!


    Zitat von kls

    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.


    Ich bin da einer Meinung mit dir. Bis jetzt ist dieser Gedankengang noch nicht so richtig auf fruchtbaren Boden bei linux-media gefallen...
    Ich seh schon, zumindest für meine Karten muss ich dann jetzt doch mal in die Treiberprogrammierung einsteigen. :)


    Zitat von kls

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


    Ja, das ist richtig, aber das Auswerten dieser Einstellungen ist mit libudev schöner als quer durch sysfs zu lesen/parsen usw..


    Ich werde mal sehen, was der Treiber so hergibt. Oder vielleicht hat UFO ja auch Lust dazu, der hat ja Ahnung von den Cine-C/T-Karten.


    Lars.

    Zitat von Keine_Ahnung

    @Klaus: Magst du hier mal reinschauen? Tastatur im VDR ist deutsch erzeugt aber keine Umlaute


    Soweit ich das jetzt sehe ist da ganz einfach nen Bug im VDR, auf nem utf-8 System gehen bei der Tastatureingabe keine Umlaute mehr.


    Im letzten Posting dieses Threads heißt es


    Zitat von Keine_Ahnung


    Edit: Jup, auf de_DE@euro gehts.


    Bedeutet das, daß damit der Fehler nicht mehr auftritt?


    Klaus

    Zitat von kls


    Im letzten Posting dieses Threads heißt es



    Bedeutet das, daß damit der Fehler nicht mehr auftritt?


    Genau, mit de_DE@euro (allgemein auf allen "nicht utf-8" Systemen) geht alles wie es soll.


    Das Problem ist einfach das die Zeichen so genommen werden wie sie über die Konsole reinkommen. Läuft der VDR (oder besser die darunter liegende Konsole) auf "nicht utf-8" kommt für "ä" ein 0xE4 rein. Läuft er auf uft-8 kommt die utf-8 Sequenz 0xC3 0xA4 rein (und das erzeugt aktuell 2 Tastendrücke die keinen Sinn ergeben), was am Ende auch 0xE4 ergibt wenn mans utf-8 dekodiert. http://de.wikipedia.org/wiki/Utf-8#Kodierung


    Hier müsste die utf-8 Sequenz also dekodiert werden wenn der VDR auf utf-8 läuft.


    cu

    Zitat von kls

    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.


    Dieser Argumentation kann ich nicht so ganz folgen:
    Wieso sollte sich der Treiber dafür interessieren, was wo angeschlossen ist?
    Die Zuordnung "Signal -> Karte" ist Sache der Anwendung.


    Bei SAT kann man ja bereits verschiedene DiSEqC- /SCR-Einstellungen den Karten zuordnen.


    Genauso sollte es möglich sein, ein bestimmtes DVB-T bzw. DVB-C Signal einer Karte zuzuordnen.
    Eine Treiberoption für DVB-T-only oder DVB-C-only ist eine Krücke. So, als wollte man per Treiberparameter SAT-Positionen festlegen.


    Ähnlich wie bei SAT kann man theoretisch z.B. auch 2 verschiedene DVB-T Signale haben, die an eigene Frontends angeschlossen sind. Spätestens dies ist nicht mehr per Treiberoption zu machen.


    CU
    Oliver


    Da kann ich nun wieder nicht so ganz folgen ;)


    Der Treiber sagt der Applikation, welche Systeme die Karte kann, also ob DVB-S, -C oder -T.
    Natürlich sagt er bei DVB-S nichts darüber aus, welche Satelliten damit empfangbar sind. Das hängt ja von diversen Parametern ab wie geographische Lage und Antennenausrichtung.
    Genausowenig sagt er bei DVB-C oder -T etwas darüber aus, welche Kanäle man empfangen kann. Das hängt ja auch wieder vom Ort des Geschehens ab.
    Aber daß man bei einer Karte, von der der Treiber behauptet, sie könne DVB-T, auch tatsächlich DVB-T empfangen kann, wenn man das Frontend entsprechend konfiguriert, darauf sollte sich eine Applikation doch wohl verlassen können. Ansonsten macht es doch keinen Sinn, daß der Treiber auf Nachfrage sagt, die Karte kann DVB-T - und wenn's dann drauf ankommt, dann geht's doch nicht.


    Zitat


    Ähnlich wie bei SAT kann man theoretisch z.B. auch 2 verschiedene DVB-T Signale haben, die an eigene Frontends angeschlossen sind. Spätestens dies ist nicht mehr per Treiberoption zu machen.


    Das dürfte ja wohl ein höchst theoretischer Fall sein, denn normalerweise liegen die DVB-T-Frequenzen ja wohl so, daß man sie alle in ein Kabel zusammenmischen kann.


    Klaus


    Die Karte kann hardwaremäßig genau das, was sie behauptet: DVB-T und DVB-C.
    Sie kann jedoch nicht unterscheiden, ob am Kabel DVB-T, DVB-C oder eine Kombination von beiden anliegt.


    Zitat

    Das dürfte ja wohl ein höchst theoretischer Fall sein, denn normalerweise liegen die DVB-T-Frequenzen ja wohl so, daß man sie alle in ein Kabel zusammenmischen kann.


    Dann warten wir mal ab, bis dieser Fall auftritt. ;)


    CU
    Oliver

    Für mich ist das Fazit mit DVB-C vs. DVB-T soweit, dass wieder einmal selbstgebackene Patche in VDR einziehen müssen. *hmpf*


    Ansonsten folge ich durchaus der Argumentation von UFO, Parameter für Treiber sind eine Krücke. Insbesondere deswegen, weil normalerweise ein ANwender nicht in der modprobe.conf herum pfuscht und andererseits der Kernel selbst das Laden der Module übernehmen sollte.

    Moin!


    Tja, es gibt wie immer viele Lösungsmöglichkeiten für dieses Problem. Es fehlt vermutlich noch eine Schicht zwischen Treiber und Anwendung.
    Es gab z.B. auch einen SCR-Patch für den dvb-core, so dass die Karten entsprechend konfiguriert werden können und alle Anwendungen nichts über SCR wissen mussten. Es funktionierte "transparent" (ein schönes Wort).
    Das wurde aber mit dem Vermerk abgelehnt, dass es im Userspace umsetzbar ist - und deshalb nichts im Kernelspace zu suchen hätte.


    Irgendwie scheint es Zeit für eine libdvb zu sein, die sowas anwendungsunabhängig umsetzen kann. Dann muss es nicht in jeder Anwendung konfiguriert werden, sondern nur noch an einer Stelle. Das würde die Anwendungen und die Konfiguration vereinfachen.


    Aber ich will nicht abschweifen... Ob's dann "vdr-konform" zu anderen conf-Dateien doch eine Device-Nr-Zeile in sources.conf wird? Was für andere Ansatzpunkte gäbe es im vdr?


    Lars.

    Um das noch zu verkomplezieren ;) es wäre durchaus möglich die DVB-C/T Kombituner Karten gleichzeitig an einem DVB-T und einem DVB-C Signal anzuschliessen sofern man ein umschaltbares Antennenrelais nutzt. Und das könnte durchaus ein wünschenswerte Szenario sein (z.B. in Grenzregionen).


    cu

    Moin!


    Zitat von Keine_Ahnung

    Um das noch zu verkomplezieren ;) es wäre durchaus möglich die DVB-C/T Kombituner Karten gleichzeitig an einem DVB-T und einem DVB-C Signal anzuschliessen sofern man ein umschaltbares Antennenrelais nutzt. Und das könnte durchaus ein wünschenswerte Szenario sein (z.B. in Grenzregionen).


    Dann musst du aber noch ein Plugin schreiben, dass das Relais bei einem passenden Kanalwechsel umschaltet... :)
    Am "coolsten" wäre es, wenn die DVB-C/T-Karte 5V für aktive Antennen bereitstellen könnte und dieses dann auch per ioctl an- und abschaltbar wäre (wie die LNB-Spannung).


    Aber wir sollten nicht zu theoretisch werden, wir haben hier ein ganz konkretes Problem: Eine Hybrid-Karte meldet alle "denkbar mögliche" Empfangsarten, von denen aber nicht alle genutzt werden (können).


    Lars.

    Zitat von mini73


    Dann musst du aber noch ein Plugin schreiben, dass das Relais bei einem passenden Kanalwechsel umschaltet... :)


    Warum so kompleziert? Wenn der VDR das DVB-T Frontend aktiviert (das tut es ja aktiv, also ist hier der richtig Punkt) ruft er "<irgendein Shellscript was per Kommandozeile übergeben wurde> -T -D <device>" auf, aktiviert er das DVB-C Frontend dann "<irgendein Shellscript was per Kommandozeile übergeben wurde> -C -D <device>". Das Script schaltet dann um.


    Zitat von mini73


    Aber wir sollten nicht zu theoretisch werden, wir haben hier ein ganz konkretes Problem: Eine Hybrid-Karte meldet alle "denkbar mögliche" Empfangsarten, von denen aber nicht alle genutzt werden (können).


    Ich denke das ist durchaus praktisch relevant diesen Fall hier gleich mal mit zu beachten (kost ja nix ;) ). Sonst wirds später wieder überkompleziert per Plugin/Patch reingewürgt.


    Und das der VDR überhaupt eigenmächtig zwischen DVB-T/C Umschaltet macht ja überhaupt nur Sinn wenn der User irgendeine Möglichkeit hat beide Signale anzuschliessen. Und das geht ja nur mit irgendeinem Umschalter (der dann auch umgeschaltet werden muss).
    Alternativ kann der VDR den Nutzer natürlich auch per OSD darum bitten das Kabel umzustecken ;)



    Für das eigentliche Problem wäre es vermutlich am einfachsten wenn der VDR die Devices mit Unternummern hochzählen würde.
    1 ist die erste Sat Karte
    1.1 der erste Eingang der zweiten Dual Tuner Sat Karte
    1.2 der zweite Eingang der zweiten Dual Tuner Sat Karte
    2.1 der DVB-C Tuner der dritten DVB-C/T Hybrid
    2.2 der DVB-T Tuner der dritten DVB-C/T Hybrid


    Dann im VDR Setup
    Tuner 1 nutzen: <ja|nein>
    Tuner 1.1 nutzen: <ja|nein>
    Tuner 1.2 nutzen: <ja|nein>
    Tuner 2.1 nutzen: <ja|nein>
    Tuner 2.2 nutzen: <ja|nein>


    Das würde auch gleich die "ich kauf mir ne Dual Tuner Karte aber schliesse nur ein Kabel an" Fälle mit erschlagen.


    cu

    Ich hab grad mal nachgeschaut, der Aufwand für ne Konfiguration frontend + adapter versus delivery system wäre nicht sehr hoch.


    a) eine extra Konfigurationsdatei, z.B. sowas wie eine 'dvbdevice.conf'
    <adapter>:<frontend>:<delsys0>,..,<delsysN>


    b) ein Eingriff in cDvbDevice :: ProvidesDeliverySystem
    (Kombi adapter/frontend in .conf nicht vorhanden = Verhalten wie bisher)


    Mal sehn, ob sich sowas umsetzen lässt.

    Moin,


    Ich würde ein = zwischen Frontend und Auzählung nehmen, damit der Doppelpunkt keine doppelte Bedeutung hat.
    Ansonsten gefällt mir der Ansatz.


    Ich bau dann bei Gelegenheit eine udev-Variante für dynamite.
    Bei USB-Geräten kann die Nummerierung sich ja ändern.


    Lars.


    Das wird dann aber wohl ein "ewiger Patch" bleiben, denn mir gefällt das überhaupt nicht!


    Wenn ein Device grundsätzlich DVB-T und DVB-C kann, wegen fehlendem Antennenanschluß aber definitiv nur eines davon möglich ist, dann sollte es bitteschön auch nur dieses an VDR melden!


    Wobei mir gerade einfällt: wozu haben wir denn eigentlich die cDeviceHook?
    Wenn du unbedingt sowas einbauen willst, dann müsste das doch da drüber gehen, oder?
    Zumindest bleibt der Core-VDR dann verschont von einer weiteren Datei, in der Devices über Nummern konfiguriert werden müssen, und der Plugin-Autor kann das gestalten, wie er will.


    Klaus

    Zitat von kls

    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.


    Aber zumindest auf aktuelle DVB-Treiber. Ok, Powarman hat just-in-time auch die 5.3 API in seinen Treiber aufgenommen. Den verwende ich zusammen mit 2.6.32.


    Aber mein build-pc (VM) läuft mit dem originalen Debian 2.6.32 Kernel, und dabei soll es auch bleiben. Und nicht jeder hat die allerneueste Hardware, und braucht dafür die allerneuesten DVB-Treiber. Es soll auch DVB-Hardware geben, die von älteren Kerneln voll unterstützt wird...



    Zitat von Keine_Ahnung

    Was spricht denn dagegen den Patch von Urig mit in den VDR zu übernehmen?


    Ich hab kein Problem damit, dass das ein Patch ist. VDR - insbesondere die Entwicklerversionen - sollten sich nach vorne orientieren, und nicht Kompatibilität für uralte APIs mitschleppen. Der Patch beinhaltet noch immer die Unterstützung für DVB V3 API, und das ist wirklich schon aus jeder Distribution verschwunden...



    Zitat von kls

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


    Das ist eins der Probleme: udev benennt nur die Devices um, ändert aber nicht die eigentliche Device-Nummer. Da VDR aber über die Device-Nummer unter /sys nachschlägt, geht das dann schief, wenn /dev/dvb/adapterX nicht mehr zu /sys/class/dvb/dvbX passt. Udev-Regeln funktionieren daher nicht.
    Alternativ könnte man entweder VDR beibringen, symlinks zu interpretieren, z.b. /dev/dvb/primary -> /dev/dvb/adapter2 zu verfolgen, oder die Device-Nummer aus der device node Nummer zu interpretieren, was aber auch gewagt ist.


    Gruß,


    Udo

    Zitat von Urig


    Das ist eins der Probleme: udev benennt nur die Devices um, ändert aber nicht die eigentliche Device-Nummer. Da VDR aber über die Device-Nummer unter /sys nachschlägt, geht das dann schief, wenn /dev/dvb/adapterX nicht mehr zu /sys/class/dvb/dvbX passt. Udev-Regeln funktionieren daher nicht.
    Alternativ könnte man entweder VDR beibringen, symlinks zu interpretieren, z.b. /dev/dvb/primary -> /dev/dvb/adapter2 zu verfolgen, oder die Device-Nummer aus der device node Nummer zu interpretieren, was aber auch gewagt ist.


    Wieso packt eigentlich nicht mal jemand dieses Übel bei der Wurzel?
    Es müsste doch wohl auch möglich sein, das alles von vorneherein richtig zu benennen, so daß es auch vernünftig zusammenpasst, oder?


    Klaus

    Moin!


    Zitat von kls

    Wieso packt eigentlich nicht mal jemand dieses Übel bei der Wurzel?
    Es müsste doch wohl auch möglich sein, das alles von vorneherein richtig zu benennen, so daß es auch vernünftig zusammenpasst, oder?


    Zum Teil bin ich da schon bei. Mit dynamite ist es z.B. möglich, bestimmten Karten feste "vdr-Nummern" zuzuordnen. Das ist die kleine Variante.
    Die große Variante wäre, noch mehr nach udev zu verlagern, aber das könnte zu viel werden. Ich bin da noch am Testen.


    Und dynamite hat noch ein paar andere Probleme, aber die werden auch noch irgendwann gelöst... :)


    Lars.

    Es gibt auch Nutzer, die keinen Bedarf an Device-Hotplug haben, aber dennoch so eine DVB-Karte betreiben wollen.


    Der korrekte Weg wäre, es irgendwie von Treiberseite her zu lösen. Schon weil man so eine Karte "systemweit" umschalten könnte. Wenn die also in einem Desktop verbaut ist, dann könnte ich beliebig zwischen kaffeine, xine, mplayer und vlc wechseln und hätte dennoch immer die passende Konfiguration.


    Als Parameter am Modul bringt es aber nicht viel. Es sei denn man kann den Parameter mehrfach übergeben und dabei irgendeine Kennung der Karte übergeben. Den Fall, dass die gleiche Karte einmal für DVB-T und einmal für DVB-C verbaut wird, ist nämlich nicht unwahrscheinlich.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden