Beiträge von kls

msv Über HITK wäre das nicht zu machen. Aber ich könnte mir einen neuen SVDRP-Befehl vorstellen, z.B. "AUDI", der, wenn ohne Parameter aufgerufen, die Audio-Spuren auflistet wie das Audio-Menü (evtl. noch mit einem eindeutigen Kennzeichen, ob es MP2 oder AC3 ist). Mit Parameter (Nummer) würde er die angegebene Spur auswählen.

Zitat von MegaV0lt

Was passiert, wenn es in einer Aufnahme oder LiveTV kein Dolby gibt? Bleibt dann Setup.CurrentDolby erhalten?

Das wird nur geändert, wenn im Audio-Menu gezielt eine andere Tonspur gewählt wird.

Zitat von MegaV0lt

Aber nur temporär. Muss dann jeden Tag bzw. nach jedem Start von VDR neu gemacht werden.

Das wird doch in Setup.CurrentDolby gespeichert, sollte also einen Neustart überstehen.

Zitat von MegaV0lt

Ich würde mir eine (zusätzliche) Einstellung wünschen

Wenn, dann würde ich höchstens UseDolbyDigital dahingehend ändern, dass es diese Funktion mit übernimmt.

<edit>

Wobei ich es dann aber so machen würde, dass im Falle von "yes" eine vorhandene Dolby-Spur (mit der bevorzugten Sprache, falls vorhanden) beim Umschalten des Kanals bzw. Start einer Wiedergabe auf jeden Fall benutzt wird, egal was der Benutzer vorher an Audio-Einstellungen gemacht hat.

</edit>

MegaV0lt Ja, das gilt generell, auch für Aufnahmen.

"Digitalton benutzen" steuert nur, ob diese Adio-Spuren überhaupt angezeigt werden:

  Use Dolby Digital = yes
                         Controls whether Dolby Digital tracks appear in the "Audio"
                         menu. This is useful if you don't have the equipment to
                         replay Dolby Digital audio.

Wenn vom Benutzer auf eine Dolby-Tonspur geschaltet wurde, wird ab dann Dolby bei Live und Wiedergabe bevorzugt, soweit es die gewählte(n) Sprache(n) zulassen. Wird explizit eine "analoge" Tonspur gewählt, gilt dies ab dann entsprechend:

* Selecting audio tracks
  ...
  Once a Dolby Digital track has been selected on any channel, further channel
  switches will first search for a Dolby Digital track of one of the preferred
  audio languages. If no such track can be found, a normal audio track will
  be selected. Note that this only works if the broadcasters use actual language
  codes in their PID data, not things like "dd" or "2ch".

VDR wurde für DVB geschrieben, alles andere ist "drangepappt". Wenn es also hilft, kann ich prevent_retune_and_obselete_satip.patch.txt gerne übernehmen, da das für DVB keinen Unterschied macht.

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

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?

Zitat von 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 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...

Das gab es schon mal:

2017-06-30: Version 2.3.8
...
- Whenever a change is made to the recordings in the video directory, the SVDRP command
  UPDR is now sent to all peer VDRs, so that they will update their recordings list.
  This is especially useful if one VDR mounts the video directory of an other one into
  a subdirectory.

2018-03-18: Version 2.3.9
...
- Removed sending the SVDRP command UPDR to peer VDRs whenever a change is made to the
  recordings in the video directory (which was introduced in version 2.3.8), because it
  triggered re-reading the video directory too fast.

wurde aber hier wieder entfernt.

Die Funktion BroadcastSVDRPCommand() gibt es aber noch, die könnte mrjoe direkt verwenden. Wobei sein Ansatz nur beim Start einer Aufnahme greift. Wenn dies aber parallel zu .update wirken soll, wäre wohl die TouchUpdate() Funktion der zentralere Ort.

Leider weiß ich nicht mehr, wie sich das mit dem "too fast" ausgewirkt hat. Das müsste mal jemand untersuchen, bevor wir das wieder einbauen.

Aus dem Bauch heraus hätte ich jetzt glatt gesagt, dass die .update-Datei automatisch angelegt wird. Aber in vdr.1 steht tatsächlich:

       .update
              If this file is present in the video directory, its last  modification
              time  will  be  used to trigger an update of the list of recordings in
              the "Recordings" menu.

