Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

21

Freitag, 11. Juni 2010, 16:53

Zitat

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

22

Freitag, 11. Juni 2010, 17:31

RE: [ANNOUNCE] VDR developer version 1.7.15

@TomJoad
Danke läuft wieder.
WoZi: VDR 2.2.0 auf OpenSuse Leap, Kernel 4.7.0-RC5, TT-Budget S2-3200 PCI, TechnoTrend TVStick CT2-4400, Kodi git
SchlafZi: VDR 2.2.0,
OpenSuse Leap, Kernel 4.3.1,Kodi, Hauppauge Nova HD-S2


23

Freitag, 11. Juni 2010, 17:32

Zitat

Originally posted by balta

Zitat

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
Mach mit beim VDR User Counter!

24

Freitag, 11. Juni 2010, 18:58

@KLS

Opps,

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

alles i.O

25

Freitag, 11. Juni 2010, 19:20

Zitat

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:

Quellcode

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:

Quellcode

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

Freitag, 11. Juni 2010, 19:45

Zitat

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

Das müsste der Index auf

Quellcode

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

27

Freitag, 11. Juni 2010, 20:06

Zitat

Original von FireFly

Zitat

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

Das müsste der Index auf

Quellcode

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »balta« (11. Juni 2010, 21:00)


28

Samstag, 12. Juni 2010, 01:43

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

Samstag, 12. Juni 2010, 02:24

Zitat

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »balta« (12. Juni 2010, 02:52)


30

Samstag, 12. Juni 2010, 09:56

Zitat

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

Samstag, 12. Juni 2010, 23:46

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

32

Sonntag, 27. Juni 2010, 17:22

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

Montag, 28. Juni 2010, 09:25

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

Fortgeschrittener

Beiträge: 501

Wohnort: Rheda-wiedenbrück

Beruf: IT

  • Nachricht senden

34

Montag, 28. Juni 2010, 15:01

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

35

Montag, 28. Juni 2010, 21:46

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »prometheus« (28. Juni 2010, 22:28)


36

Montag, 28. Juni 2010, 22:40

Zitat

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

Samstag, 10. Juli 2010, 14:27

@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 ?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »hotzenplotz5« (10. Juli 2010, 14:29)


38

Samstag, 10. Juli 2010, 15:46

Zitat

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.


Zitat

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Urig« (10. Juli 2010, 15:49)


NemoN

Profi

Beiträge: 665

Wohnort: Hamburg (Neu Wulmstorf)

Beruf: QA Engineer

  • Nachricht senden

39

Samstag, 10. Juli 2010, 20:00

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.

40

Samstag, 10. Juli 2010, 20:19

Zitat

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 14.04.1, Plex Media Server
Samsung UE55H6470

Immortal Romance Spielautomat