Posts by TomJoad

Mit den beiden Zeilen in der epgsearch.conf kann es aber nicht sein, dass keine Einträge in der Logdatei landen

Damit in der logdatei was steht, muss der Loglevel raugesetzt werden, dh. in der conf.d-Datei fehlt eine zusätzliche Zeile mit --verbose=3 oder "-v 3" (siehe README)

Mit dem grep geht es auch. Wichtig war aber vor allem, dass der ln -s nur ausgeführt wird, wenn wirklich vdr-recordings gefunden werden.

Bei mir habe ich das udiskie-Skript wie folgt abgeändert, weil ich auch externe Medien anhänge, die Filme im mkv-Format beinhalten, sonst aber ziemlich voll mit Backups etc. sind.

(Aus irgendeinem Grund brauchte es auch noch die zusätzlichen Anführungsstriche beim -n)

        target="${videodir}/$(basename "${mount_path}")"
        # check if we got a vdr recording on the mountpoint
        if [ -n "$(find "$mount_path" -maxdepth 4 -xdev -name "*.rec" -print -quit 2>/dev/null)" ]
        then
            ln -s -T "$mount_path" "target" ||
                { logger -t "vdr recordings found" "mountpoint already exists, aborting"; exit; }
            vdr-dbus-send /Skin skin.QueueMessage string:"$mount_path mounted (with recordings)"
            svdrpsend updr
        else
            vdr-dbus-send /Skin skin.QueueMessage string:"$mount_path' mounted"
        fi

udp ist einfach unzuverlässig. Ich habe den Continuationcounter der ts-Pakete mitlaufen lassen und bei den Störungen fehlen komplette Pakete. Mit einem wesentlich grösserem Puffer scheint es zumindest seltener zu sein

Ich bin beim Neubauen in vdr 2.4.3 wieder drüber gestolpert, dass make -j4 plugins bei hbbtv Fehler wirft. Beim Erzeugen der libvdr-hbbtv.so ist der cmake von nng noch nicht durch und es fehlt die nng/build/libnng.a.

Ich denke es reicht in in der Makefile folgende Änderung

-$(SOFILE): $(OBJS)
+$(SOFILE): buildnng $(OBJS)

Damit wird zuerst mit -j4 nng gebaut und dann mit -j4 der Rest

Ohne es probiert zu haben: Mit neuem ffmpeg , wo libxml2 enabled sein muss, könnte ffmpeg -i xxx.mpd -codec copy output.ts gehen.

Quote from Zabrimus

Aber ohne den "-re" Parameter wird das Video so schnell gewandelt, wie es die Leitung hergibt. Und seltsamerweise wurde das dann auch genauso schnell im VDR abgespielt.

Ich habe mich unglücklich ausgedrückt, der Ffmpeg-Parameter -re ist nötig, aber die Variable realtime wurde uninitialisiert verwendet und dann -re nicht immer gesetzt. Da realtime immer true sein soll, könnte man den Code vereinfachen.

Anbei ein Vorschlag, nur komplette ts-Pakete zu senden. FixSkipped.patch

Ffmpeg schreibt zwar immer komplette Pakete in die Pipe, wegen der Grösse ist das Schreiben, soweit ich die Kernelinfos verstehe, nicht atomar. Deshalb, auch weil eine Namedpipe als Bytestream aufgefasst wird, werden auch Zwischenstände gelesen.

Zusätzlich besteht eine gewisse Chance, das realtime nicht auf true steht beim Aufbau der der Ffmpeg-Kommandozeile. Eigentlich kann man den Parameter ganz rausnehmen.

Browserlog:

[2020-06-19 22:33:23.048] [browser] [error] Send Video data, but size is not a multiple of 188: 31640

[2020-06-19 22:33:23.049] [browser] [error] Send Video data, but size is not a multiple of 188: 2388

syslog (vdr):

Jun 19 22:33:23 vdr[27085]: [27149] Got Video data, but size is not a multiple of 188: 31640

