[ANNOUNCE] VDR developer version 1.7.2

Moin,

... ist es denn schon jemand gelungen ein DVB-S2 budget-only System (TT-S2 3200) mit vdr-1.7.2 und einem der Software Ausgabedevice (xineliboutput, xine-plugin, softdevice) zu betreiben? Ich bekomme einfach kein Live-Bild angezeigt. Und per streamdevice an den MPlayer habe ich eine slide show.

Gruß, ollo

Wichtiger Hinweis an alle die eine TwinHan-Karte mit DST-Frontend unter S2API verwenden wollen: Ohne den folgenden Patch können die Karten nicht tunen. Der Patch stammt aus der DVB-Mailingliste, ist bis dato leider noch nicht im v4l-dvb-Repository eingecheckt

--- linux/drivers/media/dvb/bt8xx/dst.c.orig    2009-01-02 13:06:47.000000000 +0100
+++ linux/drivers/media/dvb/bt8xx/dst.c 2009-01-02 13:07:25.000000000 +0100
@@ -1683,7 +1683,7 @@


 static int dst_get_tuning_algo(struct dvb_frontend *fe)
 {
-       return dst_algo;
+       return dst_algo ? DVBFE_ALGO_HW : DVBFE_ALGO_SW;
 }


 static int dst_get_frontend(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)

Zitat

Originally posted by MerlinElMago
Habe gerade festgestellt dass der VDR-1.7.2 mit dem Wrapper-Patch von Urig keine Kanäle mehr auf meiner DVB-T Budgetkarte empfängt. Ich habe eine FF DVB-S und eine DVB-T in meinem System. Die DVB-S Kanäle sind weiterhin zu sehen.

Hab gerade den Gegentest mit meinem DVB-T USB Empfänger gemacht, funktioniert bei mir. Irgend welche Fehlermeldungen im syslog?

Gruß,

Udo

Nichts, es herrscht stille in meinem Syslog.

Gruss
Merlin

frage an die Pro's

ich bekomme immer beim kompilieren den Fehler dass die DVB API 5 benötigt wird

als ich meinen Kernel kompiliert habe, hatte ich:
"Enable Video For Linux API 1 (DEPRECATED)" aktiviert
bekomme ich nun die aktuelle API wenn ich "Enable Video For Linux API 1 compaitble Layer" aktiviere und den Kernel neu kompiliere?

frage nur noch, weil ich mir nicht ganz sicher bin ob ich sonst auch noch was bestimmtest einstellen muss (außer meines TV-Chips in "DVB/ATSC adapters") denn das ganze dauert wieder 2h zum kompilieren

thx
mfg
aelo

hast denn die neuen headers in /usr/include/linux/dvb?

ansonsten DVBDIR setzen.

vdr:/usr/include/linux/dvb# ls -lah
insgesamt 88K
drwxr-xr-x  2 root root 4,0K 2008-10-09 21:00 .
drwxr-xr-x 22 root root  20K 2008-10-09 21:00 ..
-rw-r--r--  1 root root 4,9K 2008-11-23 17:54 audio.h
-rw-r--r--  1 root root 3,0K 2008-11-23 17:54 ca.h
-rw-r--r--  1 root root 3,8K 2008-11-23 17:54 dmx.h
-rw-r--r--  1 root root  16K 2008-11-23 17:54 frontend.h
-rw-r--r--  1 root root   85 2006-09-20 05:42 Kbuild
-rw-r--r--  1 root root 1,6K 2008-11-23 17:54 net.h
-rw-r--r--  1 root root 5,6K 2008-11-23 17:54 osd.h
-rw-r--r--  1 root root 1016 2008-11-23 17:54 version.h
-rw-r--r--  1 root root 8,7K 2008-11-23 17:54 video.h

sieht noch nicht die neuen oder?
am 23.11 gabs ja den neuen kernel noch nicht...

kann ich die einfach löschen und dann den kernel neu installen und dann werden die neuen hineinkoppiert?

thanx
mfg
aelo

ne, die kommen aus dem paket linux-libc-dev (bei sid)

einfach aus dem kernel dir dahin kopieren koennte funktionieren.

sicherung davor nie vergessen

edit die x-te:

habe das ganze hier ausgelagert:
http://vdr-portal.de/board/thread.php?threadid=83108
damit die News übersichtlicher bleibt ohne meine "kleinen?" Probleme^^

mfg
aelo

Zitat

Originally posted by schmirl
Wichtiger Hinweis an alle die eine TwinHan-Karte mit DST-Frontend unter S2API verwenden wollen: Ohne den folgenden Patch können die Karten nicht tunen. Der Patch stammt aus der DVB-Mailingliste, ist bis dato leider noch nicht im v4l-dvb-Repository eingecheckt

Diff

--- linux/drivers/media/dvb/bt8xx/dst.c.orig    2009-01-02 13:06:47.000000000 +0100
+++ linux/drivers/media/dvb/bt8xx/dst.c 2009-01-02 13:07:25.000000000 +0100
@@ -1683,7 +1683,7 @@


 static int dst_get_tuning_algo(struct dvb_frontend *fe)
 {
-       return dst_algo;
+       return dst_algo ? DVBFE_ALGO_HW : DVBFE_ALGO_SW;
 }


 static int dst_get_frontend(struct dvb_frontend *fe, struct dvb_frontend_parameters *p)

Alles anzeigen

Kann das gleiche Problem mit cx88 Karten sein ?

Zitat

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

Diff

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

Alles anzeigen

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.

Außerdem: Kommt es zu einem EAGAIN und Timeout, liefert WriteAllOrNothing die geschriebenen Bytes zurück - das wird beim nächsten Aufruf aber nicht berücksichtigt!

Wenn überhaupt, sollte der Code nicht eher etwa so aussehen?

int w;
  int written = 0;
  do {
     w = WriteAllOrNothing(fd_video, Data + written, Length - written, 1000, 10);
     if (w < 0 && FATALERRNO)
        return w;
     if (w > 0)
        written += w;
     } while (Length > written);
  return written;

Absolut Ruckelfrei funktioniert bei mir die Wiedergabe aber nur, wenn ich den Code von VDR 1.7.1 weiter verwende, der solche Klimmzüge schlicht weg lässt:

int cDvbDevice::PlayVideo(const uchar *Data, int Length)
{
  return WriteAllOrNothing(fd_video, Data, Length, 1000, 10);
}

Gruß,

Udo

Zitat

Original von ollo
... ist es denn schon jemand gelungen ein DVB-S2 budget-only System (TT-S2 3200) mit vdr-1.7.2 und einem der Software Ausgabedevice (xineliboutput, xine-plugin, softdevice) zu betreiben? Ich bekomme einfach kein Live-Bild angezeigt. Und per streamdevice an den MPlayer habe ich eine slide show.

Gelungen, dasselbe Problem zu haben :-(( - mit V1.7.0 und multiproto-Treibern habe ich aber dieses Problem auch. Softdevice geht und aufnehmen geht jedoch auch (siehe auch hier).

Marcus

Zitat

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.