Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

    Uwe: Ich habe jetzt mein Unicable mit 2 VDRs getestet und komme auf ein ähnliches, oder sogar schlechteres Verhalten verglichen zu dir.

    Im VDR1 steckt eine PCIe DVBSky S950, am VDR2 war eine USB TBS-5520SE angeschlossen.

    Ich habe das Script von Sundtek auf beiden VDRs zwischeh 17:40 Uhr und 18:10 Uhr laufen lassen und zuvor die Systemzeit mit ntp abgeglichen.

    Auf dem VDR1 mit der PCIe Karte gabe es in dieser Zeit einen Tuning-Fehler, beim VDR2 mit dem USB Tuner aber zehn.

    Die Fehler sind auch nicht synchron.

    Für den USB Tuner habe ich der diseqc.conf allerdings ein W50 vor dem Runterschalten auf 13V, bei der PCIeKarte war es W30. Das könnte auch den Unterschied ausmachen. Die diseqc Kommandos funktionieren bei der PCI Karte auch mit W10, beim USB Adapter ist aber ein höherer Wert nötig.

    Der Patch selbst scheint das zu tun, was er soll, ich habe nichts Auffälliges bemerkt.

    Helmut


    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hallo Helmut,


    ich kann hier ähnliches berichten.
    Der Matrix VDR mit einer FFHD6400 erzeugt nicht so viele Diseqc-re-send Befehle, als der RaspberryPi mit USB-DVB-Tuner.

    Beide VDR’s waren heute knapp 6h mit EPG-Scan aktiv, Resultat siehe unten.


    Aber der Patch funktioniert sehr gut!

    Man bekommt kein Blackscreen, wenn es mal beim zappen zum „re-send Diseqc“ kommen sollte. :thumbup:


    Vielen Dank für den Patch an HelmutB und kls ! :)


    Code
    Apr 15 12:54:55 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command
Apr 15 13:55:46 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
Apr 15 14:49:03 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211971 for channel 41 (MTV) - re-sending SCR command
Apr 15 14:51:19 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211347 for channel 14 (ZDFinfo HD) - re-sending SCR command
Apr 15 16:12:15 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
Apr 15 16:12:50 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111493 for channel 1 (Das Erste HD) - re-sending SCR command
Apr 15 16:15:14 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112226 for channel 34 (Eurosport 1 Deutschland) - re-sending SCR command
Apr 15 16:21:51 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command
Apr 15 18:49:30 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112460 for channel 10 (SIXX) - re-sending SCR command
Apr 15 19:08:07 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112188 for channel 4 (RTL Television) - re-sending SCR command


    Code
    Apr 15 14:37:30 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command
Apr 15 16:59:22 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 211624 for channel 39 (CNN Int.) - re-sending SCR command
Apr 15 17:20:05 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command
Apr 15 19:03:55 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command

    3 Mal editiert, zuletzt von Uwe ()



    Der Tuner auf dem Matrix blockiert ja auch die Leitung bei Dir.

    Ich weiß nicht wie es bei den anderen Tunern mit den Timings aussieht, eventuell haben diese auch Sleeps in den Treibern wenn sie die Spannungsversorgung hochdrehen (eventuell um sicherzugehen dass dann wirklich 18 oder 13V an der Leitung anliegen).

    Das Re-Tune ist ja nur der "After"-Effekt wo die Leitung bereits belegt war.

    Ich habe die Ausführungszeiten der Diseqc Befehle mit dem Patch im Anhang geprüft.

    Ich habe die Logs jetzt nicht vor mir, aber wenn ich mich richtig erinnere dauerte das Senden ab "V" (+18V) bis einschliesslich "v" (+13V) bei der TBS-5520(USB) 115ms-116ms und bei der DvbSky-S950(PCIe) 126ms-128ms. Das Ganze mit einem W50 vor "v"


    Es wird dabei nur die Zeit bis zur Rückkehr des Letzten ioctl-Aufrufs gemessen, ob die Hardware es dann auch schon umgesetzt hat, kann man damit natürlich nicht feststellen.

    Helmut

    Eigentlich ist das Thema für mich mit dem Patch-Nr7 erledigt.
    Die re-send Befehle die jetzt noch auftreten, sind scheinbar normal und treten bei einem Unicable-Setup wie meinem (mehrere Empfänger an einem Sat-Kabel zum LNB) öfter mal auf.

    Bisher habe ich keine Probleme mehr festgestellt, werde es aber weiter beobachten und hier melden.


    Vielen Dank für eure Hilfe Sundtek , kls , HelmutB :)

    HelmutB Irgendwie scheint das mit den Zeiten nicht zu stimmen ;)

    Edit: hier fehlt scheinbar noch ein ExecTimer.Set ... Ist vorhanden....

    Code
    Apr 19 11:59:03 raspberrypi vdr: [2549] >>> ExecuteDiseqc(0/0): 1851779112 ms (18V->13V)
