[ANNOUNCE] VDR developer version 1.7.15

Intermediate

Occupation: Student der angewandten Informatik

Friday, June 11th 2010, 4:53pm

Quoted

Original von kls
Ist das bei dir ein "plain vanilla" VDR, oder hast du irgendwelche Patches angewendet?

Ich verwende eigentlich den ExtP-NG hier aus dem Forum, habe aber eben auch mal mit einem "plain" getestet, welcher dasselbe Problem hat. Es liegt also an keinem Patch. Auch habe ich mit Kaffeine getestet, dieser kann die DVB-S2-Kanäle problemlos empfangen. Somit bleibt eigentlich nur noch der VDR.

Gibt es irgendwelche Stellen wo ich gut debuggen kann? Wo entscheidet der VDR ob ein Kanal verfügbar ist?

VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

Go to the top of the page

Kanal5

Trainee

Posts: 90

Location: Berlin

22

Friday, June 11th 2010, 5:31pm

RE: [ANNOUNCE] VDR developer version 1.7.15

@TomJoad
Danke läuft wieder.

WoZi: VDR 2.0 auf Suse 11.4, Kernel 3.2, TT-Budget S2-3200 PCI, Lorenzen SL, XBMC
SchlafZi: VDR 2.0, Suse 11.4, Kernel 3.2,Xbmc, Hauppauge Nova HD-S2

Go to the top of the page

kls

Master

Posts: 2,164

Location: Mettenheim

23

Friday, June 11th 2010, 5:32pm

Quoted

Originally posted by balta

Quoted

Original von kls
Ist das bei dir ein "plain vanilla" VDR, oder hast du irgendwelche Patches angewendet?

Ich verwende eigentlich den ExtP-NG hier aus dem Forum, habe aber eben auch mal mit einem "plain" getestet, welcher dasselbe Problem hat. Es liegt also an keinem Patch. Auch habe ich mit Kaffeine getestet, dieser kann die DVB-S2-Kanäle problemlos empfangen. Somit bleibt eigentlich nur noch der VDR.

Gibt es irgendwelche Stellen wo ich gut debuggen kann? Wo entscheidet der VDR ob ein Kanal verfügbar ist?

Schau dir mal cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) und cDvbDevice:

rovidesTransponder() an.

Klaus

Gib CI+/HD+ keine Chance! Lasst diese Pest am ausgestreckten Arm verhungern!
Wer für sowas bezahlt macht sich zum Totengräber von Projekten wie VDR!
Die Wahrheit ueber HD Plus
CI-Plus -- Das trojanische Pferd im Wohnzimmer

Go to the top of the page

hd.brummy

Professional

Posts: 1,100

Location: Berlin DE / Cape Town ZA

24

Friday, June 11th 2010, 6:58pm

@KLS

Opps,

sorry, da ist mir hier 'n Fehler reingerutscht von 0.0.2 zu 0.0.3

alles i.O

Go to the top of the page

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

25

Friday, June 11th 2010, 7:20pm

Quoted

Original von kls
Schau dir mal cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) und cDvbDevice:rovidesTransponder() an.

Klaus

Ich habe mal ein wenig Debugcode reingeschrieben, aber werde hier nicht schlau draus:

Folgender Patch:

Source code

