[ANNOUNCE] VDR Version 2.6.9 freigegeben

kls · July 15, 2024 at 11:32 AM

VDR version 2.6.9 is now available at the official VDR GIT archive

git://git.tvdr.de

You can also get the latest stable version with

git clone --branch stable/2.6 git://git.tvdr.de/vdr.git

or as a tar archive with

http://git.tvdr.de/?p=vdr.git;a=s…s/2.6.9;sf=tbz2

The changes since version 2.6.8:

- Fixed a crash in strreplace() for multiple replacements with strings of different

lengths (reported by Markus Ehrnsperger).

- Fixed handling of cSkinDisplayMenu::GetTextAreaFont() (reported by Matthias Senzel).

- Fixed a timeout in cDvbDevice while tuning after the frontend has been reopened.

- Fixed setting the editable width in the LCARS skin (reported by Matthias Senzel).

- Fixed restarting the EPG scan and keeping the frequency of calls to

Device->SetPowerSaveIfUnused() low.

- Added the lines from 'Fixed a timeout in cDvbDevice while tuning after the frontend

has been reopened' to cDvbTuner::ProvidesFrontend() (suggested by Markus Ehrnsperger).

Homepage: http://www.tvdr.de

Facebook: https://www.facebook.com/VideoDiskRecorder

Have fun!

Klaus

jsffm · July 19, 2024 at 3:17 PM

Ich habe jetzt 2.6.9 auf meinem Prod-System installiert und wundere mich über folgende Meldung trotz Bonding aktiv!

Code

Jul 19 15:08:59 vdr3-2 vdr[2867]: [2867] pause EPG scan
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 2/0
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 3/0
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 4/0
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 5/0
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 7/0
Jul 19 15:09:08 vdr3-2 vdr[2867]: [2867] closing frontend 8/0

2-5 ist DVB-S2 mit Bonding

wirbel · July 19, 2024 at 4:45 PM

Danke für das Zusammenfassen aller aktuellen Änderungen.

Kleine Frage von mir..,

was würde aktuell bool cDevice::SetChannelDevice(const cChannel *Channel, bool LiveView) mit (Channel == nullptr) für Plugins bedeuten?

1. does never ever happen

2. undefined behaviour

3. noop = no action

4. equals cDevice::SetPowerSaveMode(true)

und welcher return value wäre expected?

Ich frage deswegen, weil ich einen fork des satip Plugins möglichst kompatibel zu den aktuellen power-save Änderungen bereitstellen möchte. Mit 2.6.8 funktionierte das gut, aber der EPG Scan wurde nur 1x aktiviert und schlief danach 4ever..

kls · July 19, 2024 at 5:24 PM

wirbel SetChannelDevice() wurde nur in der ursprünglichen Version des closeFrontendUnused-Patches mit NULL aufgerufen und hatte somit eine inkompatibe Änderung gemacht, die ich eigentlich sofort hätte ablehnen sollen. Inzwischen habe ich das über SetPowerSaveMode() realisiert, womit alles rückwärtskompatibel ist. Du kannst also davon ausgehen, dass die Funktion (wie bisher) nie mit NULL aufgerufen wird. Es gab (und gibt) auch keine offizielle Version, die das tut bzw. getan hat.

wirbel · July 19, 2024 at 6:18 PM

Super, also assume 1. + fallback to 4 mit return false.

_{Könnte man das auf eine Referenz umbauen? Wäre mehr C++ style.}

kls · July 19, 2024 at 8:34 PM

Quote from wirbel

also assume 1

Richtig.

Quote from wirbel

+ fallback to 4 mit return false

Das ist so nicht richtig, denn es war bisher (und ist auch jetzt nicht) definiert, dass ein Aufruf mit NULL einem irgendwie gearteten Power-Save-Modus gleichgesetzt ist. Auf NULL abzufragen und dann false zurückzugeben ist sicher nicht verkehrt, aber einen Power-Save-Modus auszulösen entspricht zumindest nicht der Semantik dieser Funktion.

SHofmann · July 20, 2024 at 4:44 PM

Hallo Klaus,

wieder einmal vielen Dank für das VDR-Update. Noch eine Frage zu den TS-Fehlern: Wenn man eine Aufzeichnung schneidet, kann es ja durchaus passieren, dass die TS-Fehler im "abgeschnittenen" Teil lagen und in der geschnittenen Aufzeichnung nicht mehr enthalten sind. Trotzdem bleibt in den Infos die ursprüngliche Fehlerzahl stehen.