Apr 19 12:00:01 raspberrypi vdr: [2551] >>> ExecuteDiseqc(1/0): 1832904744 ms (18V->13V)
Apr 19 12:00:37 raspberrypi vdr: [2551] >>> ExecuteDiseqc(1/0): 1832904744 ms (18V->13V)


    Aber ein Cast auf int ... int(ExecTimer.Elapsed()) hilft.... :)
    Hier nun meine Ergebnisse. Auf dem raspi habe ich etwas größere Wartezeiten in der diseqc.conf eingestellt.

    7 Mal editiert, zuletzt von Uwe ()

    Einen kleinen Fehler im Patch hätte ich schon gefunden: statt "%ld ms" sollte es "%lu ms" für den uint64_t Rückgabewert von Elapsed() sein (auf einem 64-Bit System, "%llu" bei 32-Bit).

    Für sowohl 32 als auch 64 Bit sollte "lld" mit (unsigned long long) typecast gehen.

    dsyslog(">>> %s(%d/%d): %llu ms (18V->13V)", __func__,adapter, frontend, (unsigned long long)ExecTimer.Elapsed())


    Zu den Zeiten - die sind etwas länger als bei mir

    Code
    Apr 16 15:56:58 gentoo64vdr vdr[8461]: [8487] >>> ExecuteDiseqc(1/1): 118 ms (18V->13V) // USB
Apr 16 15:56:58 gentoo64vdr vdr[8461]: [8482] >>> ExecuteDiseqc(0/0): 128 ms (18V->13V) // PCIe
Apr 16 15:57:19 gentoo64vdr vdr[8461]: [8487] >>> ExecuteDiseqc(1/1): 117 ms (18V->13V) // USB
Apr 16 15:57:19 gentoo64vdr vdr[8461]: [8482] >>> ExecuteDiseqc(0/0): 128 ms (18V->13V) // PCIe

    und die diseqc.conf war:

    Code
    S19.2E  11700 V  9750  t V W10 S0 [70 00 00 00] W50 v
S19.2E  99999 V 10600  t V W10 S1 [70 00 00 00] W50 v
S19.2E  11700 H  9750  t V W10 S2 [70 00 00 00] W50 v
S19.2E  99999 H 10600  t V W10 S3 [70 00 00 00] W50 v

    Da sich aber diese Kollisionen oder sonstigen Einflüsse nicht komplett verhindern lassen, sind ein paar ms mehr oder weniger auch schon egal.

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Zur Info: Mit den Wartezeiten W10/W50 auf beiden Systemen bekomme ich diese Zeiten:

    Code
    Apr 19 18:03:39 matrix-vdr vdr: [6911] >>> ExecuteDiseqc(0/0): 140 ms (18V->13V)
