ct-VDR 3.06 reagiert manchmal nicht auf Fernbedienung

  • @ gabe


    bei mir kamen die Prob's eindeutig vom Multipatch (bzw. AutoPID). Den DVB-Treiber mit der genannten Firmware hatte ich bereits vor dem Update von Stable auf Multipatch im Einsatz.


    Bzgl. Verzögerungen der Fernbedienung habe ich ähnliche Erfahrungen wie RaK, allerdings noch mit der alten DVB Treiberversion unter vdrdevel gemacht. Nach Abschalten von Text2Skin trat der Effekt seltener auf. Werde den vdrdevel dieses Wochenende mal renovieren und checken, wie er sich mit dem aktuellen DVB-Treiber verhält.


    So long...

  • Also das Multipatch die schlimmeren Probleme hervorgerufen hat, steht außer Frage. Weiß eh nicht so genau, ob mir der gegenüber Bigpatch einen nennenswerten Vorteil bringt.


    Hab gestern Abend nur einen einzigen Hänger gehabt. Und ich habe die ganze Zeit besonders auf die RAM Nutzung geachtet. Vor dem Hänger war mein RAM noch nicht voll und SWAP noch auf 0 MB. Nach dem Hänger war SWAP plötzlich auf 2 MB. Vermute jetzt mal, dass er diese Hänger durch das Auslagern von Speicher hat. Werde demnächst mal von 128 MB auf 256 MB RAM aufrüsten.


    Vielleicht ist das auch mit ein Grund, dass das entfernen von Text2skin manchmal etwas bringt, weil er ja dadurch weniger Speicher belegt. Wenn ich genau zuückdenke, dann habe ich diese Hänger seit ich mir mit InfoSatEPG 7 Tage im voraus Programminfos hole. Es deutet vieles auf die Speichernutzung hin.


    Wie sieht die Belegung bei euch aus? Habt ihr genug RAM-Reserven oder wird bei euch auch auf SWAP zurückgegriffen?


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

  • Das Problem das in diesem Thread diskutiert wird ist alt bekannt.
    Ursache ist vdradmin der nach autotimern sucht und sich epg-daten vom VDR über SVDRSP holt. Während dieser Zeit(je nach Anzahl der Sender und Autotimer einige Sekunden) ist die Auswertung der Fernbedienung über Lirc blockiert.
    Abhilfe könnte XXV sein, der inteligenter die Daten vom VDR über SVDRSP holt.


    Gruß


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Zitat

    Original von MartenR
    Das Problem das in diesem Thread diskutiert wird ist alt bekannt.
    Ursache ist vdradmin der nach autotimern sucht und sich epg-daten vom VDR über SVDRSP holt. Während dieser Zeit(je nach Anzahl der Sender und Autotimer einige Sekunden) ist die Auswertung der Fernbedienung über Lirc blockiert.
    Abhilfe könnte XXV sein, der inteligenter die Daten vom VDR über SVDRSP holt.


    Das klingt logisch und mag ja auch sein. Hatte bis Mittwoch auch einen Autotimer im VDRAdmin drin. Vielleicht ist es durch das Löschen dieses Autotimers auch weniger geworden.


    Ich denke aber, dass das Problem mehrere Ursachen hat, denn beim Multipatch trat es doch viel extremer auf als beim Bigpatch. Und während ich das getestet habe, hatte ich keine Autotimer mehr. Und wie gesagt, gestern ging auch alles glatt, bis auf das eine mal. Deshalb muss SWAP jetzt erstmal weichen und ich werde das weiter beobachten.


    Also für mich sieht es so aus, dass da durchaus mehrere Ursachen dasselbe Sympthom hervorrufen. Deshalb müssen alle bekämpft werden um die Auswirkungen zu unterdrücken.


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

  • Der VDRadmin läuft bei mir sowohl unter der vdr als auch unter vdrdevel. Das Problem mit den LIRC Antwortzeiten tritt jedoch ausschließlich unter vdrdevel auf. Daher kann es imho nicht nur am VDRadmin liegen.


    Aber XXV steht trotzdem auf der Update-Liste :]

  • Zitat

    Original von DonCamillo
    Der VDRadmin läuft bei mir sowohl unter der vdr als auch unter vdrdevel. Das Problem mit den LIRC Antwortzeiten tritt jedoch ausschließlich unter vdrdevel auf. Daher kann es imho nicht nur am VDRadmin liegen.


    Aber XXV steht trotzdem auf der Update-Liste :]


    Also LIRC benutze ich gar nicht, sondern nur das Remote-Plugin. Was auch nur wieder die These unterstützt, dass die Hänger verscheidene Ursachen haben. vdrdevel läuft bei mir auch nicht, hab genug mit vdr 1.2.6 zu experimentieren.


    XXV werde ich auch irgendwann mal testen, bin aber momentan froh, dass der VDR erstmal wieder einsetzbar ist.


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

  • Also ich hatte das Problem auch seit vdr 1.3.21 und auch bei 1.3.22. Manchmal wurde der IR- oder Tastaturbefehl erst nach 20 Sekunden ausgeführt. Zwischenzeitlich hat TomG die 1.3.22 einige Male aktualisiert. Seit dem letzten oder vorletzten Update ist dieses Phänomen hier nicht mehr aufgetreten. Ich habe keine Aussetzer mehr. :]


    Das Abstellen der Zeitsynchronistation über Transponder hatte in der älteren 1.3.22 übrigens keinen Erfolg gebracht...


    vdr 1.3.22/e-tobi/experimental/multipatch

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

  • Ich muss das Thema nochmal aufmachen. Wie geschrieben trat der Fehler in der letzten Subversion der 1.3.22 nicht mehr auf.


    Nach einem Update auf die erste 1.3.23 hatte ich sporadische Aussetzer bis 5 Sekunden. Mit der aktuellen Subversion der 1.3.23-multipatch habe ich jedoch des öfteren wieder längere Aussetzer. Dann werden Befehle an der Fernbedienung oder des Keyboards erst nach bis zu 20 Sekunden nachgeholt. X(

    Debian Squeeze Bullseye mit vdr 1.7.18 2.6.0-1~etobi1 e-tobi/multipatch, AMD Phenom-CPU, 4 GB RAM, Technotrend S2-6400, Digital Devices Cine S2 V6, 2 TByte HDD für Videodaten.

  • Hallo,


    ich habe ein ähnliches Problem, auch schon unter dem Thread http://www.vdrportal.de/board/thread.php?threadid=32869&sid= eingestellt, da ich keine Verbindung gesehen habe, denn meine FB reagierte gar nicht mehr.


    Habe trotzdem mal diesen Thread und eventuelle Lösungsansätze aufgegriffen. Habe also wieder (hatte ich bis zum Timer-Fehler früher schon) den vdradmin-bigpatch installiert.
    .. und siehe da, die FB reagiert wieder, zumindest in ca. 60% der Fälle, was eine enorme Steigerung ist.


    Ich denke, da ist was Oberfaul im Zusammenspiel mit vdradmin.
    Das Problem trat/tritt bei mir nur auf einem CEL566MHz auf, auf einem P4/1,5GHz nicht. Obwohl in beiden Konfigurationen die Prozessorauslastung bei nur 5-10% liegt, die Speicherauslastung auch OK (Swap wird nie in Anspruch genommen vom System), scheint es es ein Performance-Problem zu sein.
    Aber wie, wenn ma über top, etc. dem nicht auf die Spur kommt.


    Hat jemand vielleicht auch ähnliche Entdeckungen gemacht? Denn ein CEL566MHz mit 256MB Ram sollte doch ausreichen, die meiste Arbeit macht ja die FF. Zumindest bis Dato war nie ein Power-Rechner gefragt.


    Oder hat jemand dieses Problem mit einen Power-Rechner, was meine These wiederlegt??? .. könnte ja sein, ist ja nur eine Vermutung.


    Wäre vielleicht interessant von tobi zu hören, was im bigpatch, abgesehen von den Features, anders ist (Speicherhaushalt, verarbeitung von Timern und Autotimern, etc, um da mal hinterzukommen. Es scheint ja mehrere zu wurmen.


    .. und der vdr ist so eine schönes System!!! :]


    SoS.


    LG,
    Sven.



  • Kann bestätigen, dass die Probleme teilweise mit VDRAdmin zusammenhängen. Habe in diesem Thread 4 mögliche Gründe für die Hänger genannt bekommen bzw. selber genannt:
    1. Zeitsynchronisation über Transponder
    2. AutoPID-Patch ode irgendwas anderes bei Multipatch
    3. VDRAdmin / SVDRP-Schnittstelle
    4. Arbeitsspeicher



    Meine Erfahrungen dazu bisher:


    1. Ob an oder aus macht bei mir keinen Unterschied. Kann ich also nicht bestätigen


    2. Als ich auf Multipatch gewechselt habe, hatte ich sehr lange Umschaltzeiten und noch mehr FB-Aussetzer. Deshalb habe ich Bigpatch draufgespielt und beides war weg bzw. wieder geringer. Vermute, dass es am AutoPID-Patch liegt.


    3. Wenn VDRAdmin Autotimer hat, fragt er periodisch (ich glaube alle 10 min) die EPG-Daten nach den Stichwörtern ab und verwendet dazu die SVDRP-Schnittstelle. Anfragen auf diese Schnittstelle rufen wahrscheinlich Aussetzer bei der Fernbedienungsauswertung hervor. Jedenfalls traten diese Hänger bei mir nur auf, falls es Autotimer gab. Wenn mich nicht alles täuscht ist in VDRAdmin Bigpatch enthalten, dass er die EPG-Daten direkt von der Festplatte aus den Dateien ausliest. Also im Endeffekt wurden da die Zugriffe per SVDRP minimiert. (Vermutung)


    4. Wenn ich mir viel in den EPG-Daten anschaue, benötigt er immer mehr Arbeitsspeicher (Cache-Nutzung steigt wahrscheinlich). Und bei der Sysinfo-Abfrage hatte ich vor dem Aussetzer noch 0 MB in SWAP und nach dem einzigen Aussetzer wurde dann die SWAP-Partition angefangen. Weitere Aussetzer hatte ich dann während des Betriebs nicht mehr. Dürfte aber bei 256 MB RAM eher nicht auftreten. Deshalb werde ich demnächst meine 128 MB RAM auch mal aufrüsten.


    Soweit die bsherigen Erkenntnisse meinerseits.
    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4


  • Ich habe VDR auf einem 2.6GHz Celeron und 512MB RAM laufen. Benutze die 1.2.6er Version ohne AutoPID und one AC3oDVB (da DXR3) aus den Tobi Sourcen kompiliert. Die FB wird durch das Remote Plugin gesteuert, also kein LIRC. Die Zeit wird durch NTP über das Internet synchronisiert.
    Ich habe die genannten Probleme nicht. Die einzigen Hänger, die bei mir auftreten stammen von der DXR3...

    Asus Pundit-S 2600 - Celeron 2,6 GHz - 512 MB - Samsung 160 GB - NEC DVD-+RW 1300 - WinTV Nova-T (alt) - DXR3 (Creative);
    c't3 - tobi Distri experimental (Sarge)/ VDR 1.4.x + (DXR3 oder em84xx 4MB bin am testen) , Streamdev, LIRC

  • ... weisser Rauch aus dem Vatikan und meine Fernbedienung funktioniert wieder 1a!


    Was habe ich gemacht?


    vdradmin und bigpatch raus. Multipatch (tobi) rein und xxv installiert.


    Jetzt ist alles OK, es liegt also, zumindest bei mir, doch am vdradmin.
    Scheinbar nimmt der Updatevorgang der Autotimer viel Zeit und Performance in Anspruch. .. leider nur nie mit "#top" oder "#ps ax" zu sehen.


    Zum Gegentest hab ich auch im xxv Autotimer hinterlegt.
    Allerdings stimmt im xxv das Datum in den Timern genauso wenig wie im vdradmin 0.95. .. egal, hauptsache die FB geht wieder.


    Sehr spannend. ALso Tschuess vdradmin ;(


    SoS.


    LG,
    Sven.



  • So ... nun habe ich auch mal LIRC probiert. Und siehe da... ich habe auch z.T. extrem lange Assetzer.
    Da ich 512MB RAM habe, die CPU 2,6GHz hat ... kann es doch eigentlich nicht an fehlenden Ressourcen liegen. Ich habe auch den VDRADMIN laufen. Ich fand ihn bisher besser als xxv. Aber ich werde auch mal den Test machen, VDRADMIN zu beenden und XXV zu benutzen.
    btw. ... kann man den Autotimer von VDRADMIN in XXV importieren?

    Asus Pundit-S 2600 - Celeron 2,6 GHz - 512 MB - Samsung 160 GB - NEC DVD-+RW 1300 - WinTV Nova-T (alt) - DXR3 (Creative);
    c't3 - tobi Distri experimental (Sarge)/ VDR 1.4.x + (DXR3 oder em84xx 4MB bin am testen) , Streamdev, LIRC

  • cyberthom:
    Interessanter Weise ändert ein einfaches stoppen des vdradmin nichts,
    zumindest bei mir. Nur die deinstallation und ein anschliessender reboot halfen.
    Die Neuinstallation von xxv danach brachte keine Verschlechterung
    des Systems, daher hab ich ihn erstmal drin gelassen.


    Warum haben die Entwickler, z.B. Tobi, etc., diese Probleme nicht??
    ... sehr komisch.


    bzgl. Autotimer hatte ich nicht gross geguckt. Da ich nur ca. 10 Autotimer drin habe,
    hab ich die eben manuell reingebastelt.


    SoS.


    LG,
    Sven.



    Einmal editiert, zuletzt von SoS ()

Jetzt mitmachen!

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