Beiträge von klausL

    Ouch, my typo. Good catch, thanks! Could you check whether the attached patch works with default settings of GSSBOX?

    It works with the gss box default timeout of 60 seconds. Thank you very much for your fast reaction.


    At the moment I have no more problems with the gss box. The plugin also works great in my stable yavdr 0.5.


    Best regards


    klausL

    Unfortunately the minimal keepalive time in tuner.h of Version 0.2.1 still has a value of 300 seconds, which for me is too high.

    Code
    eMinKeepAliveIntervalMs = 300000, // in milliseconds


    I changed it to 3000 Milliseconds (anything below 60 seconds) and it works as expected.


    KlausL

    Hi,


    good question. With telnet to Port 554 I got the following dialogue:


    As you can see, the RTSP answer indeed contains the timeout value.


    Best regards and many thanks for working on the plugin.


    klausL

    Hi,


    I also have a GSS box and I use it with yavdr 0.5 testing (vdr 2.0.4) and vdr-plugin-satip 0.2.0. I did some tests regarding the above mentioned RTSPSessionTimeout value in the GSS box. I found the following: The default timeout value in the gss box is 60 seconds (at least it was in my box). After about 60 seconds my video stream is broken, the picture freezes and wont start again. By changing that value in the gss box I can determine the time when the video stream breaks and the picture freezes.
    In the file tuner.h of vdr-plugin-satip I found two keepalive interval values and changed them:

    Code
    eMinKeepAliveIntervalMs = 30000, // in milliseconds
    eDefKeepAliveIntervalMs = 50000 // in milliseconds


    The original values were 300000 and 600000 milliseconds.
    So now the value in the GSS box is 60, the KeepAliveInterval values are less than 50 seconds.
    This works very well for me.
    My conclusion: The keepalive interval value in in the file tuner.h of vdr-plugin-satip must be less than the
    RTSP Steam Timeout value in the gss box.


    Setting the value in the gss box to 0 (obviously meaning infinite) also fulfils this condition but might not be the best choice.


    KlausL

    Hallo,


    ich habe diese Woche ein DSI 400 von GSS in Betrieb genommen. Ich bin bei den Default-Einstellungen mit Unicast-Transport geblieben. Mit Hilfe der Beiträge weiter oben und eigenem Experimentieren bin ich soweit gekommen, dass mein yavdr 0.5 (Testing) mit dem IPTV-Plugin (Version 2.0.0) Programme abspielt und Aufnahmen macht. Ich habe in der Liste der Pids noch die Standard-Pids 18 und 20 ergänzt. Damit geht auch das EPG !
    Die Einträge in der channels.conf sehen so aus:


    Code
    Das Erste HD;ARD:10:S=0|P=0|F=CURL|U=http%3A//10.0.1.90/?src=1&freq=11494&pol=h&msys=dvbs2&sr=22000&pids=0,18,20,5100,5101,5102,5103,5106|A=0:I:22000:5101=27:5102=deu@3,5103=mis@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
    ZDF HD;ZDFvision:20:S=0|P=0|F=CURL|U=http%3A//10.0.1.90/?src=1&freq=11361&sr=22000&pol=h&msys=dvbs2&pids=0,18,20,6100,6110,6120,6121,6123,6122|A=0:I:22000:6110=27:6120=deu@3,6121=mis@3,6123=mul@3;6122=deu@106:6130;6131=deu:0:11110:1:1011:0


    Damit das IPTV-Plugin mehrere Kanäle gleichzeitig benutzt, ist wohl notwendig in /etc/vdr/plugins/plugin.iptv.conf z. B. -d 4 einzutragen.


    Ich bleibe dran und werde weiter experimentieren.

    ja, auch Timestamps gehen. Hier noch mal der strace ab restart dbus:



    Ich habe gesehen, dass vor dem restart dbus der kritische Thread zwar keine Meldungen im strace produziert, aber unter der VDR-Prozess-ID werden auch solche Meldungen gezeigt. Hier ein kleiner Ausschnitt vom strace des VDR-Hauptprozesses vor dem restart dbus.



    Das könnte man womöglich auch so interpretieren, dass die Timeouts eigentlich immer da sind, und irgendwie die Übergabe in den Thread zu einem Hänger führt.


    Klaus

    Ich habe mal etwas weiter geforscht und noch ein paar Effekte gefunden:
    - Nach dem "restart dbus" geht ja die CPU-Last runter. Wenn man dann einen "restart vdr" absetzt, ist die Auslastung wieder bei 100 %.


    - Ich habe auf der dbus-Seite das Monitoring angeworfen, um zu sehen, was da ankommt.


    Beim Starten des VDR an der Konsole ("start vdr") sieht der dbus-monitor etwa 60 Ereignisse, die schnell hintereinander ablaufen:



    Nach der letzten Meldung ist dann Ruhe. Wie gehabt ist dann die CPU-Last bei 100%, erzeugt durch einen der VDR-Threads.


    Ein strace mit der Thread-ID desjenigen Thread, der die CPU auslastet (also noch vor dem restart dbus), bleibt schlichtweg leer !
    Nach einem restart dbus wird aber direkt etwas protokolliert:


    Ab gettid()... erscheint direkt nach dem restart dbus.


    Klaus

    Nach Installieren der 0.5-alpha mit vdr-plugin-targavfd hat zunächst mein Targa-VFD-Display nichts angezeigt. Nach einigem Suchen bin ich darauf gestoßen, dass die udev-Regel in /etc/udev/rules.d/93-targavfd.rules in ubuntu 12.04 einen scheinbar nicht mehr unterstützten Syntax mit sysfs-Attributen verwendet.
    Statt:

    Code
    ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="19c2", SYSFS{idProduct}=="6a11", GROUP="vdr"


    habe ich

    Code
    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="19c2", ATTR{idProduct}=="6a11", GROUP="vdr"


    eingesetzt.


    Damit funktioniert das Plugin wieder wie gewohnt. Es wäre natürlich wünschenswert, dass die Korrektur auch in die Distribution einfließt.


    klausL

    Hallo,


    ich habe gerade noch etwas gesehen:
    Gleich nach der Installation der 0.5 hat htop schon mal die 100% Auslastung angezeigt. Damals war mir aufgefallen, dass der irserver alle paar Sekunden mal kurz die CPU mit über 80 % auslastet. Nach Lesen in der yavdr-Doku hatte ich den Eindruck, dass ich den irserver nicht brauche, weil ich einen Atric mit lircd für die Fernbedienung verwende, und habe den irserver lahmgelegt (die "start on"-Zeile auskommentiert).
    Mit dem heutigen Update war auch was mit dem irserver dabei. Da fiel mir die auskommentierte Zeile ein und ich habe sie mal wieder aktiviert.
    Das Ergebnis: Alle 5 Sekunden startet der irserver und beendet sich wieder.
    Im syslog:

    Code
    Jun 17 22:40:12 VDR kernel: [40046.434097] init: irserver main process (11552) terminated with status 255
    Jun 17 22:40:12 VDR kernel: [40046.434123] init: irserver main process ended, respawning


    htop zeigt dabei durchgehend 100% CPU-Auslastung an.
    Nach einem "restart dbus" zeigen die VDR-Threads keine hohe CPU-Belastung mehr (wie bereits bekannt), aber die angezeigte CPU-Auslastung ist immer noch 100 %.
    Nach einem "stop irserver" ist die Last direkt wieder unten bei 16 %. Meine Fernbedienung geht natürlich trotzdem.
    Damit wäre zumindest eine zweite Möglichkeit da, die die CPU-Auslastung hochtreibt. Ob es eine gemeinsame Ursache gibt, kann ich nicht erkennen.


    Klaus

    Hallo,


    der restart dbus funktioniert auch bei mir zuverlässig.
    Ich habe nichts am USB hängen (außer manchmal ne Tastatur).


    Hier auch noch mein Log ab dem "restart dbus". Der avahi-daemon muss sich wohl auch neu sortieren. Zwischendrin (Zeile 13) gibt es mal einen connection error.



    Die Threads sieht man übrigens sehr schön mit den Tool htop, mittels F5 dann in die Tree-Ansicht gewechselt. Dort ist dann auch pro Rgread die CPU-Auslastung ablesbar. Fast so schön sind sie auch mit ps ax -T zu sehen.


    Klaus

    Hallo,


    Ich habe gerade einen vielleicht interessanten Effekt gesehen: Wenn ich den dbus-daemon mitten im laufenden Betrieb kille (kill -9 ...) dann wird er automatisch gleich wieder gestartet, die CPU-Auslastung sinkt aber auf ca. 15 % (!!!!) bei meinem Sempron und der vdr läuft weiter.
    Im Moment geht alles, die Auslastung bleibt niedrig.


    Mir war noch was aufgefallen: Als ich in der Prozessliste zum ersten Mal nach dem dbus-daemon gesucht habe, waren zwei unabhängige dbus-daemon-Prozesse mit unterschiedlichen Parametern zu sehen. Ich habe beide gekillt, worauf wieder einer automatisch neu gestartet wurde. Nach einem Ausschalten (nach S3 !) und wieder hochfahren war nur noch ein dbus-daemon zu sehen, aber die Auslastung wieder bei 100 %. Daemon gekillt und die Auslastung war wieder bei 15 %, der daemon ist gleich wieder neu gestartet. Seit dem läuft der VDR, alles geht.


    Bleiben also zwei Fragen:
    - Werden bei einem kompletten Reboot zwei Dbus-daemon-Prozesse erzeugt ? Kann ich erst später testen, jetzt muss der Fernseheer erst mal laufen (Alpha-Version im Wohnzimmer !).
    - Wird der jetzt laufende daemon zu früh erzeugt ?


    Ich bleib dran.


    Klaus

    Hallo,


    ich habe die Version aus unstable mal installiert und damit den vdr neu gestartet. Die CPU-Auslastung ist unverändert, aber es kommen ein paar mehr Logmeldungen.


    Alle Logmeldungen beim Starten des vdr (ab Plugin-Start):



    Der Thread 2700 ist derjenige, dem die CPU-Auslastung zugeordnet ist.


    Während der Laufzeit und einem Stop des vdr kommt dann (hier wieder alle Logmeldungen, nicht nur die vom Plugin):



    Beim Stop bleibt der Vdr allerdings hängen, der Thread läuft weiter mit fast 100% CPU und wird nach 60 Sekunden vom Watchdog unsanft beendet. Dazu könnte passen, dass der Thread keine Logmeldung mehr im syslog hinterlässt. Es sieht also so aus, als ob sich der Thread nicht mehr per stop DBUS-Upstart-Signal-Sender beenden lässt.


    Klaus

    Hallo mini73,


    ich sehe keine weiteren Logmeldungen mit dbus-Bezug. Ein "can't emit upstart signal" war nicht im syslog, ebenso wenig noch andere Meldungen. Ich habe noch mal gecheckt, aber es waren alle Meldungen zu dbus und dbus2vdr in meinem Beitrag.


    Wenn ich in der /etc/init/vdr.conf unter "start on" die Zeile "(dbus-activation de.tvdr.vdr and startup) or \" rauslösche, ändert sich am VDR-Verhalten bei einem Systemneustart nichts. Es funktioniert alles wie gehabt einschließlich der 100% CPU.


    KlausL

    Noch mal meine Logeinträge etwas genauer (mir hatte das rate-limit einen Streich gespielt):


    Wenn der VDR startet, kommen folgende plugin-bezogenen Meldungen im syslog:


    Darin ist sehen, dass unter TID 1721 der DBus-Upstart-Signal-Sender thread gestartet wird. Dieser Thread gibt dann keine Meldungen mehr aus, erzeugt aber (gesehen mit htop) die fast 100% CPU-Auslastung.


    Beim Beenden des VDR werden dann folgende Meledungen ausgegeben:


    Der Thread 1721 meldet sich beim Stoppen des Plugin zunächst mit "emit upstart-signal vdr-plugin for started" und später mit den 4 Meldungen am Ende.


    Mehr ist von diesem Thread nicht zu sehen, auch der DBus-Daemaon hinterlässt während der VDR-Laufzeit ansonsten keine Spuren im syslog.
    Mit mehreren VDR-Restarts ändert sich natürlich immer die TID, aber es ist immer der DBus-Upstart-Signal-Sender-Thread, der die CPU-Auslastung erzeugt.


    Würd' mich freuen, wenn das zur "Erhellung" beiträgt.