Apr 19 18:06:23 matrix-vdr vdr: [6915] >>> ExecuteDiseqc(1/0): 139 ms (18V->13V)
Apr 19 18:06:54 matrix-vdr vdr: [6915] >>> ExecuteDiseqc(1/0): 138 ms (18V->13V)
Apr 19 18:07:14 matrix-vdr vdr: [6915] >>> ExecuteDiseqc(1/0): 141 ms (18V->13V)
Apr 19 18:07:28 matrix-vdr vdr: [6915] >>> ExecuteDiseqc(1/0): 138 ms (18V->13V)
Apr 19 18:07:32 matrix-vdr vdr: [6915] >>> ExecuteDiseqc(1/0): 137 ms (18V->13V)


    Code
    Apr 19 18:11:58 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 150 ms (18V->13V)
Apr 19 18:12:34 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 150 ms (18V->13V)
Apr 19 18:13:10 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 149 ms (18V->13V)
Apr 19 18:13:46 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 150 ms (18V->13V)
Apr 19 18:14:22 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 150 ms (18V->13V)
Apr 19 18:14:58 raspberrypi vdr: [6188] >>> ExecuteDiseqc(1/0): 150 ms (18V->13V)
    Zitat von HelmutB

    Einen kleinen Fehler im Patch hätte ich schon gefunden: statt "%ld ms" sollte es "%lu ms" für den uint64_t Rückgabewert von Elapsed() sein (auf einem 64-Bit System, "%llu" bei 32-Bit).

    Für sowohl 32 als auch 64 Bit sollte "lld" mit (unsigned long long) typecast gehen.

    dsyslog(">>> %s(%d/%d): %llu ms (18V->13V)", __func__,adapter, frontend, (unsigned long long)ExecTimer.Elapsed())

    Schau dir mal inttypes.h an


    %"PRIu64"

    Zur Info, ich habe seit gestern auf dem raspi die Option: Kanäle aktualisieren auf „neue Transponder hinzufügen“ umgestellt. Damit gibt es keine Probleme. Mit der dvbsky hatte ich hier Probleme, dass der Empfänger irgendwann nix mehr empfing ohne reboot... mit dem sundtek Tuner keine Probleme... :)

    Code
    pi@raspberrypi:~ $ tail -n1000 -f /var/log/syslog | egrep 're-send'
Apr 19 18:33:37 raspberrypi vdr: [6188] frontend 1/0 did not switch to transponder 212246 for channel 1947 (RMC SPORT 2) - re-sending SCR command
Apr 19 19:10:48 raspberrypi vdr: [6188] frontend 1/0 did not switch to transponder 112633 for channel 1491 (health.tv) - re-sending SCR command
^C
pi@raspberrypi:~ $ date
So 19. Apr 21:28:32 CEST 2020

    Ich habe ausgehend von vdr-2.4.1-test-check-scr-03-notimer7.diff das Ganze etwas verallgemeinert, indem cSdtFilter die Funktionen TransponderVerified() und TransponderWrong() bekommen hat. Diese liefern true wenn der Transponder positiv als "richtig" oder "falsch" erkannt wurde. In cDvbTuner::Action() gibt es keine spezielle "SCR"-Behandlung mehr, denn wenn der Transponder der Falsche ist muss eigentlich immer neu getunt werden, egal was für ein System es ist (sollte also z.B. auch wirken, wenn bei einer drehbaren Antenne der falsche Satellit im Fokus ist). Bisher verwende ich nur TransponderWrong(), die TransponderVerified() brauche ich vielleicht noch im Zusammenhang mit den entfernten Zeilen in nit.c. Das muss ich aber erst noch abklären, ob es dadurch zu einer Regression kommen kann.


    HelmutB Du hattest da zuletzt einige Abfragen bzgl. ScrLastTp, ScrLastNid und ScrLastTid eingebaut. Meinst du, dass die in dieser oder ähnlicher Form (dann in cSdtFilter::Process() unter 'if (transponderVerificationState == tvsUnknown) {') noch nötig sind?


    Uwe Kannst du bitte diesen Stand testen?

    Zitat von kls

    Du hattest da zuletzt einige Abfragen bzgl. ScrLastTp, ScrLastNid und ScrLastTid eingebaut. Meinst du, dass die in dieser oder ähnlicher Form (dann in cSdtFilter::Process() unter 'if (transponderVerificationState == tvsUnknown) {') noch nötig sind?

    Die habe ich deshalb eingebaut, weil immer wieder Programme (Transportstreams) abgeschalten und/oder auf andere Transponder verschoben werden. Dadurch kann die channels.conf irgendwann Programmeinträge mit für den Transponder zwar passenden Tuningparametern aber inzwischen ungültiger NID/TID enthalten, die dann immer wieder ein Retune ergeben würden da NID/TID nie zur SDT passen können.


    Ein Retune sollte es aber nur geben wenn eine Änderung von NID/TID erwartet wird, diese aber nach SetFrontend() immer noch die alten Werte haben. Für den Vergleich braucht es die LastTNid/LastTid (LastTp ist wahrscheinlich nicht notwendig, wenn man es ganz genau nimmt eher ein LastSource). Deshalb auch die Prüfung in DvbTuner::Action() und nicht in sdt.c.


    Ich habe den Patch inzwischen auch um einen Sdt-Trigger() erweitert, wo erst nach positiver Transponderprüfung der sdt Filter getriggert wird um dann in den sdt.serviceloop einzusteigen. Ich kann dir diese Variante mailen, ich muss ihn aber vorher von meinem etwas gepatchten VDR noch für den original VDR-2.4.1 umschreiben.

    LG Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hallo Klaus,


    Danke für den weiteren Patch, der seit Dienstag auf beiden System zuverlässig hier funktioniert. :)

    Ich teste weiter und melde mich, wenn etwas auffällt.

    Code
    Apr 23 09:28:57 raspberrypi vdr: [524] frontend 1/0 is not receiving transponder 111302 for channel 11 (ServusTV HD Deutschland) - retuning
