[ANNOUNCE] VDR developer version 1.7.23

Zitat von mini73

Moin!

Zum Teil bin ich da schon bei. Mit dynamite ist es z.B. möglich, bestimmten Karten feste "vdr-Nummern" zuzuordnen.

Mit "das Übel bei der Wurzel packen" meinte ich natürlich, es im Treiber zu lösen, nicht in den Applikationen rumzufrickeln

Klaus

Na im Treiber wird das niemand lösen.

Wie UFO schon sagte: der Treiber und die hardware können ja beides. Und Treiber Optionen sind nur ein *anderer* Hack.

Moin!

Zitat von Mreimer

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

Das ist ja auch nur ein Beispiel. Ich selbst habe auch eine Cine-C/T, die ich nur als DVB-C betreiben möchte (unabhängig von dynamite).
Ich wollte damit nur ausdrücken, dass ich mich schon eine Weile mit dem Thema beschäftige.

Lars.

Neben Device Hotplug kann dynamite auch udev, IMHO etwas was direkt in den VDR gehören würde. Wenn VDR sogar schon sysfs verwendet, dann ist das nach meinem Verständnis bereits ein Teil von udev - warum nicht gleich "richtig" ?

Bezgl der Deliverysystems (auch wenn ich nicht betroffen bin):
Möglichkeit 1: Im Kernel: Begrenzung über Moduloptionen
Möglichkeit 2: Aus dem Userspace, dann muss der Treiber/die DVB API einen Befehl bereitstellen der die Deliverysystems aus dem Userspace setzen/begrenzen kann. Dann kann man das aus der Applikation oder über udev/einen udev-Helper handhaben.

Für mich klingt 2.) besser. Was richtig schlecht wäre, dem VDR sagen zu müssen was wo geht (und jeder anderen Anwendung)

Moin!

Zitat von kls

Mit "das Übel bei der Wurzel packen" meinte ich natürlich, es im Treiber zu lösen, nicht in den Applikationen rumzufrickeln

Naja, da treffen jetzt zwei Philosophien aufeinander.

Der Treiber meldet die Fähigkeiten der Hardware.
Der User möchte aber nur einen Teil davon (mit einer Applikation) nutzen.

Wo sollen wir das konfigurieren?
Es ist möglich, den Treiber zu manipulieren, damit er nur beschränkte Fähigkeiten meldet. Aber was passiert, wenn man mehrere Karten des gleichen Treibers hat, die unterschiedlich genutzt werden sollen?
Es ist möglich, die Anwendung zu manipulieren, damit sie nur das nutzt, was der Nutzer will. Problem ist hierbei evtl. eine Zuordnung zu den Device-Nummern, weil die sich ändern können, wenn die Treiber in einer anderen Reihenfolge geladen werden. Da kommt meiner Meinung nach udev ins Spiel. Um udev aber besser nutzen zu können, wären Seriennummern bei den Geräteeigenschaften sehr vorteilhaft. Denn es ist immer wieder ein Problem, die Karten eindeutig zu identifizieren.
Bei der Cine-C/T geht es z.B. nicht über den PCI-Slot (udev: KERNELS), weil da zwei Karten in einem Slot stecken.

Oder wir bauen eine Schicht dazwischen, die von allen Anwendungen genutzt wird/werden muss, und da wird konfiguriert. Diese gibt es aber noch gar nicht.

Ich bin für Vorschläge offen...

Lars.

Moin!

Zitat von steffen_b

Möglichkeit 2: Aus dem Userspace, dann muss der Treiber/die DVB API einen Befehl bereitstellen der die Deliverysystems aus dem Userspace setzen/begrenzen kann. Dann kann man das aus der Applikation oder über udev/einen udev-Helper handhaben.

Für mich klingt 2.) besser. Was richtig schlecht wäre, dem VDR sagen zu müssen was wo geht (und jeder anderen Anwendung)