diff -Naurwb vdr-1.7.15//dvbdevice.c vdr-1.7.15.dbg//dvbdevice.c
--- vdr-1.7.15//dvbdevice.c     2010-05-01 11:47:13.000000000 +0200
+++ vdr-1.7.15.dbg//dvbdevice.c 2010-06-11 18:33:43.000000000 +0200
@@ -909,8 +909,10 @@

 bool cDvbDevice::ProvidesTransponder(const cChannel *Channel) const
 {
-  if (!ProvidesSource(Channel->Source()))
+  if (!ProvidesSource(Channel->Source())){
+     esyslog("ERROR: frontend doesn't provide source");
      return false; // doesn't provide source
+  }
   cDvbTransponderParameters dtp(Channel->Parameters());
   if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
      dtp.Modulation() == QPSK     && !(frontendInfo.caps & FE_CAN_QPSK) ||
@@ -922,11 +924,14 @@
      dtp.Modulation() == QAM_AUTO && !(frontendInfo.caps & FE_CAN_QAM_AUTO) ||
      dtp.Modulation() == VSB_8    && !(frontendInfo.caps & FE_CAN_8VSB) ||
      dtp.Modulation() == VSB_16   && !(frontendInfo.caps & FE_CAN_16VSB) ||
-     dtp.Modulation() == PSK_8    && !(frontendInfo.caps & FE_CAN_TURBO_FEC) && dtp.System() == SYS_DVBS) // "turbo fec" is a non standard FEC used by North American broadcasters - this is a best guess to determine this condition
+     dtp.Modulation() == PSK_8    && !(frontendInfo.caps & FE_CAN_TURBO_FEC) && dtp.System() == SYS_DVBS){ // "turbo fec" is a non standard FEC used by North American broadcasters - this is a best guess to determine this condition
+     esyslog("ERROR: channel requires modulation (%d) system which frontend doesn't provide", dtp.Modulation());
      return false; // requires modulation system which frontend doesn't provide
+  }
   if (!cSource::IsSat(Channel->Source()) ||
      !Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
      return DeviceHooksProvidesTransponder(Channel);
+  esyslog("ERROR: device doesn't provide transponder");
   return false;
 }

beim umschalten erhalte ich:

Source code

1
2
3

Jun 11 19:08:38 tuxshome vdr: [4884] switching to channel 31 
Jun 11 19:08:38 tuxshome vdr: [4884] ERROR: channel requires modulation (1) system which frontend doesn't provide 
Jun 11 19:08:38 tuxshome vdr: [4884] info: Kanal nicht verfügbar!

Allerdings erhalte ich diese Fehlermeldung auch regelmäßig so jetzt. Was ist Modulation 1? ich kann die Definition nirgends finden.

VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

Go to the top of the page

FireFly

Master

Posts: 2,681

26

Friday, June 11th 2010, 7:45pm

Quoted

Original von balta
Was ist Modulation 1? ich kann die Definition nirgends finden.

Das müsste der Index auf

	Source code