Apr 23 10:12:45 raspberrypi vdr: [524] frontend 1/0 is not receiving transponder 212168 for channel 1922 (CINE+ PREMIER) - retuning
Apr 23 10:49:21 raspberrypi vdr: [524] frontend 1/0 is not receiving transponder 112545 for channel 3 (SAT.1) - retuning
    Code
    Apr 22 12:42:49 matrix-vdr vdr: [804] frontend 1/0 is not receiving transponder 111362 for channel 2 (ZDF HD) - retuning
Apr 22 20:24:28 matrix-vdr vdr: [805] frontend 1/0 is not receiving transponder 111362 for channel 2 (ZDF HD) - retuning

    Hallo kls,

    bei mir hat der Patch von HelmutB besser funktioniert. Besonders bei Tagesschau24 HD kommt die Wiedergabe beim retuning aus den tritt (ruckeln):


    Das war möglicherweise ein Gedankenfehler und dieser Patch hilft:

    Nach einem SetStatus(true) ist transponderState nur dann "tsUnknown" wenn sich Source() oder Transponder() gegenüber dem letzten SetStatus(true) geändert haben, anderenfalls ist er unverändert - wie auch bei einem SetStatus(false).

    Dieser Patch ist wäre zusätzlich und nach dem "vdr-2.4.1-test-check-scr-06.diff" einzuspielen.

    Helmut


    PS: wenn man im fix1 bei SetStatus() das "else if" in "if" ändert, wäre es noch klarer.

    Ist dadurch schlechter geworden:


    Murry : Kannst du im fix1 patch in dieser Zeile das "else" wegnehmen:

    + else if (Source() != lastSource || Transponder() != lastTransponder)

    sollte dann so aussehen:

    + if (Source() != lastSource || Transponder() != lastTransponder)

    Helmut

    HelmutB passed unfortunately away on July 21, 2022 ... RIP 🖤

    Hallo HelmutB,


    das wars nicht:

    Auffällig ist das nach einmailgen retune er auf jedem Sender dies tut. Erst ein vdr neustart behebt dies.


    Gruß

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden