Verlaufsdatei in DB

BUG / NEUES FEATURE

Version 2.5.7 64-bit

Windows 10 x64

Es wäre schön, wenn es eine Option gäbe, die Verlaufsinformationen in einer SQLite-DB oder etwas Ähnlichem zu speichern. Meine Verlaufsdatei wird ziemlich groß, und nach etwa 6 Monaten hört MCEBuddy auf, Dateien beim Scannen zu erkennen, und ich muss sie manuell hinzufügen oder – seit neuestem – ein PowerShell-Skript verwenden, das sie über die CLI hinzufügt.

Sobald ich die Verlaufsdatei lösche, ist der Scan in Sekundenschnelle erledigt, und falls ich einige der Ad-hoc-Ordner nicht geleert habe, werden sie den Konvertierungsaufgaben hinzugefügt. Ich vermute, dass es an der Menge der Datensätze in der Verlaufsdatei liegt.

Wenn die Option besteht, in einer DB zu speichern, dürfte die Suche schneller sein, und im Falle einer Beschädigung oder eines Neuanlegens könnten die vorherigen Datensätze möglicherweise aus einem Backup wieder eingefügt werden.

Lösche einfach regelmäßig den Verlauf. Gibt es einen Grund, warum du wissen musst, ob MCEBuddy eine Datei verarbeitet hat und nicht etwas anderes? Wenn die Datei ein Duplikat ist (d. h. bereits vorhanden), wird MCEBuddy sie nicht verarbeiten. Ob sie im Verlauf steht oder nicht, spielt keine Rolle.

Oder habe ich etwas übersehen?

Der Verlauf wird innerhalb eines Überwachungsorts verwendet, um eine bereits konvertierte Datei nicht erneut zu verarbeiten, es sei denn, die Option „Aufgezeichnete Videos erneut überwachen“ ist aktiviert.

Es gibt Situationen, in denen ich eine Datei erneut verarbeiten muss, daher aktiviere ich diese Option. Wenn du dich in derselben Situation befindest, @Nick_Skoy, kannst du versuchen, diese Option zu aktivieren, um zu sehen, ob sie die neuen Dateien erkennt. Es scheint, als würde sie das Auslesen des Verlaufs umgehen.

Sorry für die späte Antwort. Ich war am Wochenende außer Haus und gestern sehr beschäftigt.

Ich habe einen HDHomeRun Prime und benutze NextPVR. Soweit ich weiß, ist das nicht weit weg von der Norm. Ich habe einige Sendungen so eingestellt, dass sie „Alle Episoden“ aufnehmen, und andere, die nur „Nur neue Episoden“ aufnehmen. Ich glaube also, dass das Problem bei den Sendungen liegt, die in der Kategorie „Alle Episoden“ sind. Ich nehme einfach mal „Friends“ als Beispiel. Es läuft auf mehreren Kanälen, und es ist mir egal, ob die Sendung mehrmals aufgenommen wird. Oder wie ich es verstehe, wird nur dieselbe Episode aufgenommen, wenn sie auf einem anderen Kanal läuft.

Ich habe beobachtet, wie ich die Episoden über die Befehlszeile wieder zu MCEBuddy hinzufüge oder per Drag-and-Drop. Es liest die Daten, erkennt anhand des Verlaufs, dass die Datei bereits konvertiert wurde, löscht die Datei und geht zum nächsten Element in der Warteschlange über. Die Aufräumarbeiten funktionieren also auch. Wenn meine Verlaufsdatei zu groß oder beschädigt wird (obwohl ich die Datei noch gut lesen kann und keine sichtbare Beschädigung feststelle), findet die Suche die aufgenommenen Sendungen nicht, und MCEBuddy bleibt untätig. Diese Dateien häufen sich dann an, und es gab Zeiten, in denen 100+ Sendungen/Filme konvertiert werden mussten, was aber nicht geschah. Ich füge die Dateien über die Befehlszeile oder per Drag-and-Drop manuell zu MCEBuddy hinzu, und mit der Zeit werden sie in die Warteschlange aufgenommen und verarbeitet – sei es durch Konvertierung oder durch Erkennen, dass sie bereits konvertiert wurden, und die Quelldatei wird aus dem Aufnahmeordner gelöscht.

Ich hoffe, das ergibt einigermaßen Sinn und hilft weiter …

