Ohne es probiert zu haben: Mit neuem ffmpeg , wo libxml2 enabled sein muss, könnte ffmpeg -i xxx.mpd -codec copy output.ts gehen.
Beiträge von TomJoad
-
-
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
-
Wenn keine negativen Rückmeldungen mehr kommen, werde ich den Patch von Fourty2 ins git übernehmen, da er im Gegensatz zu den bisherigen Vorschlägen auch mit älten clib-Versionen kompiliert.
-
Tut mir leid wegen der Verwirrung, aber erase(it) und erase(*it) sollten im Ergebnis das gleiche liefern. Ich kann aber nichts nachstellen, weil bei bionic mit g++ 8.2.0 alles funktioniert, auch mit dem Patch von seahawk wird richtig inkementiert.
-
Der uralte Code macht einen erase auf einen Value, nicht auf eine Iteratorposition. Der Rückgabewert ist in dem Fall laut C++-Referenz ein size_type und nicht die nächste Iteratorposition. (Nicht, dass ich den Code wirklich verstehen würde, aber mit erase(*it) hat es bisher immer funktioniert.
-
Bei mir mit bionic und gcc-8 habe ich normales Verhalten bei conflict checks
-
Die Änderung von seahawk kann nicht funktionieren, weil da kein erase(it) steht, sondern erase(*it)
-
klak: Sicher kann man den automatischen Konfliktcheck deaktivieren im epgsearch-Setup.
Dank an Stefan für den Backtrace. Dieser Codeteil ist zur 2.4 nicht angefasst worden. Mich würde interessen, wie zum Absturzzeitpunkt die Werte von it, *it und checkTime sind. Und vielleicht vor einer Reproduktion das epgsearch-Logging aktivieren