Nach zwanzig Jahren kann man sowas schon mal vergessen ;-).

Ich würde sagen, sie sollte auf jeden Fall automatisch angelegt werden. Da dürfte kaum etwas dagegen sprechen.

Zitat von mrjoe

Verständnisfrage: wird durch das "touchen" durch den VDR Server beim Start der Aufnahme das Aufnahmeverzeichnis durch den Server ebenfalls komplett neu eingelesen?

Nein:

void cRecordings::TouchUpdate(void)
{
  bool needsUpdate = NeedsUpdate();
  TouchFile(UpdateFileName());
  if (!needsUpdate)
     lastUpdate = time(NULL); // make sure we don't trigger ourselves
}

Zitat von kfb77

Eigentlich will man ja erst dann die fertige Aufnahme auf einem anderen Client anschauen.

Man kann die Wiedergabe sofort nach Beginn der Aufnahme starten.

Zitat von mrjoe

vielleicht löse ich auch ein schon bereits gelöstes Problem.

Wenn eine Aufnahme startet wird .update getoucht, was bei allen Clients, die das gleiche Video-Directory benutzen, zum Update führt.

Zitat von wirbel

also assume 1

Richtig.

Zitat von 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.

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.

Zitat

1. Retune des Kanals

Warum werden die Kanaldaten dann überhaupt geändert?

Zitat von Zabrimus

2. Markieren obsoleter Kanäle

Kanäle werden obsolete, wenn SDT-Daten empfangen werden und sie darin längere Zeit nicht mehr vorkommen.

Offensichtlich senden also die IPTV-Kanäle SDT, listen aber die betroffenen Kanäle nicht auf. Ist das dann nicht eher ein Fehler in den gesendeten Daten?

Hier der aktuelle Stand meiner Überlegungen:

1. VDRVERSION und APIVERSION bleiben wie gehabt.
2. In der Freigabenotiz wird angegeben, ob Plugins neu übersetzt werden müssen (ist der Fall, wenn VDRVERSION und APIVERSION gleich sind).
3. Keine Unterscheidung mehr zwischen "stable" und "developer" Version (gerade vs. ungerade mittlere Zahl).
4. Die Versionsnummer wird einfach "hochgezählt" als wäre es eine normale Zahl (also 2.6.8, 2.6.9, 2.7.1, ...) und hat ausser der Unterscheidung, welche Version "neuer" ist, keine Bedeutung mehr.
5. Alle Bestandteile der Versionsnummern sind einstellig.
6. Bei Major und Minor wird die '0' nicht vergeben.
7. Im GIT können Zwischenstände eingespielt werden, die noch keine neue Versionsnummer haben. Der jeweils neueste davon hat das Label "master". Diese Stände sind "work in progress" und wer sie verwendet sollte immer auch alle Plugins neu übersetzen.
8. Sobald ein Stand als stabil angesehen wird erhält er eine neue VDRVERSION und ggf. APIVERSION, und wird im GIT mit "stable/latest" markiert. Für diesen Stand erfolgt dann eine Freigabemeldung.

Ich hoffe, damit allen gerecht zu werden ;-).

M-Reimer VDRVERSION und APIVERSION waren seit Version 2.1.1 (also seit über 10 Jahren) die meiste Zeit immer gleich. In dieser Zeit gab es 51 VDR-Versionen, davon waren nur bei 5 VDRVERSION und APIVERSION unterschiedlich. Zugegeben, in letzter Zeit habe ich sie immer gleich gesetzt, einfach um Diskussionen wie hier zu vermeiden (was aber anscheinend nicht gelingt). Es birgt aber auch eine gewisse Gefahr, sollte ich mal vergessen, APIVERSION hochzusetzen, wenn sich tatsächlich eine Schnittstelle ändert. Sowas bleibt u.U. lange unentdeckt, bevor es irgendwann zum Crash kommt.

Also gut, dann lasse ich halt APIVERSION wie gehabt und bemühe mich, es nur hochzusetzen, wenn es wirklich nötig ist.

Mein Script zum Erzeugen der Freigabenotiz werde ich so erweitern, dass es eine entsprechende Zeile erzeugt, je nachdem, ob VDRVERSION und APIVERSION gleich oder verschieden sind.