Cine S2 szap Problem

  • UFO


    könntest du mal bitte kurz schildern in was für einer Konstelation du die Karte nutzt.


    So könnte man unter Umständen irgendetwas eingrenzen, was ich persönlich nicht verstehe, wieso bei dir die Karte so stabil läuft, bei anderen dagegen andauern blokierte tuner, TS continuity errors etc.auftreten...


    Weil in dem gleichen system eine z.B. Tevi S470 tadellos funktioniert.

    1.Ur-VDR - (discontinued) FF TT 1.6 / 1.3, Skystar 2.6B TB Extension Board - Gentoo
    2. POV ION 330 - TBS 6980 Dual DVB S2 - Ubuntu 10.4

    The post was edited 1 time, last by argo ().

  • Quote

    Original von argo
    könntest du mal bitte kurz schildern in was für einer Konstelation du die Karte nutzt.


    SAT-Anlage:
    (ca. 7 Jahre alt, eigenhändig aufgebaut und ausgerichtet)
    - Kathrein 75cm Schüssel mit 2x UAS 484
    - Preisner Multischalter VS980TN
    - separates Kabel vom MS zu jedem einzelnen Tuner (keine Weichen oder ähnlicher Murks)


    Testmaschine, derzeit:
    - Gigabyte GA-EQ45M-S2, Quadcore-CPU, 4GB RAM
    - TT DVB-S2 6400 (hierzu bitte kein Gelaber in diesem Thread!)
    - cineS2
    - Linux 2.6.32
    - aktuelle DVB-Treiber


    Quote


    So könnte man unter Umständen irgendetwas eingrenzen, was ich persönlich nicht verstehe, wieso bei dir die Karte so stabil läuft, bei anderen dagegen andauern blokierte tuner, TS continuity errors etc.auftreten...


    Was heißt "blockierte Tuner"?
    Bei mir blockieren nur laufende Aufnahmen einen Tuner, und das ist auch gut so. :)


    Wer ein Problem hat, soll er dazu halt einen Thread aufmachen. Mit genauen Fehlerbeschreibungen, HW-Konfiguration, Logs.


    Mögliche Ursachen für TS Continuity-Errors:
    - defekte Karte: Eine bestimmte Serie hatte ein HW-Problem. Wie man so eine Karte identifizieren kann, hatte ich im Monsterthread ausführlich beschrieben.
    - Empfindlichkeit Tuner: s.o.
    - schlechter Empfang


    CU
    Oliver

  • Quote


    Da es mit open/close zu tun hat, müßte man in dvb_frontend.c/stv090x.c ansetzen.


    Man könnte auch einmal dvb-core mit

    Code
    1. dvb_powerdown_on_sleep=0


    starten und sehen, ob sich etwas ändert.



    Hallo Oliver,
    Erstmal danke für den Hinweis. Habe auch gleich mal die Option ausprobiert und die beschriebenen Tests wiederholt. Leider treten alle beschriebenen Probleme immer noch auf.


    Kennst Du vielleicht noch andere Kernel-Parameter, die man noch ausprobieren könnte?


    Anbei noch eine Beschreibung der Tests
    Als root:
    rmmod ngene
    rmmod dvb_core
    modprobe dvb_core dvb_powerdown_on_sleep=0
    modprobe ngene one_adapter=0


    Test:
    1) ./run_szap-s2_adapter0.sh | grep Delay
    Result: OK. Delay is about 0.5sec


    2) ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r
    Result: Not OK. Delay in 1) increases and is ~1.7-1.8 sec


    3) Press Ctrl-C
    Result: Not OK. After ~20 additional iterations in 1), delay is about ~20sec.


    Gruss
    Michael

  • Quote

    Original von repplinger
    Erstmal danke für den Hinweis. Habe auch gleich mal die Option ausprobiert und die beschriebenen Tests wiederholt. Leider treten alle beschriebenen Probleme immer noch auf.


    Dann hängt es wohl nicht am powerdown-Code.


    Quote


    Kennst Du vielleicht noch andere Kernel-Parameter, die man noch ausprobieren könnte?


    Leider nein. Man wird wohl tiefer in den Code einsteigen müssen... :evil:



    Tritt der Fehler eigentlich auch auf, wenn man die Frequenz der szap-Aufrufe verringert, indem man z.B. vor jedem szap-Aufruf so etwas wie

    Code
    1. sleep 1

    einfügt?


    CU
    Oliver

  • Quote

    Originally posted by UFO


    Tritt der Fehler eigentlich auch auf, wenn man die Frequenz der szap-Aufrufe verringert, indem man z.B. vor jedem szap-Aufruf so etwas wie

    Code
    1. sleep 1

    einfügt?


    CU
    Oliver


    Ja, das Problem tritt leider auch auf, wenn man ein sleep 1 zwischen den ./szap Kommandos ausführt. Auch bei mehreren Sekunden Wartezeit zwischen den ./szap Aufrufen tritt das beschriebene Problem auf.

  • Hi,


    ich habe beim testen des Treibers noch eine interessanten Aspekt herausgefunden, der evtl. hilft die Ursache des Problems zu lokalisieren.


    Das Problem mit langen umschaltzeiten konnte ich NICHT reproduzieren, wenn man auf einen HD-Kanal umschaltet, sondern NUR wenn man auf einen SD-Kanal umschaltet (siehe Tests unten).


    Damit ich mir das Problem weiter anschauen kann, wäre es toll, wenn ihr mir folgende Fragen beantworten könntet:


    1) Wird das Tunen auf einen HD-Kanal im DVB-Treiber anders implementiert als das Tunen auf einen SD-Kanal?


    2) Wenn ja, welche Methoden in welchem Modul sind für das Tunen auf einen HD- bzw. SD-Kanal verwantwortlich?


    3) Gibt es im DVB-Treiber (dvb_frontend oder ngene Modul) generell Code/Funktionen in denen explizit zwischen SD- und HD Sender unterschieden wird/muss bzw. soll?


    Anbei eine Beschreibung der Tests (die neue Kanalliste channels_DVB-S2_transponder_switch.conf ist im Anhang):


    1) ./szap-s2 -S 1 -H -c channels_DVB-S2_transponder_switch.conf -a 1 -n 1 -r


    2) Parallel zu 1) mit Adapter 0 tunen auf HD-Kanal
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 2 -x -S 1 | grep Delay
    Delay : 0.569672


    3) Parallel zu 1) mit Adapter 0 tunen auf HD-Kanal
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch_HD.conf -a 0 -n 1 -x -S 1 | grep Delay
    Delay : 0.581712


    4) Parallel zu 1) mit Adapter 0 tunen auf SD-Kanal
    ./szap-s2 -H -c channels_DVB-S2_transponder_switch.conf -a 0 -n 1 -x | grep Delay
    Delay : 1.760880


  • Nein es hängt sicher nicht mit der Systemlast zusammen (ich verwende nur szap-s2 auf einem schnellen System, und sonst nichts CPU- oder IO-lastiges)


    Die guten Nachrichten: Ja, ich kann reproduzieren: Wenn man das frontend device nicht schließt, dann treten keine timeouts bzw. Hänger des Treibers auf, die ein Neuladen des Treibers nötig machen.


    Die schlechten Nachrichten: Ich habe szap-s2 noch eine Zeitmessung nur der Funktion zap_to eingebaut und das Programm mit "-i" im interaktiven Modus gestartet, so dass man TV-Sendernamen auf der Kommandozeile eingeben kann (siehe Anhang .tar.gz).


    Problem: Auch wenn man alle devices offen lässt, hat man die _schlechten_ Umschaltzeiten von rund 1.7 - 1.8 Sekunden (alle Details im angehängten PROBLEMS.txt)


    Ich vermute mal, deshalb hast du in deinen Tests keinen Unterschied gemerkt: Die Umschaltzeiten sind einfach immer so groß mit dieser Karte/Treiber, da ja der vdr direkt alle devices öffnet (egal ob verwendet oder nicht).


    Somit hat man im vdr _immer_ die _schlechten_ Umschaltzeiten, auch wenn man effektiv nur einen Tuner verwendet.


    Das ist doppelt schade: Zum einen haben wir auf allen von uns in den letzten Jahren gemessenen Karten (KNC, Tevii, ..) immer sehr viel bessere Umschaltzeiten gehabt, z.B. 0.7 Sekunden beim Transponderwechsel.


    Andererseits ist uns weiterhin unklar, ob man mit dieser Karte/Treiber überhaupt jemals Umschaltzeiten von 0.7 Sekunden bei _gleichzeitiger_ Verwendung _beider_ Tuner schaffen kann. Umso trauriger, da man ja mit nur einem verwendeten Tuner sehr gute Werte von nur 0.5 Sekunden bekommt.


    Wir werden Euch über Fortschritte - und neue Probleme - weiter auf dem Laufenden halten.


    Gruß, Marco


  • Ja, den open/close-Bug können wir auch bestätigen. Gibt es dazu hier noch weitere Threads/Posts?


    Dann haben wir am Wochenende einen weiteren Bug gefunden:


    Wenn man direkt nach dem Kanalwechsel/Transponderwechsel Daten vom dvr Device liest, dann kommt es etwa in einem von 50 Fällen vor, dass man noch "alte" Daten kommt - obwohl das Tunen bereits abgeschlossen ist. Mit "alte Daten" meine ich, dass man noch Daten des vorherigen Transponders bekommt.


    Das hat sehr "unschöne" Auswirkungen, inklusive TS-Discontinuity Fehler, da ja noch ein paar "alte" TS Pakete empfangen werden, und dann direkt "neue", oder es wird noch eine "alte" PAT empfangen, so dass der Kanalsuchlauf Kanäle nicht findet, usw.


    Diesen Bug können wir auf _keiner_ der anderen der von uns getesteten Karten reproduzieren (TT, Tevii, KNC, ...) (Ja, ich weiß, das habe ich schon mal geschrieben, aber wenn man einen möglichen Bug findet, dann sollte man so fair sein, einen Gegentest mit einer anderen Karte zu machen, ansonsten bekommt man oft nur als Antwort: "Nee, ich kann dein Problem nicht reproduzieren")


    Klar, man kann jetzt einfach einen work-around einbauen: Einfach nach dem Kanalwechsel 1 Sekunde warten (per sleep) und erst dann Daten lesen, hat das Problem behoben. Das erhöht halt nochmal die Kanalwechselzeiten ...


  • Ich kann keine so langsamen Umschaltzeiten bestätigen. Bei meinen Tests achte ich darauf, wenn das Bild kommt.


    Möglicherweise tunt die Karte also schnell, es dauert jedoch aus irgendeinem Grund lange, bis "Lock" angezeigt wird.


    CU
    Oliver

  • Quote

    Original von mlo


    Ja, den open/close-Bug können wir auch bestätigen. Gibt es dazu hier noch weitere Threads/Posts?


    Dies ist der Bug, den ihr gefunden habt. Ist der Vollständigkeit halber aufgeführt. :)


    Quote


    Dann haben wir am Wochenende einen weiteren Bug gefunden:


    Wenn man direkt nach dem Kanalwechsel/Transponderwechsel Daten vom dvr Device liest, dann kommt es etwa in einem von 50 Fällen vor, dass man noch "alte" Daten kommt - obwohl das Tunen bereits abgeschlossen ist. Mit "alte Daten" meine ich, dass man noch Daten des vorherigen Transponders bekommt.


    Das hat sehr "unschöne" Auswirkungen, inklusive TS-Discontinuity Fehler, da ja noch ein paar "alte" TS Pakete empfangen werden, und dann direkt "neue", oder es wird noch eine "alte" PAT empfangen, so dass der Kanalsuchlauf Kanäle nicht findet, usw.


    Dies hängt wahrscheinlich mit dem "Command timeout"-Workaround" zusammen, der momentan im Treiber aktiviert ist.
    Dadurch wird der Datentransfer vom ngene zum Demuxer nicht abgeschaltet.


    Daran wird gearbeitet. Die meisten Tests, die ich derzeit mache, betreffen dieses Problem.


    Einen weiteren Bug habe ich am Wochenende gefixt:
    - Kein Low-Band-Empfang möglich.
    Ich weiß aber nur von 3 Leuten, wo dies auftrat.


    CU
    Oliver

  • Quote

    Originally posted by UFO
    Ich kann keine so langsamen Umschaltzeiten bestätigen. Bei meinen Tests achte ich darauf, wenn das Bild kommt.


    Möglicherweise tunt die Karte also schnell, es dauert jedoch aus irgendeinem Grund lange, bis "Lock" angezeigt wird.


    Hmm, das hört sich ja eigentlich gut an, wenn du das Problem so nicht hast.


    Andererseits haben nun schon verschiedene Leute diese langen Umschaltzeiten mit szap-s2 reproduziert.


    Mit dem Oben angehängten .tar.gz kann man das ja auch in 2-3 Minuten schnell ausprobieren.


    UFO : Was für Zeiten bekommst du denn damit?

  • Quote

    Originally posted by UFO
    Einen weiteren Bug habe ich am Wochenende gefixt:
    - Kein Low-Band-Empfang möglich.
    Ich weiß aber nur von 3 Leuten, wo dies auftrat.


    Ja, haben wir schon gesehen.


    Vielen Dank für den schnellen Fix auch von unserer Seite.

  • Quote

    Original von mlo
    Andererseits haben nun schon verschiedene Leute diese langen Umschaltzeiten mit szap-s2 reproduziert.


    Mit dem Oben angehängten .tar.gz kann man das ja auch in 2-3 Minuten schnell ausprobieren.


    So ganz schnell geht das nun auch wieder nicht. Jedenfalls nicht beim ersten Mal.


    Quote


    UFO : Was für Zeiten bekommst du denn damit?


    Habe jetzt mal getestet: Zeiten liegen im Bereich 0,4-0,5s.


    Allerdings kann ich *keine* Verlangsamung beim Zugriff auf den zweiten Adapter feststellen.


    Randbedingungen:
    - Kernel 2.6.32.3 mit
    - Treiber http://linuxtv.org/hg/~endriss/ngene/
    - 2x cineS2 Karten auf Adapter 1+2, 3+4 (Skripte/Aufrufe entsprechend geändert)


    Weder mit Adapter 1+2 noch 3+4 konnte ich das Problem feststellen.


    Edit:Hier die Logs.
    Terminal 1:


    Terminal 2:


    CU
    Oliver