1 2 3 4	const tDvbParameterMap ModulationValues[] = { { 16, QAM_16, "QAM16" }, { 32, QAM_32, "QAM32" }, ...

sein, also QAM32.

Avards / skinElchi / Systeminfo / Patches / Burn

Go to the top of the page

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

27

Friday, June 11th 2010, 8:06pm

Quoted
Original von FireFly

Quoted

Original von balta
Was ist Modulation 1? ich kann die Definition nirgends finden.

Das müsste der Index auf
Source code
1
2
3
4
const tDvbParameterMap ModulationValues[] = {
  {  16, QAM_16,   "QAM16" },
  {  32, QAM_32,   "QAM32" },
...
sein, also QAM32.

Ach der Index? ich hatte mir die Zahlen davor angeschaut... aber eig kann meine Karte das (bis vdr 1.7.14), ich werde mal weitersuchen...

Edit: Ich habe weitergesucht und ich denke den Grund gefunden.

frontendInfo.caps liefert bei mir nur 0x10000601, was FE_IS_STUPID, FE_CAN_FEC_AUTO, FE_CAN_QPSK und FE_CAN_RECOVER wenn ich richtig gezählt habe, und ich vermute das erste gilt auch für den Treiber (stupid), wenn er so unvollständige Fähigkeiten liefert...

Wäre es vielleicht möglich diesen genauen Check optional wieder zu deaktivieren? Für die mit den dummen Treibern unter uns

Und vielleicht wäre es schön die gelieferten Capabilities auch beim Start pro Frontend auszugeben, um sowas das nächste mal schneller zu finden.

VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

This post has been edited 1 times, last edit by "balta" (Jun 11th 2010, 9:00pm)

Go to the top of the page

rechenknechtler

Trainee

Posts: 130

28

Saturday, June 12th 2010, 1:43am

Hallo balta,

hier klappts mit der SkyStar HD 2 und dem VDR 1.7.15.

Zum Vergleich:
- lspci -vn identifiziert meine Karte (laut linuxtv.org gibt es derzeit zwei Versionen) mit 1822:4e35 / Subsystem: 1ae4:0003
- Treiber: s2-liplianin Revision 14629

Go to the top of the page

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

29

Saturday, June 12th 2010, 2:24am

Quoted

Original von rechenknechtler
Hallo balta,

hier klappts mit der SkyStar HD 2 und dem VDR 1.7.15.

Zum Vergleich:
- lspci -vn identifiziert meine Karte (laut linuxtv.org gibt es derzeit zwei Versionen) mit 1822:4e35 / Subsystem: 1ae4:0003
- Treiber: s2-liplianin Revision 14629

Danke für die Info.

Bei mir ist es Subsystem 1ae4:0001, aber ich verwende außerdem den im Kernel enthaltenen Treiber. Ich wollte allerdings eh noch eine Mail an die v4l-Mailinglist schreiben, da das Modul auch nicht automatisch lädt, dann werde ich das auch gleich erwähnen... Vielleicht steige ich doch noch wieder auf liplianin um...

VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

This post has been edited 1 times, last edit by "balta" (Jun 12th 2010, 2:52am)

Go to the top of the page

rechenknechtler

Trainee

Posts: 130

30

Saturday, June 12th 2010, 9:56am

Quoted

Original von balta
Bei mir ist es Subsystem 1ae4:0001, aber ich verwende außerdem den im Kernel enthaltenen Treiber. Ich wollte allerdings eh noch eine Mail an die v4l-Mailinglist schreiben, da das Modul auch nicht automatisch lädt, dann werde ich das auch gleich erwähnen... Vielleicht steige ich doch noch wieder auf liplianin um...

Mir erschien der mantis-Treiber aus dem Kernel 2.6.33 deutlich langsamer beim Zappen. Hab eben geschaut, es gab auch keine Änderung für mantis im Kernel 2.6.34. Bei s2-liplianin sind die letzten Revisionen bei mantis aber auch schon etwas her. Vermutlich sind die beiden Sachen sogar gleich, müsste man mal einen diff drüber machen. Da sorgt wohl die Treiber-Peripherie für anderes Verhalten. Falls du s2-liplianin probieren willst: Die letzten Revisionen produzieren bei mir derzeit Kernelcrashs. Revision 14629 läuft aber schon einige Zeit problemlos.

Go to the top of the page

balta

Intermediate

Posts: 315

Occupation: Student der angewandten Informatik

31

Saturday, June 12th 2010, 11:46pm

Hi,

als es mit dem liplianin-Treiber auch nicht funktionierte wurde ich stutzig und habe einmal meine channels.conf mit der aus dem wiki verglichen. Dabei fiel mir auf dass bei allen DVB-S2-Sendern die falsche Modulation eingetragen war, nachdem ich das überall auf 8PSK gestellt habe funktioniert es auch (mit beiden Treibern).

Ich weiß nicht wie der Fehler zustande kam, und auch nicht wieso der 1.7.14 damit keine Probleme hatte, aber jetzt funktioniert es. Danke nochmal an alle die mir geholfen haben

VDR: AMD A4-3400, 4096 MB RAM, Technisat SkyStar HD2, Technisat Skystar USB HD
openSUSE 12.3, VDR 2.0.1, vdr-xineliboutput

Go to the top of the page

prometheus

Beginner

Posts: 41

Location: Natternbach

32

Sunday, June 27th 2010, 5:22pm

Hi,
könnt Ihr auch beobachten, dass der vdr Prozess in der Version 1.7.15 ca. 3x soviel CPU Zeit verbrät wie in der Version 1.7.14?

Kernel: 2.6.32
Output erfolgt über das xine Plugin.

lg
christian

Go to the top of the page

Lou

Professional

Posts: 887

33

Monday, June 28th 2010, 9:25am

Hallo christian

Hier mal ein paar Fragen zu Deinem Problem:

Was für Sender sind das? (Auflösung in SD oder HDTV?)
Wird der vdr als root gestartet und kann die nice Last (thread.c) anpassen?
CPU Governor läuft auf welcher Einstellung? ('cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor')

MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

Go to the top of the page

spitzb

Intermediate

Posts: 474

Location: Rheda-wiedenbrück

Occupation: IT

34

Monday, June 28th 2010, 3:01pm

Ich kann das mit der deutlich höheren CPU - Last bestätigen. Es ist der receiver - thread, der deutlich mehr Zeit verbraucht.

Bei mir läuft die Ausgabe über eine eHD.

Falk

Go to the top of the page

prometheus

Beginner

Posts: 41

Location: Natternbach

35

Monday, June 28th 2010, 9:46pm

Hallo,

Der VDR läuft nicht als root, es gibt einen eigenen vdr Account der sich allerdings in der root Gruppe befindet.
(Gentoo eBuild, nur der vdr selbst is von hand kompiliert)
Es tritt sowohl bei SD als auch bei HD sendern auf (bei HD Programmen ist die Auslastung natürlich höher, das ist aber auch normal)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
liefert:
userspace
thread.c könnte ich wen nötig anpassen und alles neu kompilieren.
Kann ich irgendwelche anderen Infos liefern, die uns weiterhelfen?

lg
christian

This post has been edited 1 times, last edit by "prometheus" (Jun 28th 2010, 10:28pm)

Go to the top of the page

Lou

Professional

Posts: 887

36

Monday, June 28th 2010, 10:40pm

Quoted

Original von prometheus
Der VDR läuft nicht als root, es gibt einen eigenen vdr Account der sich allerdings in der root Gruppe befindet.
[...]
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor liefert:
userspace

der User unter dem der vdr läuft ist egal, wichtig ist, das root den vdr startet -> dann kann die nice Last angepasst werden.

Kannst den Governor mal wechseln auf performance oder ondemand? Das geht mit sudo echo <Ausdruck> direkt in die scaling_governor Datei rein oder mit einem der graphischen Applets (solltest du sowas haben)

MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

Go to the top of the page

hotzenplotz5

Sage

Posts: 5,752

37

Saturday, July 10th 2010, 2:27pm

@kls mal ne frage
warum kann vdr nicht nach dem vdr start erkennen ob es ein "neues" device gibt ?
wäre doch "wichtig" für z.b. dvb-t stix ?

in manchen "situationen" startet eben vdr schneller (bei startskripten) als das device zur verfügung steht ...

oder anders gefragt, was braucht es damit es möglich wird ?

This post has been edited 1 times, last edit by "hotzenplotz5" (Jul 10th 2010, 2:29pm)

Go to the top of the page

Urig

Professional

Posts: 1,214

Location: Kassel

38

Saturday, July 10th 2010, 3:46pm

Quoted

Originally posted by hotzenplotz5
warum kann vdr nicht nach dem vdr start erkennen ob es ein "neues" device gibt ?
wäre doch "wichtig" für z.b. dvb-t stix ?

Darüber nachgedaht habe ich auch schon. Drei Dinge fehlen für Plug&Play derzeit:
1. Überspringen nicht vorhandener Devices
2. Suchen nach neuen Devices zur Laufzeit
3. Entfernen von Devices zur Laufzeit

(1) ist erforderlich, falls mal ein Stick gezogen wurde, und z.B. nur /dev/dvb0 und /dev/dvb2 übrig sind. In dem Zusammenhang wäre es auch schön, wenn die Device-Namen nicht so 'hartkodiert' wären, und besser mit udev zusammen arbeiten würden: z.B. wenn /dev/dvb-primary ein Symlink auf /dev/dvbX ist.

(2) sollte noch überschaubar sein, wenn man vorsichtig vor geht. Zyklisch nach neuen Devices suchen, und dann die Device-Liste verlängern. Man muss nur aufpassen, dass es keine Multithread-Probleme gibt, denn bisher wird die Device-Liste bei Programmstart erzeugt und ist danach statisch. Wenn auch Device-Plugins dynamisch aktiv werden sollen, wird dafür eine Plugin-Schnittstelle nötig.
Auch das bisherige -D 0 -D 1 -D 2 passt nicht recht dazu, die Nummern der zu benutzenden Devices ergeben sich ja aus der Auffind-Reihenfolge bei Programmstart, und sind für dynamisch gefundene Devices wenig sinnvoll.

(3) wird dagegen ernsthaft kompliziert. Nicht nur, dass entfernte Devices u.U. genutzt wurden, und Timer etc. auf andere Devices verlegt werden müsten, mit allen Konsequenzen (Prioritäten), auch das Thread-sichere Abbauen des Devices ist nicht ganz einfach. Derzeit werden die Devices bei Programmende abgebaut, nachdem alle Device-Aktivitäten beendet und alle Plugins gestoppt sind, und dann ziemlich sicher niemand mehr das Device im Hintergrund benutzt. Auch hier wird für Plugins erst mal eine zusätzliche Schnittstelle erforderlich.

Ausklammern sollte man dagegen das primary output device. Ein dynamisches hin und her des primary device dürfte für erhebliche Kopfschmerzen sorgen.

Alles in allem eine herausfordernde, wenn auch nicht ganz unmögliche Aufgabe.

Quoted

in manchen "situationen" startet eben vdr schneller (bei startskripten) als das device zur verfügung steht ...

Mein DVB-Ladeskript wartet deswegen auf das Auftauchen aller 'erwarteten' Devices bis zu einem großzügigen Timeout.

Gruß,

Udo

PS: Von mir ist das Proxy-Plugin, das das dynamische Entladen von Plugins erlaubt - und für Device-Plugins gleich wieder verbietet, weil es schlicht nicht möglich ist, Device-Plugins sauber zu beenden, bevor VDR herunter fährt.

This post has been edited 1 times, last edit by "Urig" (Jul 10th 2010, 3:49pm)

Go to the top of the page

NemoN

Professional

Posts: 575

Location: Hamburg

39

Saturday, July 10th 2010, 8:00pm

irgendwo im forum habe ich gelesen das der reel vdr in kombination mit dem net receiver mit virtuellen devices (bzw. device pools) arbeit. aber ich finde den thread gerade nicht.

Server: Debian, 2.5" 320GB, 3.5" 2TB, GuruPlug Plus, 10 Watt idle
Client 1: HD/VDPAU (VDR 1.7.xx / 1.5TB / Antec Fusion Remote / yaUsbIr / M3N78-EM + GT220 (inkl. HDMI Audio) / AMD X2 250 / 2GB RAM / HVR-4000 / NOVA-HD-S2) (CineS2 wartet auf Einbau)
Client 2: M740AV (VDR 1.4.7)

Go to the top of the page

gda

Im Forum Zuhause

Posts: 11,196

Location: HH

40

Saturday, July 10th 2010, 8:19pm

Quoted

Original von NemoN
irgendwo im forum habe ich gelesen das der reel vdr in kombination mit dem net receiver mit virtuellen devices (bzw. device pools) arbeit.

Die Idee hatten wir auch schon mal. Einfach dem vdr vorlügen wir hätten eine Menge DVB-Devices und wenn der vdr drauf tunen will sagen wir ihm einfach, dass es gerade nicht geht, bis wir die Devices tatsächlich haben. Leider haben wir weder die Zeit noch die Erfahrung um das auch umzusetzen.

Gerald

OrigenAE S16T, ASRock K10N78D, Athlon II X2 4400e (unlocked Sempron 140), 2GB RAM, OCZ Vertex 30GB, 2xWD10EADS, 3xKNC One TV-Station DVB-C, G210 MSI N210-MD512H, yaVDR.
Seagate Dockstar, Debian Squeeze, VDR 1.7.16, 500 GB 2,5" HD, 2xSundtek MediaTV Home DVB-C/T.

Go to the top of the page

VDR Portal

Quoted

RE: [ANNOUNCE] VDR developer version 1.7.15

Quoted

Quoted

Quoted

Source code

Source code

Quoted

Source code

Quoted

Quoted

Source code

Quoted

Quoted

Quoted

Quoted

Quoted

Quoted