Es klingt, als gäbe es zwei Arten der „Duplikats-/Verlaufsentfernung“.

  1. Die Datei befindet sich in der History-DB/dem History-Log (d. h. gleicher Name vom aufnehmenden DVR) und wird daher vor der weiteren Verarbeitung übersprungen.
  2. Die Datei wird zunächst soweit vorverarbeitet, dass der Ziel-Dateiname ermittelt wird; ist diese Datei schon vorhanden, wird sie vor der weiteren Verarbeitung übersprungen (oder vielleicht danach – das Detail ist mir nicht sicher; hoffentlich erkennt MCEBuddy, dass es die Datei vor der eigentlichen Verarbeitung überspringen kann).

Szenario #1 hängt davon ab, dass die Eingangs-Datei denselben Namen wie eine frühere Aufnahme hat (gemäß den History-Regeln).

Szenario #2 hängt davon ab, dass die Ausgangs-Datei denselben Namen wie eine bereits verarbeitete Aufnahme hat (gemäß den Zielbenennungsregeln).

Wenn ich z. B. meinen HDHR auf „alles aufnehmen“ stelle (die ganze Serie – er ist (noch?) nicht so schlau wie mein TiVo, das die „neu“-Markierung im EPG berücksichtigt), fügt der Tuner die Startzeit (HHMM) und Endzeit (HHMM) sowie den aufnehmenden Sender in den Dateinamen ein. Jede Ausstrahlung landet so in einer eigenen Datei, unabhängig davon, ob die EPG-Daten Episoden-Informationen oder andere Metadaten enthalten.

Fast alle Sendungen auf PBS-Subkanälen (CreateTV, ich schaue dich an) haben keine Episoden-Informationen oder Show-IDs, daher landen sie bei mir immer als Einzelstücke im „Specials“-Zielordner, statt in eine TV-Serie (mit Staffeln und Episoden) einsortiert zu werden – egal ob es sich um verschiedene Episoden oder um Wiederholungen derselben Episode zu einem anderen Zeitpunkt handelt.

Für meine „Specials“-Jobprofile muss ich daher die Startzeit im Ausgabedateinamen berücksichtigen, damit ich erkennen kann, dass es potenziell mehrere Episoden und Duplikate gibt. Würden alle Ausgabedateien nur „Showname-S-E-Aufnahmedatum“ lauten, würde die erste verarbeitete Datei alle anderen blockieren und diese als doppelte Ausgabedatei gemäß Szenario #2 aus der Job-Queue entfernt werden.

Bei TV-Serien will ich das nicht und bevorzuge eine „erste Aufnahme gewinnt“-Logik. Daher enthält mein Ausgabedateiname für Serien (die eine Episodennummer in den Metadaten haben) nur das „FirstAirDate“, nicht das „RecordDate“.

Sport-Events sind in der Regel live und nur für das jeweilige Veranstaltungsdatum relevant; daher verwendet die Umbenennungsregel das „RecordDate“, nicht das „FirstAirDate“, weil manche EPG-Daten als „FirstAirDate“ das Datum der gesamten Sport-Sendung eintragen (z. B. Monday Night Football – nur als Beispiel). Außerdem wird in einer Spielserie nicht immer die Spiel-Nummer als Episodennummer hinterlegt: Game 3 der „World Series 2022“ erscheint z. B. als „World Series 2022 Game 3“ im Sendungstitel (was die Aufnahme der ganzen Serie im DVR zur Katastrophe macht) oder als Episode 3 innerhalb der Show „World Series 2022“. Das „RecordDate“ im Dateinamen löst dieses Problem, egal was die EPG-/Metadaten sagen.

Ich hoffe, das hilft dir zu verstehen, was MCEBuddy in deinem Fall machen könnte. Im Forum findest du auch meine Posts mit den Umbenennungsregeln, die jede Art von Sendung (TV, Film, Sport, „Sonstiges“) an unterschiedliche Orte schicken und unterschiedliche Ausgabedateinamen verwenden, die mit meinem Plex-Setup harmoniieren.

Die problematischen Sendungen sind die PBS-Produktionen, die im „Specials“-Ordner landen und die ich manuell von Duplikaten befreien sowie ins richtige TV-Show-Verzeichnis verschieben und in Staffel/Episode umbenennen muss. Dabei behalte ich meist die Aufnahmezeit als Suffix und behalte die beste, von MCEBuddy erzeugte Version.

Können Sie mir Ihre Verlaufsdatei per PN zusenden oder mir mitteilen, wie viele Zeilen/Einträge sie enthält? Wir haben sie mit bis zu 100.000 Einträgen ohne Probleme getestet. Wir haben außerdem die INI-Datenbank-Engine in der neuesten Beta-Version 2.5.8 überarbeitet, um noch größere Datenbanken zu ermöglichen.