Beiträge von kls

Zitat von johns

Passt zwar nicht zum Announce, aber ich habe keinen besseren Platz gefunden.

Ich glaube ich habe einen Bug:

cDevice:: SetVideoDisplayFormat wird nur beim Kanalwechsel aufgerufen.

Das ist so nicht ganz richtig. Es wird aufgerufen, wenn ein cPlayer sich beim Ausgabedevice abmeldet, um wieder das Default-Format für den Live-Modus einzustellen.

Zitat

Beim ersten Kanal kommt nichts.

Es wird nur von cDevice::Detach aufgerufen, ich würde ja vermuten es sollte in cDevice::AttachPlayer

Die Anfangs-Einstellung erfolgt im Konstruktor von cDvbSdFfDevice durch den Aufruf von

SetVideoFormat(Setup.VideoFormat);

Klaus

Zitat von wla

Hallo Klaus,

habe sowohl das Plugin als auch die Firmware gerade aktualisiert.
Das Verhalten ist immer noch gleich. Es wird aufgenommen, kann aber nicht wiedergegeben werden, VLC gibt aber die Aufnahme problemlos wieder.
Aufnahmen anderer Sender lassen sich problemlos wiedergeben. Das ganze auf zwei VDRs.

Die Version des VDR ist 1.7.19, kann es noch daran liegen?
Werde wohl nicht drumrumkommen dies zu testen

Ach ja, der relevante log-Auszug:
...
Feb 10 20:01:34 vdr vdr: [4389] unknown frame delta (-255210127), assuming 25.00 fps
...

Grüße
Walter

Alles anzeigen

Die Zeile

unknown frame delta (-255210127), assuming 25.00 fps

deutet darauf hin, daß VDR die Frames nicht richtig erkennt.
Probier's mal mit der aktuellen Developer-Version, denn seit der 1.7.19 hat sich da noch was getan.

Klaus

Zitat von wla

Hallo,

kann dies jemand bestätigen bzw. funktioniert es bei jemand?
TT S2-6400, getestet auf zwei (allerdings identischen) VDRs an unterschiedlichen Standorten

Live funktioniert SIXX einwandfrei
SIXX;ProSiebenSat.1:12460:hC34M2O0S0:S19.2E:27500:767=2:768=deu@3:35:0:776:133:5:0

Aufnahmen können in VDR aber nicht abgespielt werden. Sie lassen sich mit VLC aber problemlos abspielen.
Dieses Problem besteht nur beim Sender SIXX.

Alles anzeigen

Hab's gerade mal getestet und konnte eine Aufnahme von diesem Kanal problemlos mit der TT S2-6400 abspielen.
Ich verwende das aktuelle Plugin von http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice und die neueste
Firmware von http://aregel.de.

Klaus

Zitat von Mreimer

...
Zudem hat kls zugesagt, einen Patch zu übernehmen, sofern dieser *ein* zusätzliches Verzeichnis implementiert.

Na ja, ich habe gesagt "Wenn's denn bei einem weiteren Directory bleibt ;-)".
Das war mehr eine Vermutung, daß es nicht bei einem Directory bleiben dürfte, als eine Zusage einen entsprechenden Patch zu übernehmen.
Aber warten wir erstmal ab. Meine Vorhersage ist eh, daß es keine brauchbare Einigung geben wird

Klaus

Zitat von Keine_Ahnung

Das "K" kommt von nem VDR Patch den das restfulapi Plugin nutzt. Hier werden Metainfos (Das was sonst im EPG Text unter "<key>: <value>" gespeichert wird) gespeichert.

Von dieser 'K'-Erweiterung habe ich noch nie was gehört.
Ich finde es nicht gut, eine so zentrale Schnittstelle wie die EPG-Datenstruktur einfach nach Belieben zu verändern

Klaus

Zitat von sewn4

Hallo zusammen,

mir ist eben was aufgefallen. Und zwar wenn ich eine Direktaufnahme starte dann wird das aktuelle TV Bild für ca. 2-3 Sekunden schwarz sprich Bild und Ton sind weg. Danach kommt das TV Bild mit Ton wieder. Ist das noch ein "Bug" oder ist das Works As Designed? Ich habe beide Tuner angeschlossen...das "Problem" lässt sich bei mir nachstellen.

Hab's eben mal probiert, aber bei mir tritt das nicht auf.
Erst wenn ich eine weitere Aufnahme auf einem anderen Transponder starte (und nur die beiden Devices der TT S2-6400 benutze), dann wird das Bild kurz dunkel. Das kommt daher, daß VDR dann das Live-Signal in den "Transfer-Mode" schaltet.