Dann müsste man also zwei ioctls unterscheiden: Was die Hardware kann (das neue ENUM_DELSYS) und was der Nutzer von der Hardware nutzen will (gibt's noch nicht). Bleibt aber immer noch, das irgendwo definiert werden muss, was der Nutzer will...
Ich wäre auch glücklich über eine anwendungsunabhängig Lösung...

Lars.

Es gibt eine einfache vorläufige Lösung.

VDR muß einfach auch die anderen Eingänge verwenden, wenn der erste Fehlschlägt. Dann dauert das Umschalten etwas länger, aber die Aufnahmen werden sicherer.
(Wackelkontakt oder Katze)

Johns

Zitat von mini73

Dann müsste man also zwei ioctls unterscheiden: Was die Hardware kann (das neue ENUM_DELSYS) und was der Nutzer von der Hardware nutzen will (gibt's noch nicht).

Die Anwendung interessiert nur, was der Nutzer will. IMHO wäre es also durchaus legitim, wenn eine Karte, die eigentlich auch DVB-C kann, dies auf Wunsch des Nutzers nicht an die Anwendungen kundtut.

Zitat

Bleibt aber immer noch, das irgendwo definiert werden muss, was der Nutzer will...
Ich wäre auch glücklich über eine anwendungsunabhängig Lösung...

Schafft man es von udev her eine Info zum Treiber (Kernel-Modul) zu übermitteln? Mit einer passend gebauten udev-Rule sollte man das Device eindeutig separieren können.

Hi,

so etwas gehört nicht in den Treiber. Eine Funktion, um dem Treiber zu sagen, er soll ab jetzt Delivery System XYZ unterdrücken, ist doch völlig unsinnig!

Etwas wie eine libdvb wäre eine universelle Möglichkeit, aber so etwas gibt es halt derzeit nicht.

Eine einfache Lösung wäre ein Plugin, das - wie Klaus oben erwähnte - die Funktion über cDeviceHook::DeviceProvidesTransponder realisiert.

Imho eine elegante Lösung. Und wer die Funktion nicht benötigt, lädt einfach das Plugin nicht.

CU
Oliver

Moin!

Zitat von johns

VDR muß einfach auch die anderen Eingänge verwenden, wenn der erste Fehlschlägt. Dann dauert das Umschalten etwas länger, aber die Aufnahmen werden sicherer.
(Wackelkontakt oder Katze)

Ein Fallback auf ein anderes Device im Falle eines "broken video stream" ist sicherlich ein tolles Feature, hat aber nichts mit diesem Problem zu tun, denke ich.

Lars.

Moin!

Zitat von Mreimer

Die Anwendung interessiert nur, was der Nutzer will. IMHO wäre es also durchaus legitim, wenn eine Karte, die eigentlich auch DVB-C kann, dies auf Wunsch des Nutzers nicht an die Anwendungen kundtut.

Ich denke nicht, dass ein Treiber nur das melden sollte, was den Nutzer interessiert. Mal übertrieben gesagt: Soll der Treiber für den SATA-Controller nur die Partitionen melden, die den Nutzer interessieren? Klingt irgendwie falsch. Außerdem weiß der Treiber das überhaupt nicht.

Zitat von Mreimer

Schafft man es von udev her eine Info zum Treiber (Kernel-Modul) zu übermitteln? Mit einer passend gebauten udev-Rule sollte man das Device eindeutig separieren können.

Andersherum: der Treiber kann Variablen an udev geben, so dass Anwendungen diese auswerten können. Siehe "udevadm info --query=all --name=/dev/dvb/adapter0/frontend0".
Bei USB-Geräten gibt's z.B. häufig eine Seriennummer, weil die meistens in USB-Geräten zur Verfügung gestellt wird. Das ist bei PCI(e)-Karten meistens nicht der Fall. Das ist ja das Problem.

Lars.

Moin!

Zitat von UFO

Eine einfache Lösung wäre ein Plugin, das - wie Klaus oben erwähnte - die Funktion über cDeviceHook::DeviceProvidesTransponder realisiert.
Imho eine elegante Lösung. Und wer die Funktion nicht benötigt, lädt einfach das Plugin nicht.

Ja, das ist für den vdr eine gute Lösung.

Es bleibt aber das Problem, wie man die Karten am besten eindeutig identifizieren kann. Da komme ich wieder auf meine Bitte zurück, zumindest bei den Cine-Karten irgendwie die TAP-Nummer o.ä. per udev an den Userspace zu melden.
Ansonsten kann nur die Adapternummer als Kriterium genommen werden, und die ist nicht eindeutig, falls die Treiber mal in einer anderen Reihenfolge (oder auch während des Betriebs neu-)geladen werden.

Lars.

Ich sehe nicht, daß das nicht in den Treiber gehört, da die Hardware unter bestimmten Umständen ja augenscheinlich ein bestimmtes Delivery System nicht unterstützen kann. DVB-S/S2 ist kein guter Vergleich, da an einem Kabel die verschiedenen Satelliten hängen können. Sei's drum - zum einen bin ich nicht betroffen, zum anderen bin ich nicht involviert - ich hätte halt gerne eine Lösung gesehen die für die Betroffenen funktioniert ohne jetzt einen großen Aufriß darüber zu machen.

Zitat von johns

Es gibt eine einfache vorläufige Lösung.

VDR muß einfach auch die anderen Eingänge verwenden, wenn der erste Fehlschlägt. Dann dauert das Umschalten etwas länger, aber die Aufnahmen werden sicherer.
(Wackelkontakt oder Katze)

Johns

Die Idee finde ich sehr gut, VDR startet eine Aufnahme quasi auf allen freien Devices, und überprüft dann nach den bisherigen Kriterien nach einander ab bis ein gültiger Stream gefunden wurde, das geht in die Datei, der Rest wird wieder frei gegeben.

Zitat von UFO

Etwas wie eine libdvb wäre eine universelle Möglichkeit, aber so etwas gibt es halt derzeit nicht.

Eine einfache Lösung wäre ein Plugin, das - wie Klaus oben erwähnte - die Funktion über cDeviceHook::DeviceProvidesTransponder realisiert.

Zitat von mini73

Ja, das ist für den vdr eine gute Lösung.

Ja, eine "libdvb" wäre eine gute Idee, aber dabei wird es wohl auch erstmal bleiben, es sei denn man löst sich IMHO von "linuxtv". Aber diesen Part könnte "vdr-plugin-dynamite" für und als Teil des VDR übernehmen. Auch wenn es leider wieder die typischen Unken-Rufe gibt, nicht jeder braucht dynamische Devices, würde es niemanden zwingen die dynamischen Fähigkeiten nutzen zu müssen, wenn im Gegenzug die DVB Devices so zur Verfügung stehen, wie man sie im VDR benötigt und zwar für alle Nutzer.

Zitat von steffen_b

Ich sehe nicht, daß das nicht in den Treiber gehört,

Das sehe ich auch so, die möglichen Fähigkeiten eines Geräts müssen vom Treiber gemeldet werden bzw. abfragbar sein. Wie man diese Fähigkeiten nutzt, muss von der Applikation entschieden werden bzw. konfiguriert werden.

Regards
fnu

Zitat von fnu

Das sehe ich auch so, die möglichen Fähigkeiten eines Geräts müssen vom Treiber gemeldet werden bzw. abfragbar sein. Wie man diese Fähigkeiten nutzt, muss von der Applikation entschieden werden bzw. konfiguriert werden.

"Doppelte Verneinung" im Zitat übersehen?

Klaus

Zitat von kls

"Doppelte Verneinung" im Zitat übersehen?

Hmm, nein, ich für mich habe die Aussage so verstanden, aber wohl zu kurz zitiert

Regards
fnu

Zitat von Urig

Der Patch beinhaltet noch immer die Unterstützung für DVB V3 API, und das ist wirklich schon aus jeder Distribution verschwunden...

Würde es bei DVBAPI 5.2 reichen, wenn ich einfach eine aktuelle frontend.h in den VDR include, ansteller der, die im Kernel liegt?

Zitat von kamel5

Hallo kls,

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.

Alles anzeigen

Kannst du bitte mal folgenden Patch testen?

--- ./device.c  2011/10/16 14:36:43     2.44
+++ ./device.c  2012/01/17 15:28:57
@@ -531,6 +531,14 @@
   return false;
 }


+void cDevice::DelLivePids(void)
+{
+  for (int i = ptAudio; i < ptOther; i++) {
+      if (pidHandles[i].pid)
+         DelPid(pidHandles[i].pid, ePidType(i));
+      }
+}
+
 void cDevice::StartSectionHandler(void)
 {
   if (!sectionHandler) {
--- ./device.h  2011/12/04 13:38:17     2.30
+++ ./device.h  2012/01/17 15:13:10
@@ -354,6 +354,9 @@
          ///< Handle->used indicates how many receivers are using this PID.
          ///< Type indicates some special types of PIDs, which the device may
          ///< need to set in a specific way.
+public:
+  void DelLivePids(void);
+         ///< Deletes the live viewing PIDs.


 // Section filter facilities


--- ./dvbdevice.c       2012/01/16 12:52:01     2.58
+++ ./dvbdevice.c       2012/01/17 15:16:12
@@ -502,6 +502,8 @@
      tunerStatus = tsIdle;
      ResetToneAndVoltage();
      }
+  if (bondedTuner && device->IsPrimaryDevice())
+     cDevice::PrimaryDevice()->DelLivePids(); // 'device' is const, so we must do it this way
 }


 bool cDvbTuner::Locked(int TimeoutMs)

Klaus

kls

Zitat von kls

Kannst du bitte mal folgenden Patch testen?

Diff

--- ./device.c  2011/10/16 14:36:43     2.44
+++ ./device.c  2012/01/17 15:28:57
@@ -531,6 +531,14 @@
   return false;
 }


+void cDevice::DelLivePids(void)
+{

Ich habe den Patch getestet.

Das sichtbare Verhalten des VDR unterscheidet sich jetzt nicht mehr vom ursprünglichen LNB-Sharing-Patch.
Beim Start einer Aufnahme mit anderer Polarisation oder Band gibt es jetzt eine entsprechende Meldung und nach kurzer Zeit schaltet er dann die Live-Darstellung auf den Aufnahmekanal um.

Aus meiner Sicht kann damit das Thema Device-Bonding erst einmal als OK betrachtet werden, weitere Fehlermeldungen natürlich nicht ausgeschlossen .

Vielen Dank nochmal für die schnellen Lösungen.

Gruß
Karl