Dynamite und Tuner abschalten

    Zitat

    Hast Du yaVDR auch unter Proxmox laufen oder ohne Virtualisierung?


    Ganz normale Installation.

    Zitat von mini73

    vdr-freak & mahlzeit:
    Dann müsst ihr den vdr-Patch erweitern. In device.c, dvbdevice.c und dvbci.c gibt es eine Funktion "SetIdle" bzw. "SetIdleDevice". Da könnt ihr nach belieben "isyslog"-Aufrufe einstreuen. Da ihr beide die Hardware durchreicht, vielleicht kriegt der vdr anschließend das Frontend nicht wieder richtig geöffnet, weil der Host irgendwie noch nicht so weit ist? Hab davon aber keine Ahnung.

    Zumindest dippes hat ja auch Probleme mit dem Aufwecken der Devices, obwohl er keine Virtualisierung verwendet.


    Ich habe zwar von Programmierung keine Ahnung, aber nach bestem Wissen die von Dir benannten Funktionen mit isyslog Einträgen ergänzt (den zugehörigen Patch habe ich angefügt). Nun habe ich den vdr gestartet und gewartet, bis alle Geräte eingeschlafen sind... danach habe ich über streamdev versucht einen Stream zu öffnen (ohne Erfolg). So wirklich schlau werde ich aus dem log aber auch nicht. Dass die Devices schlafen gelegt werden, kann man ja noch nachvollziehen (btw. device 1-4 entspricht adapter 0-3). Das mit dem Aufwecken kann ich allerdings noch nicht ganz nachvollziehen.



    Irgendeine Idee?

    Jetzt schieb ich direkt noch eine Log hinterher. Habe nun gewartet, bis die Geräte wieder idle waren und nochmal einen stream geöffnet... und siehe da, nun geht es. Das gleiche device (adapter 3 bzw. device 4) was gerade eben noch nicht ging... das soll mir mal einer erklären ;). Ich habe den vdr in der Zwischenzeit nicht neugestartet!!!


    Beim ersten mal fällt mir als Unterschied nur die Zeile 51 auf:

    Code
    Nov 13 21:45:42 myVDR vdr: [3372] frontend 3/0 timed out while tuning to channel 24, tp 110802


    War das der Kanal, den du per streamdev angefordert hast?
    Beim zweiten Versuch taucht die Meldung nicht auf.


    War die Karte beim ersten mal auf einen anderen Kanal getunt, so dass umgeschaltet werden musste?
    Vermutlich war sie beim zweiten Versuch schon auf Kanal 24, so dass an der Ecke vielleicht nichts gehakt hat und der Kanal schneller gelockt werden konnte.


    Ansonsten sieht das Log so aus, wie ich es erwarten würde. Es werden alle Funktionen aufgerufen, um die Karte wieder aufzuwecken (so auf den ersten Blick).
    Aber natürlich kann es irgendwo immer noch Timing-Probleme geben. Geht es eigentlich um DVB-S(2)? Ich hab nur DVB-C, da geht das Tunen naturgemäß etwas schneller als bei Sat.


    Lars.

    Ja, channel 24 war der Kanal, den ich über streamdev angefordert hatte (bei beiden Versuchen). Beim zweiten Versuch taucht diese Meldung nicht auf, weil es kein time out gab und das 'tuning to channel' erfolgreich war (oder sollte wirklich ein Logeintrag erfolgen, wenn das tuning erfolgreich war?).


    Vor dem ersten Versuch hatte ich auch channel 24 auf dem gleichen device. Jedoch kann es sein, dass ein epg-scan das device auf andere Kanäle umgeschaltet hat (ich kann aus dem Log nicht erkennen, welches device für epg scan verwendet wird). Die Vermutung, dass das device beim zweiten Versuch bereits auf Kanal 24 geschaltet war, kann ich noch nicht ganz nachvollziehen. Das erste log zeigt, dass frontend 3/0 (device 4) nicht auf channel 24 schalten konnte. Im Anschluss hat der vdr dann versucht auf verschiedenste Kanäle zu schalten (epg-scan?), jedoch auch ohne Erfolg. Der letzte Versuch war das Schalten auf Kanal 26, bevor das device dann schlafen gelegt worden ist. Danach kam ja erst wieder Kanal 24 ins Spiel (den ich aktiv über streamdev angefordert habe).


    Bei mir geht es um DVB-S2.
    Wie Du bereits schreibst, werden die Funktionen zum Aufwecken der Devices aufgerufen. Heisst das nun im Umkehrschluss, dass es sich um ein Treiberproblem handeln muss? Oder wie muss man mit eventuellen Timing-Problemen umgehen? Das komische ist ja wirklich, dass wenn erst mal ein "timed out" aufgetreten ist, das entsprechende Device frühestens nach erneutem Schlafenlegen und wieder Aufwecken funktioniert (zumindest nach aktuellem Kenntnisstand).

    Schwer zu sagen, ist ja auch nicht einfach nachzustellen.
    Treiber, Timeouts im vdr, Races oder irgendwas mit meinem Patch... ist alles möglich.


    Lars.

    Ok, ich verstehe, dass das alles sehr komplex ist. Aber wie kann man sich denn dem Problem annähern? Könnte man denn z.B. die Timeouts entsprechend verlängern, so dass man diese ausschließen kann?


    Ich habe ein großes Interesse daran dieses Problem zu lösen und bin gerne bereit hier weiter aktiv zu testen. Leider bin ich kein Programmierer und brauche daher Hilfestellung an welchen Schrauben gedreht werden muss.


    Das Problem kann ich zwar nicht direkt erzwingen, aber es tritt so häufig auf, dass ein debuggen möglich sein sollte. Letzte Nacht hatte ich testweise nochmals Timer erstellt. Alle devices schliefen. Von drei aufgeweckten devices war nur ein device in der Lage auch auf den entsprechenden channel zu tunen. Die anderen beiden brachten wieder nur "timed out". Heute Morgen lief dann erst mal wieder alles wie es sollte.


    Zur vollständigkeit hier noch das installierte Treiberpaket:

    Code
    $ apt-cache policy media-build-experimental-dkms