Kann es sein, das an deinem zweiten Device ein Receiver hängt, der es blockiert?
Probier's mal ohne jegliche andere Plugins.

Klaus

Zitat von Maniac

Ok

Hätte den so ein Patch, wenn er vernünftig gebaut ist, die Chance in den VDR zu kommen?
Als default würde ich dann setzen das alles so bleibt wie der VDR es derzeit macht. Die User/Distributionen können über einen weiteren Parameter oder die Make.config dieses Verhalten dann ändern. Plugins würden die Möglichkeit bekommen das neue Verzeichnis über eine ähnliche Funktion wie cPlugin::ConfigDirectory() abfragen und dann nutzen.

Wenn's denn bei einem weiteren Directory bleibt

So wie ich das sehe, gibt es bei N Usern N+1 Meinungen, welche Datei wo hin gehört.
Ich halte nichts davon, das alles so kompliziert zu machen.
Es gibt das große Video-Directory für die Aufnahmen, und es gibt ein Konfigurationsdirectory. Mehr ist meiner Meinung nach für eine so konkrete Applikation wie VDR nicht nötig.
Wenn ich dem Thema weiter nachgebe, dann wird ziemlich sicher eine ewige DIskussion darüber beginnen, welche Datei denn nun von welchem Typ ist und daher hier, oder besser dort, oder vielleicht ganz woanders sein sollte (genau genommen läuft diese Diskussion ja schon, wie weiter vorne in diesem Thread zu sehen ist). Und irgendwann weiß keiner mehr, wo er denn nach einer bestimmten Datei suchen soll.
Ich mag's am liebsten einfach...

Klaus

Zitat von Maniac

Edit: Mir kam gerade noch die Idee was kls davon hält.

Ich habe noch nie allzu viel davon gehalten, die Dateien einer Applikation quer über das gesamte Filesystem zu verstreuen

Klaus

Zitat von FireFly

Mit Pixmap->SetAlpha() kann man ja das OSD schön einblenden. Ein Skin kann das z.B. in Flush() zeitverzögert machen nachdem der Konstruktor aufgerufen wurde.
Aber wie kann ein Skin das OSD wieder ausblenden? Der Destruktor sollte ja nix übrig lassen (wie cOsd) und sollte auch nicht 1000ms benötigen, oder?

Wenn du es langsam ausblenden möchtest, dann mußt du die 1000ms aber wohl oder übel irgendwo "verbraten".
Und das kann vermutlich nur im Destruktor passieren.
Vergiß aber nicht, einen Setup-Parameter einzubauen, mit dem man das abschalten kann. Ich würde nämlich vermuten, daß die meisten das abschalten wollen, sobald sie ein paarmal darauf warten mussten

Klaus

Zitat von S:oren

kls: CEC hat sehr viele verschiedene Teilspezifikationen, fuer die S2-6400 wurden zwei davon beworben: OneTouchPlay und RemoteControlPassThrough.
OneTouchPlay bedeutet, dass ein HDMI-Geraet - hier der vdr - den Fernseher aus Standby einschalten (auch wieder aus ist vorgesehen) und auf den entsprechenden HDMI-Eingang umschalten kann. Das entspricht im Prinzip der entsprechenden Funktionalitaet der analogen Scart-Buchse und ist z.B. dazu gedacht, an einem ueber HDMI angeschlossenen DVD-Player auf Play zu druecken, der Rest passiert dann automatisch. Hier hat die Firmware der S2-6400 einen Bug und schaltet nach dem Einschalten des vdr-Rechners und Aktivieren von CEC im dvbhddevice-Plugin den Fernseher manchmal ohne Nutzerinteraktion ein (von mir ZeroTouchPlay genannt). So weit, so gut, so langweilig. Das ist wohl das, was die meisten Leute bisher unter CEC bei der S2-6400 verstehen.
Richtig interessant ist aber RemoteControlPassThrough. Hier steuert der Fernseher das HDMI-Geraet (den vdr), wenn der Fernseher fuer die entprechende HDMI-Buchse entsprechend eingestellt ist. Der Fernseher reagiert dann nicht mehr selbst auf die (fast alle) Tasten seiner Fernbedienung und reicht stattdessen die Tastendruecke an den vdr durch. Das ist schnell und funktioniert bereits perfekt mit dem Remote-Plugin. Bei mir reagiert der Fernseher zum Beispiel selbst auf laut/leise - sehr schoen bei AC3-Ton, reicht aber die Zifferntasten, die bunten Tasten, die Richtungstasten und mehrere andere Tasten (z.B. OK) an den vdr durch, genau das, was man braucht.

