You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

21

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 13.1, VDR 2.0.4, vdr-xineliboutput

Kanal5

Trainee

Posts: 93

Location: Berlin

  • Send private message

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


kls

Master

Posts: 2,682

Location: Mettenheim

  • Send private message

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::ProvidesTransponder() 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

hd.brummy

Professional

Posts: 1,164

Location: Berlin DE

  • Send private message

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

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::ProvidesTransponder() an.

Klaus


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

Folgender Patch:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
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 13.1, VDR 2.0.4, vdr-xineliboutput

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.

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 13.1, VDR 2.0.4, vdr-xineliboutput

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


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

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 13.1, VDR 2.0.4, vdr-xineliboutput

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


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.

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 13.1, VDR 2.0.4, vdr-xineliboutput

prometheus

Trainee

Posts: 56

Location: Natternbach

  • Send private message

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

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

spitzb

Intermediate

Posts: 489

Location: Rheda-wiedenbrück

Occupation: IT

  • Send private message

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

prometheus

Trainee

Posts: 56

Location: Natternbach

  • Send private message

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)


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

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)


Urig

Professional

Posts: 1,223

Location: Kassel

  • Send private message

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)


NemoN

Professional

Posts: 637

Location: Hamburg (Neu Wulmstorf)

Occupation: QA Engineer

  • Send private message

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.
NAS: Synology D213+
Server: Debian, 2.5" 320GB, 3.5" 2TB, GuruPlug Plus, 10 Watt idle
Client 1: HD/VDPAU (VDR 2.0.x / 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)

gda

Im Forum Zuhause

Posts: 13,337

Location: HH

  • Send private message

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

HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 12.04.2, Plex Media Server
Samsung UE55H6470