Fichier d'historique vers DB

Bugs / Demandes de fonctionnalités New Features
1

BUG / NOUVELLE FONCTIONNALITÉ

Version 2.5.7 64-bit

Windows 10 x64

Il serait bien qu’il existe une option pour stocker les informations d’historique dans une base de données sqlite ou équivalent. Mon fichier d’historique devient assez volumineux et, au bout d’environ six mois, MCEBuddy cesse de détecter les fichiers lors des analyses ; je dois alors les ajouter manuellement ou, récemment, j’utilise un script PowerShell qui les ajoute via la CLI.

Dès que je vide le fichier d’historique, l’analyse se termine en quelques secondes et, si je n’ai pas nettoyé certains dossiers ad hoc, ils sont ajoutés aux tâches de conversion. Je pense que c’est lié au nombre d’enregistrements dans le fichier d’historique.

Si l’option d’enregistrer dans une base de données existe, la recherche sera plus rapide et, en cas de corruption ou de recréation, les enregistrements précédents pourraient éventuellement être réintégrés à partir d’une sauvegarde.

2

Il suffit de vider l’historique régulièrement. Y a-t-il une raison pour laquelle vous devez savoir si MCEBuddy a traité un fichier plutôt qu’une autre application ? Si le fichier est un doublon (c’est-à-dire déjà présent), MCEBuddy ne le traitera pas. Le fait qu’il ne soit pas dans l’historique n’a pas d’importance.

Ou est-ce que je passe à côté de quelque chose ?

3

L’historique est utilisé dans un emplacement de surveillance pour ne pas retraiter un fichier déjà converté, sauf si l’option « Re-monitor recorded videos » est activée.

image
image659×437 19.6 KB

Il y a des moments où j’ai besoin de retraiter un fichier, donc je coche cette option. Si vous êtes dans la même situation @Nick_Skoy, vous pouvez essayer de cocher cette option pour voir si elle détecte les nouveaux fichiers. Il semble qu’elle devrait contourner l’analyse de l’historique.

4

Désolé pour le retard de ma réponse. J’étais en déplacement ce week-end et occupé hier.

J’ai un HDHomeRun Prime et j’utilise NextPVR. Ce n’est pas si décalé de ce que je comprends. J’ai configuré certaines émissions pour enregistrer « Tous les épisodes » et d’autres pour « Seulement les nouveaux épisodes ». Je pense donc que le problème vient des séries classées dans la catégorie « Tous les épisodes ». Je vais prendre « Friends » comme exemple. Elle passe sur plusieurs chaînes et, quand j’enregistre, peu importe que l’épisode soit enregistré plusieurs fois. Ou, d’après ce que je comprends, il ne réenregistrera le même épisode que s’il est diffusé sur une autre chaîne.

Je l’ai observé quand je ré-ajoute les épisodes à MCEBuddy via la ligne de commande ou par glisser-déposer. Il récupère les données, reconnaît qu’il a déjà converti le fichier grâce à l’historique, supprime le fichier et passe à l’élément suivant dans la file. Il fait donc le ménage. Quand mon fichier d’historique devient trop volumineux ou corrompu (même si je peux toujours le lire sans problème et que je ne vois pas de corruption visible), la recherche ne trouve pas les enregistrements et MCEBuddy reste inactif. Les fichiers s’accumulent alors et il m’est arrivé d’avoir plus de 100 émissions/films à convertir, mais rien ne se fait. J’ajoute les fichiers à MCEBuddy via la ligne de commande ou en les glissant manuellement, et au fil du temps ils s’ajoutent à la file, sont traités — convertis ou détectés comme déjà convertis — et le fichier source est supprimé du dossier d’enregistrement.

J’espère que c’est à peu près clair et que ça aide…

5

Il semble qu’il puisse y avoir 2 types de « suppression des doublons/historique ».

  1. Le fichier figure dans la base de données/log d’historique (c’est-à-dire qu’il porte le même nom qu’un enregistrement précédent du DVR) et est donc ignoré avant tout traitement supplémentaire.
  2. Le fichier est d’abord partiellement traité jusqu’à déterminer quel serait son nom de fichier de destination ; si ce fichier existe déjà, il sera ignoré avant (ou peut-être après, je ne suis pas certain de ce détail – j’espère que MCEBuddy vérifie qu’il peut ignorer le fichier avant de faire le travail de traitement).

