Posts by HelmutB

    Das macht ein Patch von HelmutB (vdr-2.4.7-SignalMonitoring2.patch). Ob es einen realen Signalverlust gab (Sat-Schüssel), die DVB-S Karte bisweilen spinnt, oder der Patch zu nervös ist, läßt sich nicht sagen.

    Wenn es während der Aufnahme zu einem Signalverlust kommt, solltest du zuerst so eine Meldung im syslog sehen:

    frontend 1/0 lost lock on channel....

    Erst wenn danach 11 Sekunden lang kein Signal kommt, versucht der SignalMonitoring-Patch für Livebild oder Aufnahme auf ein anderes freies Device umzuschalten. Zu sehen mit No signal on tp xxx for channel... und retuning due to modification of channel....

    Du kannst es testen, indem du das Antennenkabel abziehst.

    LG Helmut

    dann könnten ja nie mehrere Applikationen den gleichen Filter benutzen.

    Du hast recht, eher unwahrscheinlich - aber dann sollte sich die Änderung in pat.c überhaupt nicht auf w_scan_cpp auswirken.

    Vielleicht bringe ich den SAT-Scan zum laufen und sehe dann mehr,

    LG Helmut

    Den Filehandle nicht, aber vielleicht wird mit einem Del() in dmxdev.c des Kernel der Filter entfernt und es kommen keine Daten mehr zum cPmtScanner von w_scan.

    Ich habe es gestern nur kurz mit DVB-T getestet und w_scan_cpp hat auch mit vdr-2.5.5 alle Programme gefunden, ich kann den Fehler also noch nicht nachvollziehen,

    DVB-S mit Unicable/SCR funktioniert bei mir nicht, da fehlt ein passendes ProvidesTransponder().


    Mit StopSectionHandler/StartSectionhandler könnte man vielleicht feststellen ob sich hier etwas in die Quere kommt.

    LG Helmut

    wirbel : So wie ich das sehe, behandelt w_scan die Sections eigenständig und damit am device::Sectionhandler vorbei - so wie hier zu sehen:

    Daher weiß der VDR klarerweise nichts von zusätzlichen Usern und kann sie beim Del() auch nicht berücksichtigen

    Wie wäre es, vor dem Scan die VDR-Sectionhandler mit cDevice::StopSectionHandler() zu beenden, und danach mit cDevice::StartSectionHandler wieder zu starten (ich habe es selbst aber noch nicht ausprobiert) ?

    LG Helmut

    Wird softhddevice nicht zu deinem primary device ? Ohne geht es natürlich nicht:

    Code
    1. * VDR errors from /var/log/messages:
    2. * ERROR: invalid primary device number: 4
    3. * ERROR: no primary device found - using first device!
    4. * ERROR: invalid primary device number: 1
    5. /usr/bin/vdr: no process found
    6. * ERROR: vdr failed to start

    Es gibt doch auch diesen Parameter: softhddevice.MakePrimary = 1 #0 = unverändert, 1 softhddevice wird Primärgerät beim Start

    LG Helmut

    Ohne Tuner startet vdr nicht.
    Könnte man das nicht gleich ganz mit aufheben? Wie starte ich auf dem Mond einen vdr zum Aufnahmen anschauen?

    Ich habe probeweise mit "-D-" alle Devices deaktiviert. Mit xineliboutput und vdr-sxfe startet mein vdr und ich kann auch auf die Aufnahmen zugreifen. Ohne Ausgabe startet der VDR auch mit dem dummydevice Plugin.

    LG Helmut

    Das Problem mit falschen PLPs gibt es beim ORF hier in Wien auch. Da wird auf einem von 6 Transpondern die falsche PLP 0 statt 1 geliefert. Wenn du Update.Channels=5 verwenden willst und den VDR patchen und selbst bauen kannst, sollte dieser kleine Fix für DVB-T2 genügen:

    Man verpasst damit überhaupt nichts, weil bei DVB-T2 sowieso keine neuen Transponder hinzugefügt werden und ein Update der Transponderparameter auch nicht notwendig ist, da der gewünschten Stream ja schon empfangen wird.

    LG Helmut

    Hier die Version 2 mit ein paar Korrekturen und Fehlerbereinigungen:

    - In eitscan.c war der Signalstatus noch nicht berücksichtigt, dadurch wurden auch Devices ohne Signal für den EPG-Scan ausgewählt

    - bei den Codestellen rund um ProvidesTransponder() und ProvidesChannel() wird nun (wo erforderlich) ebenfalls der Signalstatus berücksichtigt

    - in cDvbTuner::Action() wurde der Code für das richtige Setzten von DataTimeouts überarbeitet und ist nun (zumindest für mich) auch besser lesbar.


    Helmut

    Es war hier im Forum schon öfters zu lesen, das es manchmal schwierig sein kann, den VDR so einzurichten, dass z.B. ein gemischter Betrieb von mehreren DVB-T/C Adaptern oder eine nur teilweise Belegung der Antennenanschlüsse von Multi-Tunerkarten möglich ist.


    Ich habe mir dazu einen Signal-Monitoring Patch überlegt, der diese Sonderfälle automatisch erkennen und auch richtig behandeln sollte.

    Das ganze funktioniert ähnlich wie schon in diesem und den darauffolgenden Posts angedacht: feature-request-beschränken-von-c-t-tunern-auf-eine-empfangsart:

    Ein Device kann 2 Signalzustände haben: Signal und NoSignal. Bei der Deviceauswahl für Live oder Aufnahme kommen nur solche mit Signal in Betracht (beim Start von VDR haben alle Devices ein "Signal"). Wird nach einem gewissen Timeout kein Signal erkannt, wird ein der Status auf NosIgnal gesetzt, ein Retune ausgelöst und das nächste verfügbare Device gewählt. Wenn keine Devices mit Signal mehr verfügbar sind, werden die NoSignal Devices der Reihe nach wieder verwendet.

    Zusätzlich wird nach jedem Programmwechsel im Hintergrund mit dem gleichen Transponder auch auf alle NoSignal Adapter getuned - so kann deren Status relativ schnell auf Signal angehoben werden, falls sich am Empfang etwas verändert hat.

    Man kann damit z.B. auch im laufenden Betrieb ein Antennenkabel von einem Device auf ein anderes umstecken, mit dem Patch sollte es nach ein- oder mehreren automatischen Retunes wieder ein Bild geben.

    Und wurde auf einem T/C Adapter ein z.B. DVB-T Signal gefunden, wird das DVB-C Frontend bei allen folgenden Anfragen blockiert - und natürlich auch umgekehrt mit C/T.


    Bei meinen Tests war das Ganze ziemlich brauchbar, das echte C/T Verhalten konnte ich aber in der Praxis nicht testen.

    Der Patch ist für vdr-2.4.7 geschrieben, lässt sich aber auch auf vdr-2.5.3 anwenden.


    Helmut

    Deine Plugins sollten schon passen, das war ein Gedankenfehler von mir.


    Zum Log - in den Microframes mit Länge 0 sind keine brauchbaren Daten, es gehen tatsächlich so viele Pakete verloren.

    Und nach ca. 10 Sekunden sind die Daten auch nicht mehr als TS-Pakete zu erkennen (obwohl im 1.Byte immer das Sync-Byte (0x47) zu sehen ist - das bedeutet nichts, das ist nur eine Eigenheit des SMIT-Moduls).


    Was mir jetzt noch einfällt, wäre es mit options wintv_usb2ci use_dma_coherent=1 zu versuchen, da bin ich aber nicht sicher, ob das auf ARM-Platformen überhaupt verwendet werden soll oder kann.

    Und mitoptions wintv_usb2ci dummy_half_uframes=2 , 1 oder 0.

    Den cidebug-Patch kannst du wieder herausnehmen.


    LG Helmut

    Ich habe mir jetzt das syslog angesehen und es sind mir doch einige Dinge aufgefallen:

    Um 19:08:27 startet der Datentransfer zum CI, die Daten die zurückkommen sind noch verschlüsselt, und nach ca. 1 Sekunde wird für fast jeden zweiten Microframe (enthalt 4 TS-Pakete) die Länge 0 - also leer angegeben. Anhand der Continuity-Counters erkennt man, dass damit tatsächlich 50% der TS-Pakete fehlen.

    Ab kurz vor 19:08:46 stimmt etwas mit den TS-Daten die an das CAM gesendet werden nicht mehr - die ersten 4 Bytes ergeben keinen regulärer TS-Header. Das kann aber nichts mit dem WintvCI zu tu haben, denn die vom Treiber selbst eingefügten TS-Null Pakete kommen korrekt wieder aus dem CI. Außerdem wird immer noch nichts entschlüsselt - möglicherweise stimmt etwas mit dem Plugin nicht.

    Wie ist es mit FTA-Programmen - laufen die ohne Probleme, bzw. gibt das ci-Plugin keinen Fehler aus?


    Im Anhang ein Patch der auch Microframes mit Länge 0 verarbeitet - möglicherweise sind die fehlenden TS-Pakete doch vorhanden. Kannst du damit noch einmal ein Log erstellen.

    Und - du hast es vermutlich eh schon ausprobiert - einmal mit options wintv_usb2ci dummy_half_uframes=2 testen. So geht es bei meiner SMIT auch.

    LG Helmut

    Da gehen zu viele Pakete auf dem Weg zum/vom Modul verloren - ich vermute fast alle. Da muß ich etws nachdenken.

    Du erhälts noch (viel) mehr Debugausgaben, wenn du in wintv-ci-ci.c in Zeile 57 und 58 die beiden defines auf 1 setzt,

    Code
    1. /* a lot of TS in/out massages */
    2. #define DEBUG_TS_IO 0
    3. #define DEBUG_TS_IN 0
    4. #define DEBUG_TS_SYN 1

    und auch dei Moduloption options wintv_usb2ci show_ts_bitrate=1verwendest.

    Vielleicht sieht man dann besser, wo auf dem Weg die Pakete verloren gehen.

    Ändert die Auswahl des USB-Anschluß irgend etwas? (es wird aber vermutlich keinen Unterschied machen)

    LG helmut

    Ja, du bekommst überhaupt keine brauchbaren Daten, das Sync-Byte - oder zumindest ein Byte mit dem Wert 0x47 - ist bei den "not SYNC " Zeilen immer 42 Bytes entfernt.

    Verwendest du die letzte Version 0.3.4pre3 von github ? Wenn ja, versuche zusätzlich noch diesen Modulparameter

    options wintv_usb2ci sync_urb_to_uframe=1 (default = 0 (off))
    und vielleicht auch noch

    options wintv_usb2ci urb_iso_asap=2 oder options wintv_usb2ci urb_iso_asap=0 (default = 1)

    LG Helmut

    Ich glaube nicht, dass der Raspberry zu langsam ist -ich habe aber selber keinen mit dem ich es testen könnte.

    Ist das noch das gleiche Modul wie im Post #168? Kannst du ein paar Zeilen mit den Sync-Fehlern posten - und deine aktuellen wintv_usb2ci Modul-Parameter.

    LG Helmut

    Das scheint das gleiche Problem wie hier zu sein. Du kannst ja auch einmal versuchen den Ringbuffer zu vergrößern.


    Apr 17 20:00:04 rpi4s vdr: [31015] tp 212551 (18/FF) read incomplete section - len = 4098, r = 4096 zeigt, das zumindest die ersten 3 Bytes der Section den Wert "0xFF" haben. Das scheinen die Füllbytes im letzten TS-Paket der Section-Daten zu sein.

    Das sollte aber mit dem von den Kernel DVB-Treibern verwendeten dvb_demux.c eigentlich nicht vorkommen.

    Eine Gemeimsamkeit wäre der Sundtek Treiber. Vielleicht wird hier ein eigener Sectionfilter verwendet.

    LG Helmut

    Ich hätte hier einen sehr experimentellen Patch, der versucht die Zuordnung von Device und verfügbarem Signal automatisch herauszufinden.

    Dazu werden nach dem Start von VDR bei jedem Programmwechsel zuerst die noch nicht verwendeten Devices auf eine Signal geprüft. Wenn es zu keinem Lock kommt, wird ein Retune ausgelöst und das Gleiche mit dem nächsten ungetesteten Device durchgeführt.


    vdr_rossi : In deinem Fall sollte der VDR damit spätestens nach dem 2. Retune ein passendes Frontend gefunden haben, dass dauert ungefähr 25 Sekunden. Nach einem weiteren Programmwechsel sollte klar sein welche der 2 Devices/4 Frontends DVB-T/C empfangen können - oder im Umkehrschluss eben nicht empfangen können.


    Diese Zuordnung ist unter idealen Bedingungen relativ einfach herauszufinden, schwieriger wird es bei schwankendes oder keinem Signal oder durch fehlerhafte Tuningparameter - daran kann dieser Patch dann möglicherweise scheitern.

    Du kannst ja einmal Testen, ob er für dich brauchbar ist.

    LG Helmut