Posts by TomJoad

Für 1.7.6 gibt es schon Liemikuutio-1.27. Vielleicht kannst Du das in der offiziellen Version einbauen.
Danke

Ich kenne eigentlich nur die Meldung "missing plugin", wenn ein Plugin im Verzeichnis nicht gefunden wird. "unknown plugin" kommt z.B. wenn in keymacros.conf ein Aufruf auf ein nicht bekanntes Plugin steht. Sind da vielleicht irgendwelche Sonderzeichen reingerutscht? ( cat -v ...)

Vielleicht hilft es, als zusätzlichen Parameter -D /var/log/dvdswitch.log
anzufügen und nach Hinweisen in dieser Debugdatei zu schauen.

TS ist doch nur die Verpackung um PES herum beim digitalen Fernsehen. Das spricht nicht dagegen, in TS die Aufnahmen zu speichern, doch jedes Ausgabeprogramm muss aus TS das PES wieder rausholen.

Ich kenne die Meinung von Klaus und respektiere sie. Trotzdem sollte man doch möglichst früh versuchen, Weichen zu stellen.
Zur Zeit wird xineliboutput von PlayVideo und PlayAudio gefüttert, die beide PES weitergeben und nicht TS. Nur dieses PES ist offensichtlich (noch) nicht kompatibel. Es reicht gerade, um eine FF zu füttern. Deshalb setzt ja xine in 0.9.0 auf PlayTS auf und benutzt den alten Remuxcode, um selber PES zu erzeugen.
Wenn es schon eine neue Klasse cTsToPes gibt, die ja cRemux ablösen sollte, sollte gefragt werden, warum damit die Softdevices nicht umgehen können. Sind nur kleinere Anpassungen in cTsToPes nötig oder muss im Prinzip die ganze Untersuchung auf Framegrenzen aus cRemux wieder rein?
Ich war ja nur dagegen, dass jedes Plugin das Rad wieder neu erfinden muss.
Mir sind nicht alle Hintergründe klar, aber wenn jedes Plugin nur TS bekommt, muss jedes Plugin aus dem TS wieder das PES extrahieren, um die einzelnen Frames an das entsprechende Ausgabedevice zu geben. Es bläht doch den Code nur unnötig auf, wenn da nicht zentrale Klassen zur Verfügung gestellt werden. Der Hinweis auf Patches wie Bigpatch oder Extensionspatch heisst ja auch nur, dass man Sachen, die nur bestimmte Plugins brauchen, über ifdefs im Code ein- und abschalten kann.

xineliboutput würde mit dem gleichen Remux-"Trampolin" funktionieren wie xine-0.9.0. Deshalb stellt sich die Frage, ob man nicht die alten Remuxer-Klassen wieder im Basis-VDR haben sollte (notfalls per Bigpatch), damit alle Plugins, die aus TS wieder PES machen müssen, was davon haben.

Quote

Original von kls
. Wenn also jemand einen Vorschlag hat, wie das besser zu machen ist, immer her damit.
Klaus

Warum nicht einfach wie PlayTsVideo:

int cDevice::PlayTsAudio(const uchar *Data, int Length)
{
  if (TsPayloadStart(Data)) {
     int l;
     while (const uchar *p = tsToPesAudio.GetPes(l)) {
           int w = PlayAudio(p, l, 0);
           if (w < 0)
              return w;
           }
     tsToPesAudio.Reset();
     }
  tsToPesAudio.PutTs(Data, Length);
  return Length;
}

funktioniert bei mir jedenfalls einwandfrei

Die Routine PlayTsAudio() in device.c macht für mich überhaupt keinen Sinn (auch nicht mit den Korrekturen von rnissl), sie liefert kein komplettes PES-Paket ab, sondern das erste TS-Teil und dann einen Haufen Mülldaten. (Bei ZDF heute war das PES-Längenfeld vom Audiostream 5384 und soviel wird auch versucht auszugeben, auch wenn noch nicht alle zugehörigen TS gesammelt sind). Warum ist sie nicht so geschneidert wie PlayTsVideo ???
Wenn man die Routine so umschreibt wie in PlayTsVideo und die Länge einzelner Video-PES nicht auf 0xfff0, sondern auf 2k beschränkt, geht im Prinzip auch xineliboutput wieder. Allerdings ist der Ton nicht immer sauber.