Jun 19 22:33:23 vdr[27085]: [27149] ERROR: skipped 132 bytes to sync on start of TS packet at device.c/PlayTs(1583)

Jun 19 22:33:23 vdr[27085]: [27149] ERROR: skipped 132 bytes to sync on start of TS packet at device.c/PlayTs(1583)

Jun 19 22:33:23 vdr[27085]: [27149] ERROR: skipped 132 bytes to sync on start of TS packet at device.c/PlayTs(1583)

Jun 19 22:33:23 vdr[27085]: [27149] ERROR: skipped 132 bytes to sync on start of TS packet at device.c/PlayTs(1583)

Jun 19 22:33:23 vdr[27085]: [27149] Got Video data, but size is not a multiple of 188: 2388

Ich bekomme beim Abspielen von Videos aus einer Mediathek immer wieder

ERROR: skipped xxx bytes to sync on start of TS packet (von device.c)

weil bei HbbtvVideoPlayer::readTsFrame() nicht immer ein Vielfaches von 188 Bytes ankommt.

Das führt zu Störungen im Bild.

Auf jeden Fall sind in 2.4 im VDR Patches reingekommen. Es hatte in epgsearch Probleme gegeben, weil die Dauer der Sendung im VDR falsch ermittelt wurde und nicht mit dem EPG übereinstimmte. Das sollte alles behoben sein.

Meine letzten Korrekturen sind im git. Wenn der Schedules-Lock nicht gehalten wird, während die Events ausgelesen werden, kann es zu Abstürzen kommen.

Ich werde, sobald ich dazu komme, eine Korrektur in dem Umfeld ins git einchecken. Wenn das Problem damit nicht behoben ist, wäre ein backtrace sehr nützlich.

Dazu gibt es Versionsnummern der Schnittstelle, aber z.Zt. komme ich nicht dazu.

MarkusE: Da war bei mir was durcheinandergeraten, ich hatte den fix_remote_search_timer.diff im Gedächtnis, aber das ist ein anderes Thema, das schaue ich mir noch an.

Mit GetById zu arbeiten, ist seit 2.4 immer die sicherere und bessere Methode, deshalb sollte dein Patch unabhängig von meinem drin bleiben.
Das Holen der Liste von remote geht natürlich nur über svdrpservice, da hast Du recht.

Man könnte natürlich auch eine neue aufgebohrte Version der Serviceschnittstelle machen, aber auch dann muss live angepasst werden.

Mir fällt sonst kein weiteres Plugin ein, das die Konfliktcheck-Schnittstelle nutzt?

Im epgsearch-Code werden im Conflictcheck-Menü die lokalen und die remoteTimer getrennt überprüft. Dazu wurde der svdrpservice-Befehl LSCC so angepasst, nur lokale Timer anzuzeigen. Das ist auch nötig, weil es sonst zu einer Ping-Pong-Schleife zwischen lokalem und remote Server führen würde.

Mir wäre es am liebsten, die ServiceSchnittstelle entsprechend anzupassen und nur lokale Timer in diese Liste zu schreiben. Dann müsste live selber, wenn remote Timer vorhanden sind, die ServiceSchnittstelle von dem passenden Server aufrufen.

Der Patch von MarkusE ist für epgsearch ohne Live nicht nötig und nicht sinnvoll.

Anhängender Patch mit der Bitte um Kommentare.

GTRDRIVER: Es müsste beim Hochfahren und alle 30 Minuten in der syslog die Meldung "search timer update started" kommen.

Warum löscht ihr nicht in solchen Fällen die timersdone? Die ist dazu da, um einmal automatisch programmierte Timer, die evtl. gezielt manuell gelöscht wurden, nicht sofort wieder automatisch aufzuziehen. Wenn Wiederholung vermeiden programmiert ist, wird auch die epgsearchdone herangezogen.

Sieht auch für mich vernünftig aus