Ich hatte mir das eigentlich genau umgekehrt gedacht, nämlich daß der VDR den Fernseher steuert. Dann wäre man bei der Wahl der Fernbedienung nämlich wesentlich flexibler.
Jetzt muß ich auf meiner bevorzugten FB (welche nicht die mit dem TV gelieferte ist) eine Einstellung finden, mit der sowohl der TV als auch VDR steuerbar ist. Dadurch ist man natürlich in der Auswahl ziemlich eingeschränkt und manche Tasten gehen entweder gar nicht oder wirken sowohl auf VDR als auch TV (wenn ich z.B. die rote Taste drücke, dann blendet mein TV (un)sinnigerweise immer ein "No recording has been started").
Wenn der VDR die paar Steuerbefehle, die ich für den TV brauche, an diesen schicken könnte, dann wäre ich in der Wahl der FB-Codes deutlich freier.

Zitat

Somit braucht der vdr keinen eigenen IR-Empfaenger mehr, der vdr erscheint als "interner Tuner des Fernsehers mit Zusatznutzen", man braucht nur noch die Fernbedienung des Fernsehers. (auf input-select reagiert der Fernseher natuerlich noch selber, aber wer will schon vom vdr wegschalten )

Eben!
Bei mir ist der VDR die zentrale Steuereinheit und der TV lediglich die "Peripherie", die das Bild anzeigt und den Ton wiedergibt.

Klaus

Das mit CEC klingt interessant. Meist hat man ja das Problem, bei einer Fernbedienung eine brauchbare Kombination zu finden, mit der man gleichzeitig den Fernseher und VDR bedienen kann. Wenn man dagegen nur FB-Codes verwenden könnte, die der TV nicht kennt, und VDR diejenigen, die für den TV gedacht sind, über HDMI/CEC an diesen schicken würde, wäre das vielleicht nützlich.

Ich kenne mich mit CEC bisher nicht aus,daher mal folgende Fragen:

- Kann man darüber die Grundfunktionen eines TV steuern (also "Ein", "Aus", "Lauter", "Leiser", "Mute", "Input-Select")?
- Geht das schnell genug, so daß man es interaktiv brauchen kann?

Eventuell würde es ja Sinn machen, in VDR eine neue Plugin-Schnittstelle einzubauen, über die zusätzliche FB-Befehle (die VDR dem Benutzer beim Anlernen der FB anbietet) entsprechend umgesetzt werden können. Das Plugin für eine Karte mit HDMI könnte daraus CEC-Befehle machen, es wäre aber auch denkbar, daß ein anderes Plugin etwas ganz anderes damit anstellt.

Klaus

Zitat von S:oren

Der patch darf von mir aus gerne (auch modifiziert) in das offizielle Plugin uebernommen werden - wer verwaltet das eigentlich (powarman, kls,?).

Das Plugin verwaltet "powarman" hier: http://powarman.dyndns.org/hgwebdir.cgi/dvbhddevice.
Ich füge es nur der aktuellen VDR-Version immer hinzu, weil das dann der Stand ist, den auch ich verwende (und weil ich möchte, daß VDR mit einer TT-S2 6400 "out of the box" funktioniert ;-).

Klaus

Zitat von Keine_Ahnung

Ich hänge mal den Diff gegen den 1.6er (die relevanten Teile haben keine grossen Änderungen, reicht um zu sehen was ich ändere) mit meiner momentanen Bastelei an. Ist noch nicht wirklich schön und ich stehe mit C auch einwenig auf dem Kriegsfuß. Aber der sollte zeigen wo ich hin will.
Ich habe da länger hin und her überlegt, und ich denke das muss so in den VDR damit die Tastatur/UTF8 richtig geht.

Im Prinzip hätte ich gerne erstmal ein OK ob die Richtung prinzipiell OK ist bevor ich da weitermache (Schön machen und Diff gegen den 1.7.23er). Die Idee ist:

- der eKeys enum hat ja nur 4 Byte, so ist es schwer ist da alles vernünftig reinzubekommen, deswegen gibts da jetzt zwei Flags kKbd_control und kKbd_unicode.
Bei kKbd_control steht in den oberen 2 Byte das Steuerzeichen laut eKbdControl, dabei werden auch Tasten wie ESC und Enter zu den Steuerzeichen gemappt (vereinfacht hinterher die Verarbeitung).
Bei kKbd_unicode steht dort das Unicode Zeichen (max. 0xFFFF), ansonsten das 8-Bit Zeichen.
Und eKbdControl ist in keys.h weil die Definition ja eher zu den eKeys gehört und evtl. auch mal Plugins die Tastatur abfragen wollen.