Quote

Original von Urig
Ich durchschaue die gesamte Code-Änderung an dieser Stelle nicht. WriteAllOrNothing selbst kümmert sich doch schon um EAGAIN, wenn schon ein Teil der Daten geschrieben wurde. Die Schleife wirkt also nur, wenn EAGAIN ab dem 0. Byte zuschlägt, oder das 1s Timeout erreicht wird.

Mir scheint auch der alte Code am besten zu dvbplayer zu passen, weil dort der DevicePoll schon gemacht wird und dann auch fatale Fehler richtig durchgereicht werden.
Allderdings durchschaue ich die Absicht bei 7.1.2 nicht. Es sollte wohl nur erreicht werden, PlayTsVideo von einer Überprüfung zu befreien, weil die Pakete ja auf jeden Fall rausgehen sollen. Eine Abfrage auf FATALERRNO gehört auf jeden Fall in die Schleife und mit der bestehenden Schleife habe ich im strace gesehen, dass jedes Videopaket etwa 20mal beim ersten Byte auf EAGAIN lief, bevor es - und dann ganz - akzeptiert wurde, deshalb der zusätzliche Poll. Mit anderen CPUs und anderen Ausgabedevices kann es zu anderem Timing kommen, deshalb wollte ich keinen sleep einbauen.
Die Änderungen zu 7.1.2 berücksichtigen auch die Möglichkeit eines Timeouts nicht, dann wird das ganze Paket immer wieder geschickt.
Im alten transfer wurde bei Live-Transfer vor jedem PlayPes auch ein DevicePoll (mit Timeoutüberwachung und evtl. Reset) gemacht, das ganze gibt es nicht mehr. Die aktuelle Schleife im transfer mit SleepMs(10) wird eigentlich nicht aktiv, weil PlayVideo nur zurückkommt, wenn alles ausgegeben wurde.