Siehst du eine Chance, die Zahl der TS-Fehler beim Schneiden neu zu ermitteln, sodass die geschnittene Aufzeichnung diesbezüglich "korrekt" ist?

Danke & Grüße

Stefan

kls · July 25, 2024 at 12:02 PM

SHofmann Das mit den Fehlern ist eh nur eine grobe Schätzung, um für Pattern-Timer entscheiden zu können, ob eine bestimmte Sendung bei einer eventuellen Wiederholung nochmal aufgenommen werden soll. Diese in der geschnittenen Fassung erneut zu ermitteln halte ich für unnötig aufwendig. Ich glaube, es hat schon mal jemand einen Patch gemacht, der die Fehler geloggt hat, weiß aber nicht, ob er diese Info dann beim Schneiden mit berücksichtigt hat. Wenn ich mich recht erinnere, habe ich den Patch damals nicht angenommen, weil er (wie leider so oft) weit über das Ziel hinausgeschossen ist und viel zu viel gemacht hat. Wenn überhaupt, könnte ich mir das so vorstellen:

- Fehler werden in der (neuen) Datei "errors" im Aufnahmeverzeichnis geloggt.

- Gespeichert wird der Frame-Index, bei dem der/die Fehler aufgetreten ist/sind (bei mehreren Fehlern innerhalb eines Frames nur ein Eintrag "<index> <number of errors in this frame>").

- Zu klären wäre, wie festgestellt werden soll, wann ein Fehler wieder "vorbei" ist, denn es müsste auch gespeichert werden, ab wann es wieder fehlerfrei ist ("<index> 0").

- Dieses Log könnte beim Schneiden verwendet werden.

Ob es den Aufwand wert ist, ist allerdings fraglich...

SHofmann · July 25, 2024 at 3:08 PM

Hallo Klaus,

erst einmal vielen Dank für deine Überlegungen. Wenn sich die Fehler nicht beim Verarbeiten (Schneiden) des Datenstroms "en passant" ermitteln lassen, scheint dein Ansatz wohl am zielführendsten zu sein.

Noch ein paar ergänzende Gedanken: Schnittmarken können ja laut Handbuch ja immer nur an I-Frames gesetzt werden. Insofern bräuchte man also nur per I-Frame vermerken, wie viele Fehler in ihm selbst und den folgenden B-Frames aufgetreten sind. TS-Fehler müssten für den gedachten Zweck auch nur auf Granularität solcher Schnittblöcke protokolliert bzw. beim Schneiden akkumuliert werden. Blöcke ohne TS-Fehler bräuchte man dabei nicht protokollieren, wenn man fehlende Blöcke als fehlerfrei betrachtet.

Landet ein protokollierter Block (I-Frame mit seinen B-Frames) in der geschnittenen Aufzeichnung, wird die Zahl seiner TS-Fehler aufaddiert. Entfällt ein protokollierter Block, sind seine TS-Fehler ohne Belang. Ein nicht protokollierter Block ist per definitionem fehlerfrei.

Textbasiert kann eine Datei mit den TS-Fehlern per Block recht groß werden. Insofern wäre ein binäres Dateiformat wie bei index mit Tupeln von (struct tIndexTs block, uint64_t tsErrors) wohl günstiger. [uint64_t deshalb, damit man die Datei mit od -tx8 schön ausgeben lassen kann.]

Schick wäre das alles schon. Bezüglich der Frage, ob sich der Aufwand für dich lohnt, hoffe ich auf eine wohlwollende Einschätzung...

Viele Grüße

Stefan

MarkusE · July 25, 2024 at 4:16 PM

Quote from shofmann

Noch ein paar ergänzende Gedanken: Schnittmarken können ja laut Handbuch ja immer nur an I-Frames gesetzt werden. Insofern bräuchte man also nur per I-Frame vermerken, wie viele Fehler in ihm selbst und den folgenden B-Frames aufgetreten sind. TS-Fehler müssten für den gedachten Zweck auch nur auf Granularität solcher Schnittblöcke protokolliert bzw. beim Schneiden akkumuliert werden. Blöcke ohne TS-Fehler bräuchte man dabei nicht protokollieren, wenn man fehlende Blöcke als fehlerfrei betrachtet.
Landet ein protokollierter Block (I-Frame mit seinen B-Frames) in der geschnittenen Aufzeichnung, wird die Zahl seiner TS-Fehler aufaddiert. Entfällt ein protokollierter Block, sind seine TS-Fehler ohne Belang. Ein nicht protokollierter Block ist per definitionem fehlerfrei.
Textbasiert kann eine Datei mit den TS-Fehlern per Block recht groß werden. Insofern wäre ein binäres Dateiformat wie bei index mit Tupeln von (struct tIndexTs block, uint64_t tsErrors) wohl günstiger. [uint64_t deshalb, damit man die Datei mit od -tx8 schön ausgeben lassen kann.]

