J’utilise le profil HDHomeRun Unprocessed pour convertir des fichiers WTV de Windows en fichiers MPG afin de les lire dans le visionneur HDHomeRun (HDHRV). Il semble que des données soient manquantes dans le fichier MPG :
Le champ Description de la balise WTV n’est pas transféré dans le fichier MPG converti. Je peux voir la balise description dans le fichier WTV, mais pas dans le fichier mpg converti. Grâce à Jriver, je peux copier la description WTV et la coller dans la description du MPG (j’ai donc une solution de contournement), mais cela ralentit mon processus de conversion. Après cette étape manuelle, je vois la description dans HDHRV et JRiver.
Lorsque je visionne un fichier converti dans HDHRV, la barre de progression en bas du lecteur n’indique aucune progression pendant la lecture, même si je saute en avant avec la flèche droite ou la flèche haute. Quand je quitte le programme en cours de visionnage, la liste des enregistrements (triée par chaîne, nom d’épisode, épisode et colonne « enregistré ») n’affiche aucune progression ; je dois donc manuellement avancer pour retrouver l’endroit où j’avais quitté le visionneur. Je vois bien les changements de barre de progression dans d’autres lecteurs (JRiver, PowerDVD et Windows Media Player), mais pas dans HDHRV. Je suis certain que SiliconDust dira que c’est un problème MCEBuddy et j’espère que MCEBuddy pourra proposer un correctif pour que je ne sois pas pris entre deux feux…
Y a-t-il des paramètres que j’aurais manqués ? Voici mes profils :
Pouvez-vous joindre votre journal de conversion qui montrera ce qui se passe. HDHR utilise un format de métadonnées propriétaire. Nous avons travaillé avec eux pour en incorporer autant que possible dans MCEBuddy. Cependant, certaines fonctionnalités du format sont uniques à HDHR, donc si vous utilisez un enregistrement HDHR au départ, toutes les fonctionnalités de métadonnées sont préservées. Cependant, lors de la conversion d’un format non-HDHR vers un format HDHR, une partie de ces métadonnées est simulée puisqu’elle n’existe pas et est assignée par HDHR lors de l’enregistrement. Cependant, la description ne fait pas partie de celles-ci.
Votre journal de conversion apportera plus de précisions à ce sujet.
Le champ de description n’est apparemment pas utilisé par le visionneur HDHR. D’autres enregistrements convertis s’affichaient correctement même sans balise de description. J’expérimenterai davantage, mais l’absence de la balise description n’est pas le problème principal. Désolé pour la fausse alerte à ce sujet.
Malheureusement, cela ne règle toujours pas le problème de la progression de l’enregistrement qui n’est pas affichée pendant la lecture (ni conservée à la sortie). Je suppose qu’il existe une sorte de « marqueur » dans le format d’enregistrement propriétaire HDHR qui n’est pas simulé dans le fichier converti. Les fichiers de log seraient-ils utiles pour ce problème ? Devrais-je fermer ce ticket comme résolu et ouvrir un autre fil de discussion pour la progression de l’enregistrement ?
Essayez-vous de convertir un fichier pendant son enregistrement ? Vous convertissez WTV en MPG, donc j’essaie de comprendre à quoi vous faites exactement référence.
Non… Désolé pour la confusion. J’essaie de décrire la barre de progression pendant la lecture d’un fichier converti dans le visionneur HDHR.
La première capture d’écran montre le visionneur HDHR avec la barre de progression (entourée en orange) pour un épisode de Smash que j’ai enregistré en 2012 sur WMC et converti en mpg avec MCEBuddy. Notez qu’aucune progression n’est indiquée alors que la lecture est à mi-chemin.
La capture suivante montre la barre de progression d’un épisode de Signed, Sealed, Delivered enregistré l’année dernière via HDHR. Notez que la barre de progression entourée en orange contient une portion verte indiquant la progression de la lecture (environ 25 %).
Si vous quittez la lecture de « Signed, Sealed, Delivered » à ce moment-là pour revenir à l’écran des épisodes, vous voyez que la progression de la lecture a été conservée (entourée en orange). Si vous relancez la lecture (en cliquant sur l’épisode), le visionneur saute à 25 % du programme pour reprendre là où vous vous étiez arrêté.
Cependant, l’écran des épisodes pour l’enregistrement de Smash ci-dessus (le fichier converti) ne montre aucune progression alors que la lecture s’est arrêtée à mi-chemin. Cela signifie que lorsque vous relancez le programme, vous recommencez toujours au début et devez avancer rapidement pour retrouver l’endroit où vous vous étiez arrêté.
J’espère que c’est plus clair. Je suis souvent interrompu et j’aimerais pouvoir reprendre la lecture si possible.
Pouvez-vous télécharger un échantillon du fichier converti WTV en MPG ET une copie du fichier contenant le marqueur de lecture sur notre serveur pour analyse.
@Goose J’ai déterminé que les clés de métadonnées SeriesID et ProgramID du dictionnaire ont une signification dans certains scénarios et ne doivent donc pas être définies à des valeurs statiques (comme codé dans MCEBuddy 2.5.1 64 bits - 20190717 et comme nous l’avons discuté en messages privés). Les valeurs définies dans le code de la version 2.4.11 fonctionnent bien (je pense qu’elles sont extraites du fichier WTV source). Tous les exemples suivants ont été créés en utilisant la version 2.4.11 pour les conversions ainsi qu’un code que j’ai écrit pour apporter des modifications de métadonnées après la fin des conversions.
Pour que la fonction de reprise fonctionne correctement (ce qui était l’objectif initial de ce fil), il suffit de définir les valeurs de métadonnées suivantes (où seconds est une valeur représentant la durée de l’émission enregistrée en secondes). Dans toutes les métadonnées que j’ai examinées, StartTime et RecordStartTime étaient déjà définis correctement dans les métadonnées…
EndTime = (StartTime + seconds)
RecordEndTime = (RecordStartTime + seconds)
Resume = 0
Avec ce qui précède, la fonctionnalité de reprise fonctionne parfaitement et persiste entre les vues. Ce qui suit montre des fichiers WMC convertis avec persistance de la reprise (la version du visionneur a changé, donc l’apparence est légèrement différente des publications précédentes).
L’épisode The Nominations montre que quelques secondes ont été regardées
L’épisode Transfer montre que la visualisation s’est arrêtée à mi-chemin
Joindre des images aux enregistrements est également possible mais délicat. J’avais précédemment publié (par e-mail privé) qu’un épisode de Smash n’apparaissait pas après une conversion 2.5.1 BETA. De plus, j’ai ensuite découvert que tous les épisodes de “Inside the Actors Studio” convertis avec 2.5.1 avaient disparu. Ces problèmes aléatoires m’ont tourmenté pendant une semaine jusqu’à ce que je découvre par hasard la raison sous-jacente.
Il s’avère que les métadonnées ImageURL et PosterURL insérées par la version 2.5.1 Beta pointaient vers de grandes images jpg. Par exemple, certaines que j’ai vérifiées faisaient 680 x 1000 pixels ou plus. Je ne peux pas en être certain, mais je soupçonne qu’en interne le code HDHR (visionneur ou enregistreur - je ne sais pas lequel) manquait d’espace tampon, générant des exceptions et “empoisonnant” ainsi les épisodes, donnant l’impression qu’ils n’étaient pas là. Tous ces épisodes sont réapparus lorsque les étapes suivantes ont été prises.
Les métadonnées ImageURL et PosterURL ont été mises à jour pour pointer vers des fichiers jpg plus petits
Le service HDHomeRun RECORDER a été arrêté et redémarré
Avec cette découverte et la capacité d’apporter des modifications de métadonnées, la puissance du visionneur est devenue apparente et j’ai pu faire des choses très intéressantes. Par exemple, “The Capitol Fourth” est un spécial annuel du concert et des feux d’artifice à DC le 4 juillet. Il est marqué comme “Category”: “special” dans les métadonnées. Avec des modifications de métadonnées appropriées, ces programmes annuels ressemblent maintenant à une série plutôt qu’à de nombreux spéciaux séparés (en ignorant les valeurs Season/Episode artificielles qui consistent par exemple à convertir l’année 2019 en S20E19). Incidemment, les enregistrements 2017-2019 ont été faits avec HDHR recorder. Les enregistrements 2016 et antérieurs étaient des fichiers WTV convertis en utilisant MCEBuddy 2.4.1, mais on ne peut pas le dire en regardant ce qui suit…
J’aimerais voir ce qui suit dans la prochaine version
Incorporer la fonctionnalité de reprise comme décrit ci-dessus. Cela semble simple et devrait être facile à implémenter.
Fournir la capacité de joindre des images aux fichiers convertis. Si une URL appropriée ne peut pas être trouvée programmatiquement au moment de la conversion, placez des notations appropriées dans le fichier journal (peut-être avec des instructions pour exécuter un utilitaire avec une référence à un fichier jpg approprié) et laissez les métadonnées ImageURL et PosterURL définies à null. Les tailles suivantes sont utilisées par le moteur HDHR, donc je suppose que ce sont les tailles “recommandées”
ImageURL référence jpg à un fichier de 360 x 270 pixels ou moins
PosterURL référence jpg à un fichier de 240 x 360 pixels ou moins.
Contactez-moi si vous avez besoin d’informations supplémentaires.
Je suggère de le signaler également à HDHR (nous l’avons aussi fait, car c’est un potentiel problème de sécurité). Le micrologiciel devrait simplement ignorer les images trop grandes. Nous verrons comment gérer cela dans MCEBuddy pour l’instant, puisque les images proviennent d’Internet et que nous n’avons pas toujours une URL d’image plus petite. Pour l’instant, nous ne renseignerons pas ces informations. À titre d’information, une solution simple est de décocher l’option de téléchargement de l’affiche dans la page Tâche de conversion → Paramètres experts → Correction des métadonnées. Une fois que HDHR aura corrigé le micrologiciel, nous reprendrons l’ajout des URL d’image dans les métadonnées.
Vous pouvez essayer la dernière version bêta 2.5.1 avec ces changements.
J’utilise MCEBuddy 2.5.1 64bit - 20190723 et il préserve les métadonnées de manière identique lors de la suppression des publicités d’un enregistrement HDHR. Cependant, afin de ne pas casser la fonctionnalité de l’indicateur de progression, au minimum RecordEndTime devrait changer.
Lors d’une conversion récente, 33 minutes de publicités ont été supprimées d’un film de 2 heures. Par conséquent, l’indicateur de progression de la lecture affichait seulement 3/4 de progression alors que le film converti n’avait plus que quelques secondes à jouer. J’ai expérimenté et déterminé que si la métadonnée RecordEndTime est définie à RecordStartTime + secondesDuMpgConverti, alors l’indicateur de progression de la lecture se déplace comme prévu de l’extrême gauche (au début du film) à l’extrême droite (à la fin du film). Aucune autre modification n’a été apportée aux métadonnées.