Irgendwas passt da aber nicht zusammen. vdr 1.7.2 verlangt API Version 5 und dvbfe_delsys gibt es nicht mehr. Ich würde zuerst mal einen korrekten Stand des vdr aufspielen (von ftp://ftp.cadsoft.de/vdr/Developer die tar-Datei von 7.1.2 oder auf einen älteren Stand die korrekten diff-Dateien

Mir war aufgefallen, dass vdr 1.7.2 bei der Wiedergabe von Aufnahmen 80%CPU-Last erzeugt. Beheben kann man das mit folgendem Patch

--- src/dvbdevice.c.last        2008-12-27 18:19:39.000000000 +0100
+++ src/dvbdevice.c     2008-12-27 18:27:48.000000000 +0100
@@ -1339,6 +1339,10 @@ int cDvbDevice::PlayVideo(const uchar *D
   int w;
   do {
      w = WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
+     if ((w < 0) && errno==EAGAIN) {
+       cPoller Poller(fd_video,true);
+       Poller.Poll(200);
+        }
      } while (w != Length);
   return w;
 }
@@ -1348,6 +1352,10 @@ int cDvbDevice::PlayAudio(const uchar *D
   int w;
   do {
      w = WriteAllOrNothing(fd_audio, Data, Length, 1000, 10);
+     if ((w < 0) && errno==EAGAIN) {
+       cPoller Poller(fd_audio,true);
+       Poller.Poll(200);
+        }
      } while (w != Length);
   return w;
 }

Ohne diesen Patch hat die Routine das Schreiben der Video-Daten ohne Pause bis zu 25 Mal wiederholt, wenn fd_video noch belegt war (EAGAIN). Klaus sollte kommentieren, ob das genau an dieser Stelle Sinn macht, ich habe aber keine Nebenwirkungen gesehen.
Da die Daten max 2k gross sind, sollten keine Nebenwirkungen auftreten, auch der Transfermode bei ZDF scheint gut zu gehen.

Seit einiger Zeit habe ich das Problem, dass im Münchner Kabel auf 458 MHz der ARD-Transponder mit Arte, Eins Festival etc. den laufenden und nächsten Event falsch anzeigt.
Alle anderen Transponder sind ok
Ich habe mit dvbsnoop nachgesehen, dass die Daten schon falsch gesendet werden, auch das Running Flag ist falsch gesetzt, was jede Aufnahme mit VPS unmöglich macht.
Meine Frage an die anderen ist, ist das auch auf dem Astra-Satelliten, von dem das Signal übernommen wird, so oder mischt Kabel Deutschland da mit (was ich mir zwar eigentlich nicht vorstellen kann, aber immerhin wird ein Lokalsender zu dem Transponder dazugemischt)

Versuchs mal mit CONFIG_DVB_BUDGET_AV, dann sollte kommen
DVB: registering new adapter (Satelco EasyWatch DVB-C MK3)
DVB: registering adapter 1 frontend 0 (Philips TDA10023 DVB-C)
budget-av: ci interface initialised.

Ihr habt doch beide Recht. Wenn vdr mit

export LD_ASSUME_KERNEL=2.4.1

startet wie z.B. bei easyvdr, bekommt jeder thread eine eigene PID.

Hast du mal

cd /var/tmp/portage/media-tv/v4l-dvb-hg-0.1-r2/work/v4l-dvb
make menuconfig

ausprobiert?

Mit der Einstellung und im Plugin-Setup OSDHeight=480, OSDOffset=0, Position=1,Skin=1,Theme=1,UseSingleArea=0 habe ich keine Probleme mit der Anzeige.

Was ist denn bei Dir die Basiseinstellung für OSDHeight und OSDWidth im OSD-Setup?

Hi,
I had the same problem, because in the general Fontsettings I am using UseSmallFont=2.
If this is your problem, the following patch to the music-sources should help

--- config.c.orig       2008-06-02 13:28:59.000000000 +0200
+++ config.c    2008-06-02 13:29:49.000000000 +0200
@@ -153,7 +153,7 @@
 const cFont *cMusicConfig::GetFont(int id, const cFont *pFontCur)
 {
   const cFont *res = NULL;
-  if(::Setup.UseSmallFont == 1) {
+  if((::Setup.UseSmallFont == 1)||(::Setup.UseSmallFont == 2)) {
     if (allFonts[id].VdrId == FONT_TRUETYPE) {
       if(pFontCur)
         return pFontCur;

Ich hatte das gleiche Problem von Anfang an (allerdings mit TT-C2300 und damals linvdr) und habe es nicht lösen können. Ich verzichte seitdem auf das CI und benutze eine USB-Fernbedienung.
Im Transfer-Mode fehlten immer wieder Frames, die von der Hardware/Firmware nicht zum Treiber kamen und dann auch nicht zum vdr. Merkwürdigerweise lief damit gleichzeitig der Repacker-Puffer langsam voll und es wurde ein DeviceClear() gemacht. Seitdem das CI nicht mehr dran ist, ist das Problem nie mehr aufgetreten.

Quote

Original von Dr. Seltsam
den Zusammenhang von Mute und ToggleMute ist mir noch unklar.
in device.c passiert bei ToggleMute() folgendes: ...
Da wird offenbar Mute bzw. DeviceMute gar nicht aufgerufen.

Bei der FF folgt aus dem obigen SetVolume ein SetVolumeDevice (dvbdevice.c), mit einem ioctl (AUDIO_SET_MIXER), dieser führt im ttpci-Treiber zu av7110_set_volume. Mute wird m.E. als volume=0 realisiert (jedenfalls beim TV schauen).