Hört sich kompliziert (und fehleranfällig) an.

Lass doch nach dem Schneiden ein tool über die geschnittene Aufnahme laufen, das die TS Fehler ermittelt.

SHofmann · July 25, 2024 at 4:20 PM

Genau das mache ich derzeit, was aber ein wenig lästig ist und im Nachgang immer viel Handarbeit erfordert.

kls · July 25, 2024 at 4:40 PM

Quote from shofmann

Textbasiert kann eine Datei mit den TS-Fehlern per Block recht groß werden. Insofern wäre ein binäres Dateiformat wie bei index mit Tupeln von (struct tIndexTs block, uint64_t tsErrors) wohl günstiger.

Hmmm, im struct tIndexTs sind noch 7 Bit frei ("reserved for future use"). Da könnte man direkt im Index fehlerhafte Frames markieren. Das entspräche dann zwar nicht der Anzahl der Fehler (die kann ja bei vielen fehlerhaften TS-Paketen sehr hoch sein), aber ich denke mal, es reicht aus, zu wissen, ob ein Frame fehlerfrei ist oder nicht. Die Info stünde dann beim Schneiden direkt zur Verfügung. Da überleg ich mir mal was...

SHofmann · July 25, 2024 at 4:52 PM

Das hatte ich gesehen und auch schon in diese Richtung überlegt. Allerdings wäre dann die Semantik von "O" nach dem Schneiden (fehlerhafte Frames) eine andere als vor dem Schneiden (fehlerhafte Rahmenbits, wie ich vermute)...

Danke jedenfalls

Stefan

kls · July 25, 2024 at 5:04 PM

SHofmann In vdr.5 heißt es dazu lediglich:

Code

The 'O' tag contains the number of errors that occurred during recording.  If it is zero, the recording can be safely considered error free. The higher the value, the more damaged the recording is.  If this is an edited recording, the number of errors is that of the original recording.

Es geht dabei lediglich um eine grobe Abschätzung. Der "fehlerfreie" Fall wird sicher erkannt, und ansonsten gibt die Zahl nur ein Maß für die Fehlerhaftigkeit an. Den letzten Satz würde ich dann halt entsprechend ändern, etwa "If this is an edited recording, this is the number of frames with errors". Vielleicht würde es ja auch Sinn machen, die Zahl generell auf "defekte Frames" umzustellen, auch bei der original Aufnahme?

SHofmann · July 25, 2024 at 5:11 PM

Quote from kls

Vielleicht würde es ja auch Sinn machen, die Zahl generell auf "defekte Frames" umzustellen, auch bei der original Aufnahme?

Ich fände das eh sinnvoller.

Jetzt fehlten nur noch ein paar Tasten, mit denen man Blöcke fehlerhafter Frames (das erste bzw. letzte I-Frame eines Blocks) gezielt ansteuern könnte – so wie Sprungmarken. Dann könnte man vor dem Schneiden noch schnell checken, ob sich die Fehler im Vor- bzw. Nachlauf oder in einer Werbeunterbrechung befinden.

Ja ja, ich weiß schon: die Sache mit dem kleinen Finger und dem ganzen Kerl...

Viele Grüße

Stefan

kls · September 6, 2024 at 10:54 AM

Quote from kls

Da überleg ich mir mal was...

cTsChecker und cFrameChecker werden von recorder.c nach remux.c verlagert und in cFrameDetector benutzt. Dadurch ist eine Zuordnung von Fehlern zu bestimmten Frames möglich, was bisher nicht der Fall war, da cTsChecker beim Empfangen der TS-Pakete geprüft hat, und cFrameChecker erst beim Verarbeiten.
Fehlerhafte Frames werden im Index mit dem Flag "error" markiert. Dabei ist es egal, ob in dem Frame nur 1 Fehler ist oder viele.
~~Fehlende Frames werden im Index wie normale Frames eingetragen und mit "missing" und "error" markiert.~~
Falls Frames komplett fehlen, wird im nächsten gefundenen Frame das "missing"-Flag gesetzt.
In der Fortschrittsanzeige werden "error" und "missing" Frames gekennzeichnet.
~~Bei der Wiedergabe werden "missing" Frames übersprungen.~~
Bei der Regenerierung des Index einer bestehenden Aufnahme werden die gleichen Prüfungen gemacht wie bei der Aufnahme selber, so dass Fehler entsprechend erkannt und im Index eingetragen werden können. Einzig "missing" Frames am Beginn der Aufnahme können auf diese Weise nicht erkannt werden.
Beim Schneiden einer Aufnahme werden eventuelle "error" und "missing" Flags in den neuen Index übernommen und die Gesamtzahl der Fehler entsprechend angepasst.