Alles anzeigen

Plugins sollten die Tastatur eigentlich genau nicht abfragen!
Ein Plugin sollte keine Annahmen darüber machen, wo die Eingaben herkommen.
eKbdControl gehört daher zu remote.h und nicht zu keys.h.

Zitat

- Ferner hat es mich immer schon gestört das man in der remote.conf nen Dummyeintrag haben musste wenn man die Tastatur nicht als Fernbedienung nutzen will. Deswegen neben dem no-kbd Kommandozeilenparameter noch no-kbd-remote und no-kbd-input um die beiden Funktionen einzeln zu deaktivieren.

Läßt sich das nicht anders regeln? Mir gefällt das nicht, da noch zwei weitere Optionen einzuführen.

Zitat

- Bei den Editfeldern in menuitems.c gehen auch die Tastaturtasten Links, Rechts, Enter, Esc so das man das Feld Editieren kann ohne die Fernbedienung zur Hand zu nehmen.

Verstehe ich ehrlich gesagt nicht ganz. Wieso muß man da "die Fernbedienung zur Hand nehmen"?

Zitat

- Und cCharSetConv hat ein IsUTF8, weil so ziemlich jedes Plugin bastelt sich was eigenes Zusammen um zu testen ob der VDR gerade auf UTF-8 läuft.

Ich verstehe zwar nicht, warum sich da jedes Plugin "was eigenes zusammenbastelt", denn die Standardvorgehensweise ist doch, cCharSetConv::SystemCharacterTable() abzufragen. Deine IsUFT8() Funktion ist doch lediglich ein anderer Name hierfür (mit umgekehrter Polarität).
Braucht's das wirklich?

Klaus

Zitat von HALLO01

Ich wollte mal nachfragen ob ich das ganze jetzt richtig verstanden habe:

vdr-1.7.23 kann man nur mit einem kernel >= 3 kompilieren, da man ansonst die DVBAPI warning bekommt?
Ein workaround waere zB der api wrapper patch.

Es muß nicht zwingend ein kompletter Kernel >= 3 sein.
Ich verwende Kernel 2.6.37.6 mit dem Treiber von hier:

hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
cd media_build_experimental
make download
make untar

Klaus

Zitat von johns

Habe noch einen Rechtschreibfehler, den mache ich auch gerne.

With -> Width.

Danke

Klaus

Zitat von UFO

Known Bug: VDR crasht beim Beenden.

Hier der Fix:

--- device.c    2012/01/17 15:28:57     2.45
+++ device.c    2012/01/18 10:43:00
@@ -335,6 +335,7 @@
 
 void cDevice::Shutdown(void)
 {
+  deviceHooks.Clear();
   primaryDevice = NULL;
   for (int i = 0; i < numDevices; i++) {
       delete device[i];

Klaus

Zitat von wirbel

In Plugins.html ist ein Tippfehler:
...

Code

-void cMyDeviceHook::DeviceProvidesTransponder(const cDevice *Device, const cChannel *Channel) const
+bool cMyDeviceHook::DeviceProvidesTransponder(const cDevice *Device, const cChannel *Channel) const

Danke, hab's gefixt.

Bei dieser Gelegenheit mal wieder der allgemeine Hinweis: ich nenne normalerweise den Autor jedes Beitrags zu VDR in der HISTORY bzw. CONTRIBUTORS Datei - allerdings nur, wenn mir der wirkliche Name und eine gültige Email-Adresse bekannt sind. Bei den Beiträgen hier im Portal, wo nur Nicknames verwendet werden, weiß ich das meistens nicht. Wer also Wert darauf legt, genannt zu werden, kann mir ja eine Email schicken mit den entsprechenden Angaben.

Klaus

Zitat von UFO

Damit das Lamentieren aufhört, ...

Aus dem gleichen Grund habe ich mir überlegt, die Idee von "johns" aufzugreifen und im Falle, daß ein Device für ein bestimmtes Delivery System nichts liefert, es bei einem anderen Device zu probieren (vorausgesetzt, es gibt für das betreffende Delivery System ein anderes Device).

Damit ist es völlig egal aus welchem Grund ein Device nicht "kann" - und es erspart eine weitere "Konfigurations-Orgie"

Zitat

Known Bug: VDR crasht beim Beenden. Laut PLUGINS.html:

Code

A plugin that creates a derived cDeviceHook shall do so in its Initialize() function, as in 


new cMyDeviceHook;


and shall not delete this object. It will be automatically deleted when the program ends.

Habe ich etwas übersehen?

Ich schau's mir mal an.

Klaus

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

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