Le scénario n° 1 dépend du fait que le fichier d’entrée porte le même nom qu’un enregistrement antérieur (selon les règles d’historique).

Le scénario n° 2 dépend du fait que le fichier de sortie porte le même nom qu’un enregistrement déjà traité (selon les règles de nommage des fichiers de destination).

Par exemple, quand je configure mon HDHR pour « tout enregistrer » (c’est-à-dire toute la série – il n’est pas (encore ?) assez malin pour utiliser le flag « nouvel épisode » dans les données du guide, contrairement à mon Tivo), le tuner insère l’heure de début HHMM et l’heure de fin HHMM dans le nom du fichier, ainsi que la chaîne d’enregistrement. Chaque diffusion se retrouve donc dans un fichier séparé, que les données du guide indiquent ou non des métadonnées d’épisode.

Presque toutes les émissions des sous-canaux PBS (CreateTV, je vous vois) n’ont ni information d’épisode ni identifiants d’émission ; elles apparaissent donc toujours comme des épisodes isolés dans mon dossier « Specials » au lieu d’être classées dans une série TV (avec saisons et épisodes), qu’il s’agisse d’épisodes différents ou de rediffusions du même épisode à des horaires différents.

C’est parce que, pour mes profils de travail « Specials », je dois inclure l’« heure de début » dans le nom de fichier de sortie afin de pouvoir distinguer les épisodes potentiellement multiples et les doublons. Sinon, s’ils aboutissent tous à un nom de sortie « Showname-SaisonÉpisode-DateEnregistrement », le premier traité bloquera les suivants, qui seront retirés de la file d’attente comme fichiers de sortie en double selon le scénario n° 2.

Pour les séries TV, je ne veux pas que cela arrive ; je souhaite un traitement « premier enregistrement gagne ». Mon nom de fichier de sortie pour les séries (c’est-à-dire quand il y a un numéro d’épisode dans les métadonnées) n’inclut donc que la « date de première diffusion » et non la « date d’enregistrement ».

Les événements sportifs sont généralement en direct et ne concernent que la date de l’événement ; leur règle de renommage inclut donc la « RecordDate » et non la « FirstAirDate », car certaines données de guide indiquent comme « FirstAirDate » la date de début de l’émission sportive complète (par exemple Monday Night Football – pas que ce soit exact, je l’utilise juste comme exemple reconnaissable). De plus, dans une série de matchs, le numéro du match n’est pas toujours renseigné comme « numéro d’épisode » : le match 3 de la « World Series 2022 » peut apparaître sous le titre « World Series 2022 Game 3 » (rendant l’enregistrement de toute la série chaotique dans le DVR) ou comme épisode 3 de la série « World Series 2022 ». Inclure systématiquement la « RecordDate » dans le nom du fichier pour les émissions sportives résout ce problème, quelles que soient les données du guide ou les métadonnées.

J’espère que cela aide à comprendre ce que MCEBuddy fait dans votre cas. Vous pouvez aussi chercher sur les forums mes messages décrivant mes règles de renommage qui envoient chaque type d’émission (TV, Film, Sport, et « Autre/tout le reste ») vers des dossiers différents, avec des règles de nommage compatibles avec mon installation Plex.

Les émissions problématiques sont celles de PBS qui atterrissent dans mon dossier Specials ; je dois les dédoublonner manuellement, les déplacer vers la série TV appropriée et les renommer avec la bonne saison et le bon épisode. Je garde généralement l’heure d’enregistrement en suffixe, puis je dédoublonne en ne conservant que la meilleure version traitée par MCEBuddy.

6

Pouvez-vous me joindre ou m’envoyer en MP votre fichier d’historique (ou me dire combien de lignes/entrées il contient) ? Nous l’avons testé avec jusqu’à 100 000 entrées sans problème. Nous avons également refondu le moteur de base de données INI dans la dernière version bêta 2.5.8 pour permettre des bases de données encore plus volumineuses.