Am Punkt 1. bin ich momentan dran. Alles weitere sind bisher nur Überlegungen, die ich hiermit zur Diskussion stelle.

kfb77 · September 6, 2024 at 11:23 AM

Quote from kls

3. Fehlende Frames werden im Index wie normale Frames eingetragen und mit "missing" und "error" markiert.

Hat das Auswirkung auf die Timestamps der Marken ?

Beispiel:

Bisher sind im Index nur vorhandene Frames. Wenn ich auf Frame 100 springen will, und dann neu die 10 fehlende Frames davor in Index drin sind, muss ich ja auf Frame 110 springen ?

Wäre es nicht sinnvoller gleich PTS in den Index aufzunehmen um damit eine eindeutige Identifizierungen des Frames zu schaffen, statt nur die Zeilennummer des Index, wo immer eine Unschärfe bleibt, welches Frame berücksichtigt wurde und welches nicht ?

jrie · September 6, 2024 at 11:31 AM

Quote from kls

Bei der Wiedergabe werden "missing" Frames übersprungen.

Und was passiert mit dem Audio?

Quote from kfb77

Wäre es nicht sinnvoller gleich PTS in den Index aufzunehmen um damit eine eindeutige Identifizierungen des Frames zu schaffen

Finde ich eine gute Idee.

kls · September 6, 2024 at 12:04 PM

Quote from kfb77

Hat das Auswirkung auf die Timestamps der Marken ?

Ja, denn die fehlenden Frames werden dann ja mitgezählt. Aber für den Benutzer macht das keinen Unterschied, denn wenn er die Marken im VDR setzt kommen sie ja genau dort hin, wo sie sollen. Der Offset fehlender Frames wird immer der des letzten zuvor gefundenen Frames sein. Ich sehe das als einzige Möglichkeit, in der Fortschrittsanzeige fehlende Frames auch anzuzeigen. Alternativ könnte natürlich auch nur beim nächsten gefundenen Frame das "missing" Flag gesetzt werden, was dann soviel bedeuten würde wie "vor diesem Frame fehlen ein oder mehrere Frames". Die Fortschrittsanzeige könnte dann aber halt nur eine "kleine" Markierung zeigen, auch wenn in Wirklichkeit viele Frames fehlen. Welche Lösung wir nehmen ist mir egal.

Quote from jrie

Und was passiert mit dem Audio?

Der Sprung würde genauso geschehen wie wenn man mit der grünen bzw. gelben Taste eine Minute überspringt (hier dann halt eben so weit, wie Frames fehlen). Als "Frames" zählen eh nur die Video-Frames, Audio ist darin enthalten und erfährt keine Sonderbehandlung.

Quote from kfb77

Wäre es nicht sinnvoller gleich PTS in den Index aufzunehmen

Wozu sollte das gut sein?

Ausserdem wäre das eine absolut inkompatible Änderung im Format der Index-Datei, was ich ganz bestimmt nicht machen werde.

kfb77 · September 6, 2024 at 12:25 PM

Quote from kls

denn wenn er die Marken im VDR setzt kommen sie ja genau dort hin, wo sie sollen

Und wenn die Marken nicht von Hand vom VDR kommen ? Z.B. von markad. Woher soll markad wissen, ob der Index mit oder ohne fehlende Frames geschrieben wurde ?

Quote from kls

Ich sehe das als einzige Möglichkeit, in der Fortschrittsanzeige fehlende Frames auch anzuzeigen.

Warum nicht den Fortschritt auf Basis aktuelle PTS - Start PTS anzeigen ?

Quote from kls

Wozu sollte das gut sein?

Um die Unschärfe weg zu bekommen. Das ist eindeutiger Wert, das in jedem Packet drin steht. Bei "Anzahl Pakete" zählen gibt es mehrere Möglichkeiten, welche mitzählen und welche nicht. Genau die Diskussion früheren wir ja gerade.

Participate now!