Posts by Dr. Seltsam

    Ich habe die vorgeschlagene Änderung in nit.c mal in vdr-2.6.7 übernommen. Und siehe da, jetzt überschreibt vdr die korrekte stream-id 0 nicht mehr mit 1, wenn Kanäle aktualisieren in den DVB-Einstellungen aktiviert ist. :applaus

    Allerdings berichtigt er eine falsch eingetragene 1 bei nächster Kanalwahl auch nicht auf 0. Löscht man den Kanal aber aus der Kanalliste, wird er korrekt mit 0 neu erkannt und ans Ende der Kanalliste angefügt. (Kanäle aktualisieren steht bei mir auf 'neue Kanäle hinzufügen')

    Sieht also so aus, als wenn das tatsächlich ein Tippfehler ist. Wenn kls das auch so sieht, könnte das ja in die Version vdr-2.6.8 einfließen.

    Moin jojo61,

    kannst Du Dir bitte mal diese Stelle in CodecVideoOpen ansehen?

    Müsste der PIP-Check bei hevc und mpeg2 nicht vom Grundsatz her gleich sein? Bei mpeg2 wird auf ungleich use_pip_mpeg2 geprüft, bei hevc hingegen ob use_pip true ist.

    Die von mir gepostete channels.conf war evtl. schon durchprobiert und dadurch auf P1 für ARD geändert. Meine t2scan-Version ist:

    Code
    fhg@ubuntu-tv:~$ t2scan -V
    t2scan -V
    20200628

    Ich habe eben noch einen Scan gemacht, der sieht gut aus, alle Kanäle haben P0, hier ein Ausschnitt:

    Seltsamerweise ist der Parameterstring kürzer als in der letzten geposteten Version, die ich aber definitiv mit der selben Version erzeugt habe. Liegt das evtl. daran, daß ich den heutigen Scan nicht als root gemacht habe?

    In dem t2scan-Thread wurde ja mehrfach berichtet, dass bei jedem neuen Scan die Anzahl gefundener Sender und ich glaube auch ihre Parameter unterschiedlich waren. Dieses Multistream-Zeug ist saukompliziert. Ich glaube HelmutB war der einzige, der da richtig durchgeblickt hat. Zu schade, dass er nicht mehr unter uns weilt.

    VDR-Version unter 16.04, Kernal 4.8.0-58-generic ist von fnu die Version 2.4.1-0fnu0-xenial.

    Ich frage mich, ob fnu in diesen vdr vielleicht einen Patch eingebaut hat, der zu einer funktionierenden multistream-Behandlung führte. HelmutB hatte damals allerlei Patches erstellt, von denen fnu vielleicht vorab eine Lösung integriert hatte, die so dann später nicht von kls übernommen wurde.

    Frank, kannst Du bitte mal nachschauen, ob Du die Sourcen für dieses vdr-Paket noch findest? Bei launchpad bin ich nicht fündig geworden, das älteste dort war ein 2.4.8

    Der vdr-Patch aus #88 hilft nicht.

    Das device liefert als capability u.a. CAN_MULTISTREAM. Aber offenbar kann vdr damit nicht richtig umgehen.

    Eine stream_id -1 kann man übrigens nicht setzen. vdr akzeptiert nur 0-255

    Ich habe bei mir jetzt das gleiche Problem! Einziger Unterschied ist, dass t2scan (frisch aus dem git kompiliert) die stream_id richtig mit 0 erkennt.

    • channels.conf wurde mit neu kompiliertem t2scan erzeugt und weist durchgehend P0 aus
    • vdr wird gestartet und auf einen ARD-Kanal gewechselt.
    • changing transponder data of channel 1 (Das Erste HD) from 490000:B8D0G19128P0Q1S1T16X0Y0:T to 490000:B8D0G19128P1Q1S1T16X0Y0:T
    • retuning due to modification of channel 1 (Das Erste HD)
    • das Bild ist weg
    • Kanäle aktualisieren deaktiviert
    • per OSD stream-id für den Kanal auf 0 geändert
    • Kanal neu angewählt - Bild kommt

    Deine t2scan-Version hatte P1 erkannt, meine richtigerweise P0. Jetzt wäre die Frage: welche t2scan-Version hast Du verwandt?

    Meine sagt

    Code
    root@CoreELECTanixTX3 ~ # t2scan -V
    t2scan -V 
    20201027

    Da gab es eine Änderung in scan.c am 03.05.2020 mit der Beschreibung "fix handling of non-multistream capable T2 hardware"

    Bei fnu finde ich die Version nicht mehr mehr, aber in den vdr-Sourcen der 2.4.1 von kls ist der Codeabschnitt aus #68 unverändert so wie heute. Beim Treiber ist dann nun schwieriger zu rekonstruieren, da man dazu den von Dir ausgecheckten git-Stand kennen müsste. Am si2168.c kann es eher nicht liegen, den hattest Du ja schon gepostet. NO_STREAM_ID_FILTER ist in include/uapi/linux/dvb//frontend.h definiert, und das ist auch im tbsdtv-git schon seit mindestens 8 Jahren mit

    Quote

    #define NO_STREAM_ID_FILTER (~0U)

    definiert, was laut SHF ja für -1 steht.

    Ich also verstehe weiterhin nicht, warum es unter 16.04 nicht auch zu einem fälschlichen Überschreiben der stream_id mit 1 kommt. Wenn ich mich richtig erinnere, hatten wir auch schon abgeklärt, dass sowohl unter 16.04 als auch 22.04 die gleiche Firmware-Version B 4.0.25 von dvb-demod-si2168-b40-01.fw verwandt wird.

    Es würde jetzt doch sehr helfen, wenn Du angeben könntest, welche vdr-Version unter 16.04. (Ubuntu Xenial) funktioniert. fnu hat ja diverse repositories, aber in keinem finde ich Pakete für Xenial.

    Und welche Treiber wurden jetzt unter 16.04. für die Tests mit WinTV dualHD benutzt? Die vom Kernel (welcher? oder ein TBS-Paket? Falls letzteres: Sind das proprietäre Treiber von der TBS Webseite oder Open Source Treiber von https://github.com/tbsdtv/media_build? Ich vermute ersteres, denn laut https://linuxtv.org/wiki/index.php/TBS_driver_installation läuft die 6205 nur mit Closed Source Treibern. Das muss aber nicht aktuell sein.

    Wie auch immer, wenn man das Problem jetzt mit dem Treiberentwickler des si2168 aufnehmen will, wäre es besser, ein komplettes Treiberpaket inklusive der Header zu haben. Ist das eines von hier?

    TBS Download Center-Update the Latest Window & Linux Driver

    Also hast Du jetzt die P0 in der channels.conf und ein ungewolltes Überschreiben durch vdr mittels Deaktivierung der Kanalaktualisierung verhindert?

    Oder bist Du SHF's Vorschlag gefolgt und hast -1 als Wert für P eingetragen (ich weiss gar nicht, ob das überhaupt geht)


    Das löst das eigentliche Problem aber ja nicht. Warum finden t2scan und vdr anhand der Transponderinfo den Parameter P1, wenn damit kein Empfang möglich ist? Wenn die ARD ihre Transponderdaten falsch deklariert, müssten ja auch andere Empfänger Probleme haben. Ich vermute eher, dass hier entweder vdr oder der Treiber die Hardware nicht richtig ansprechen und die plp autodetection deshalb nicht richtig funktioniert.


    Hattest Du den Test unter 16.04 eigentlich mit der gleichen vdr-Version gemacht? Nicht dass das Abändern der Stream-ID erst durch Änderungen in einer späteren vdr-Version entstanden ist.


    Wenn Du den TBS-Treiber neu kompilierst, kannst Du ja mal diesen Vorschlag des Treiberentwicklers zu einem ähnlichen Problem ausprobieren:

    Auf meinem chroot-System habe ich den Aufruf der smp-affinity.sh schon ewig in der runvdr drin. Bei VDR*Elec hatte ich im Vergleich immer das Gefühl, dass da Kaugummi im Getriebe ist. Es kam bei deaktiviertem FastSwitch sinifikant häufiger als in chroot zu Fehlern beim Umschalten (Bild lief für einen Moment zu schnell). Du erinnerst Dich vielleicht an die Diskussion mit den Compiler-Optionen. Ich könnte mir vorstellen, dass die smp affinity hier den Unterschied macht. Exakt belegen kann ich es nicht, zumal ich auch ständig Umbauexperimente im softhdodroid-Plugin mache. Aber ich denke es schadet auf keinen Fall.

    Vielleicht mögen ja noch ein paar mehr Leute Deinen Umsetzungsvorschlag testen und Feedback geben.

    Hi jojo61,

    ich habe mir nochmal das Phänomen des bei manchen Kanalwechseln (nur mit deaktiviertem FastSwitch) kurz zu schnell laufenden Bildes angesehen. Es liegt an void AudioEnqueue in audio.c:


    Der Zähler für die Anzahl Durchläufe zur Ermittlung von Radio ist mit 75 zu klein. Ein guter Umschaltvorgang sieht z.B. so aus:

    Die zweite Bedingung (Audio PTS kleiner als Video PTS) wird hier 34 mal erkannt, macht bei 24ms pro Durchgang plausibe 816 ms A/V-Differenz. Was ich aber nicht verstehe: Nachdem der Ton also nicht mehr zurückhinkt, wird dann aber mit der letzten Bedingung noch 11 mal = 264 ms das Gegenteil erkannt - nun ist das Video plötzlich vor dem Ton. Mir ist nicht klar, wie es dazu kommt. Liegt das daran, dass das Audio immer komplett verworfen wird, so dass es zu neuen Abweichungen kommt, wenn die A/V-Differenz nicht durch 24 teilbar ist?


    Wie auch immer, ich konnte debuggen, dass es beim Umschalten immer mal wieder Situationen gibt, wo die erste Bedingung (Clear all audio until video is available) deutlich über 75 hochläuft, ehe doch noch Videodaten kommen. Das passiert immer dann, wenn es irgendwo kurz 'hakt' - sehr gut reproduzierbar ohne radio-Plugin durch Umschalten auf einen Radiokanal und sofort zurück auf einen TV-Kanal. In einigen Fällen habe ich dann bis knapp 150 geloggt.


    Ich habe den Wert jetzt von 75 auf 150 erhöht - seitdem gab es bei keinem Umschaltvorgang mehr zu schnell laufende Bilder. Nachteil ist, dass es auf Radiosendern dann fast 4 s dauert, bis Ton kommt. Aber das kann man ja mit dem radio-Plugin umgehen. Wen das auf PlayPes konfiguriert ist, sendet es die benötigten Videodaten.


    Du hattest irgendwann mal geschrieben, dass Du immer etwas zuviel Audio in den ringbuffer geben musst, damit der nicht leer läuft und es einen alsa underrun gibt. Welche Codestelle ist das?

    Zabrimus:

    Mir fiel da noch was zur Performance ein. CoreElec hat in /usr/lib/systemd/system einen Dienst smp-affinity.service:

    Mit systemd stehe ich auf Kriegsfuß. Kann es sein, dass der Dienst erst startet, wenn Kodi gestartet wird? Dann stünden diese Optimierungen ja nicht bereit, solange man direkt in vdr bootet:


    das ist wirklich aus dem funktionierenden Treiber, der unter 16.04 läuft?


    Der Code ist an der möglicherweise entscheidenden Stelle genauso wie aktuell

    Ich verliere leider den Durchblick. Vielleicht kann SHF nochmal erläutern, wie sein Vorschlag

    zu verstehen ist.

    schalte mal in Einstellungen - DVB - Kanäle aktualisieren auf 'nein'. Kannst Du den P-Parameter danach über das OSD auf 0 ändern? Wenn nicht, muss vdr gestoppt und die channels.conf anschließend händisch editiert werden. Danach sollte keine automatische Aktualisierung und auch kein Überschreiben mehr erfolgen. Ich hoffe, dass der der Parameter dann so nicht nur beim Treiber ankommt, sondern auch tatsächlich gesetzt wird.


    Aus dem TBS-Treiberpaket interessiert mich nur die Datei si2168.c - sie sollte in /drivers/media/dvb-frontends liegen.

    Und die Gegenprobe mit 16.04 und P1?


    Welchen Kernel verwendest Du unter Ubuntu 16.04.? Stammen die dvb-Treiber darin aus einem TBS-Paket? Hast Du dazu noch die Sourcen? Ich würde mir da gerne mal eine Stelle anschauen, ob die da schon so wie im aktuellen si2168-Treiber war.


    Es gab da 2015 ein möglicherweise ähnliches Problem mit dem Vorschlag des Treiberentwicklers, testweise mit einem Hack die stream_id fix auf 0 zu setzen. Anscheinend kam danach aber nichts mehr vom User.


    Ich bin dann noch auf einen Post von HelmutB (R.I.P.) gestoßen, der eine Modifikation des vdr-Codes in dvbdevice.c vorschlägt. Das passt auch für vdr-2.6.7 noch.


    Kannst Du vdr selbst kompilieren? in dvbdevice.c wird aus

    Code
         if (frontendType == SYS_DVBT2) {
            // DVB-T2
            SETCMD(DTV_INNER_FEC, dtp.CoderateH());
            if (DvbApiVersion >= 0x0508) {
               SETCMD(DTV_STREAM_ID, dtp.StreamId());
               }
            else if (DvbApiVersion >= 0x0503)
               SETCMD(DTV_DVBT2_PLP_ID_LEGACY, dtp.StreamId());
            }

    dann

    Code
    Das Erste HD;ARD:538000:B8D0G19128M2P1Q1S1T16X0Y0

    Hier wird jetzt explizit P1 vorgegeben. Und diese channels.conf wurde auch beim Test mit dem alten Treiber verwandt, bei dem laut Analyse von SHF stream_id 0 gesetzt wurde? Das wäre dann für mich nur erklärlich, wenn der Treiber die stream_id damals gar nicht berücksichtigt hat und pauschal 0 gesetzt hat.


    Was ist, wenn Du den Teil der channels.conf auf

    Code
    Das Erste HD;ARD:538000:B8D0G19128M2P0Q1S1T16X0Y0

    änderst? Funktioniert es dann mit dem neuen Treiber?

    Ich würde mal versuchen die stream_id auf 0 zu setzen. Das müsste eigentlich im Channels-Menü vom VDR gehen. (Ich kann das leider nicht probieren, ich habe hier nur SAT.)

    Und dann mal schauen, ob das auch im Logfile ankommt.


    Irgendwie ist das Ganze mit der stream_id sowieso etwas merkwürdig, zumal sie in dem channels.conf gar nicht gesetzt wurde.

    Aber vielleicht weiß da einer der DVB-T-Experten mehr?

    Hiernach

    @kls: Stream ID neuer Parameter in channels.conf?
    ist die stream_id in der channels.conf der P-Parameter, und der ist in der in #23 geposteten channels.conf für Das Erste bereits 0:

    Code
    B8C12G19128M64S1T16P0

    Allerdings war das nach meiner Erinnerung eine veraltete channels.conf, die da gepostet wurde, in der die Frequenzumstellung des NDR-Paketes noch nicht berücksichtigt war.

    Gehen wir mal davon aus, dass der P-Parameter richtig auf 0 konfiguriert ist und vdr das auch so an den Treiber gibt. Dann scheint der aktuelle Treiber das aus irgendwelchen Gründen zu ignorieren und stattdessen die 1 zu setzen. Geschieht das denn auch beim ZDF oder nur bei der ARD?

    Gegenprobe: Was ist, wenn beim alten Treiber der P-Parameter in der channels.conf bewusst auf 1 geändert wird? Geht der Sender da dann auch nicht mehr?


    Anbei hänge ich auch das auf "vdr:" gefilterte syslog mit einigen Umschaltversuchen an.

    das hilft nicht weiter. Wir wollen ja die Kernel-Meldungen des Treibers sehen.Lieber einmal ein komplettes Syslog vom fehlgeschlagenen Umschaltvorgang. Eventuell können wird das dann später mit einem anderen grep-Begriff eingrenzen.