media-build-experimental-dkms:
  Installiert: 0~20130831.210530-1yavdr1~precise
  Kandidat:	0~20130831.210530-1yavdr1~precise
  Versionstabelle:
 *** 0~20130831.210530-1yavdr1~precise 0
    	500 http://ppa.launchpad.net/yavdr/main/ubuntu/ precise/main amd64 Packages
    	100 /var/lib/dpkg/status

    Servus,


    an der Problemlösung wäre ich auch interessiert, zwischen den Aufnahmen könnte ich auch mal testen. Kann zwar einigermaßen Programmieren, aber mit C/C++ und den VDR Gegebenheiten habe ich mich noch nicht auseinandergesetzt-


    cu
    Markus

    Ich habe gerade nochmal mit femon die devices beobachtet. Dazu habe ich alle devices per svdrpsend Befehl schlafen gelegt und dann ein device geweckt (hierbei ist kein Client mit dem VDR Server verbunden). Nach dem Aufwecken versucht der vdr server direkt einen channel zu tunen und bringt ein timeout. Nach einigen Sekunden sehe ich aber im femon einen lock.


    svdrpsend und femon:


    syslog:


    Hierbei ist mir auch aufgefallen, dass devices, die einen Lock haben, manchmal auch nach dem Schlafenlegen über femon noch einen Lock anzeigen, jedoch mit Fehlerweten bei SNR und BER. Ist das normal? Zum Beispiel wie hier:


    Manchmal ist der Status der devices nach dem Schlafenlegen auch nur "SC", ohne FE_HAS_LOCK. Manchmal auch mit leerem Status, auch ohne FE_HAS_LOCK. Kommt mir irgendwie komisch vor.

    Und weil es so schön ist direkt noch ein Szenario. Device schlafen gelegt und wieder aufgeweckt... danch kein Lock mehr (Signalwert ändert sich dann mal, wenn der vdr versucht auf einen anderen Kanal zu wechseln, sonst passiert nix). In der Syslog sind dann dauerhauft "timed out" Einträge mit den jeweiligen channels (habe ich mir gespart anzufügen)...



    Update: Auch hier will ich nochmal anmerken, dass ein erneutes Schlafenlegen des device und wieder aufwecken das Problem löst.

    Wenn dynamite das Device "schlafen" legt, heißt das letztlich nur, dass alle Filedescriptoren geschlossen werden. Dass dann manchmal noch ein Lock vorhanden ist und manchmal nicht, ist Zufall. Es ist ja keine Anwendung mehr da, die den Tuner steuert. Was dann also passiert, ist Treibersache. Vielleicht hält der Treiber noch den Lock, vielleicht auch nicht - keine Ahnung.
    Jedenfalls kann man davon ausgehen, dass die Karte in einem "undefinierten" Zustand ist, wenn alle Descriptoren geschlossen wurden.


    Vielleicht fehlt ja noch ein wichtiges Detail beim wieder Öffnen, also in "OpenFrontend". Muss ich mir mal bei Gelegenheit ansehen.


    Lars.

    Vielleicht könntest du in dvbdevice.c in der Funktion "CloseFrontend" noch was einbauen:


    Lars.

    Schade. Dann muss ich erst länger drüber nachdenken, hab aber keine Ahnung, wann ich Zeit dafür finde.


    Ohne dynamite bekommt streamdev immer ein Bild?


    Lars

    Ohne "AutoIdle" bekommt streamdev immer ein Bild (dynamite selbst bleibt grundsätzlich aktiv, es geht ja nur ums Schlafenlegen der devices).
    Danke für Deine bisherigen Bemühungen. Sobald Dir was einfällt, will ich gerne testen!


    Gibt es denn einen Ansatz den Debug-Output des Treibers zu sehen? Vielleicht ist ja etwas auffällig, wenn sich das device schlafen legt bzw. aufgeweckt wird.

    Ich habe das idle meines USB DVB Adapters ausprobiert. Der Suntek USB Stick wurde wie gewünscht abgeschaltet und bei Bedarf wieder aktiviert.
    Allerdings gibt es bei mir den Seiteneffekt das auch mein USB MCE IR Emfänger deaktiviert wird, weshalb ich den idle Parameter wieder deaktiviert habe.


    Bus 003 Device 002: ID 2659:1208 idle ok
    Bus 001 Device 003: ID 15c2:0038 SoundGraph Inc. GD01 MX LCD Display/IR Receiver idle ok funktioniert weiter
    Bus 002 Device 003: ID 0609:031d SMK Manufacturing, Inc. eHome Infrared Receiver idle nicht ok


    Wie erkennt dynamite das das USB Gerät ein DVB Device ist?

    Gruß
    Frodo

    Ob USB oder nicht, ist dynamite total egal.
    Wenn der vdr eine zeitlang nicht OpenDvr von cDvbDevice aufgerufen hat, dann werden einfach alle Filedescriptors geschlossen, mehr nicht. Sobald der vdr wieder irgendwas von dem DVB-Gerät will, werden sie wieder geöffnet.


    Ob da vielleicht irgendein Energiemanagement vom USB-System zuschlägt und die Hubs deaktiviert?
    dynamite kümmert sich jedenfalls nicht um USB.


    Lars.

    Kommisch, ohne

    Code
    --idle-timeout=5
--idle-wakeup=5

    hatte ich noch kein Ausfall. ?(


    Eventuell kommen meine Probleme aber auch woanderst her, ich habe ja auch Probleme mit /usr/bin/lircd2uinput welches 100 % CPU Last erzeugt und deshalb von mir deaktiviert wurde.

    Gruß
    Frodo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden