MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

Fehler / Funktionswünsche Bugs
1

MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

Ich habe gerade weitere Spenden an MCEBuddy & Comskip gemacht.

Ich habe 2 Systeme, auf denen ich MCEBuddy betreibe: einen XP mit einer dedizierten Leitung zum HDHomeRun und ein Dell G4 Gaming-Laptop mit Win10.

Das Zweitere nutze ich, um von meinem Tivo XL4 schwarz-weiße oder kolorierte Westerns herunterzuladen, die nach MCEBuddy werbefrei auf einem WDTV Live per USB-Stick nachts laufen, wenn ich nicht schlafen kann oder aufwache.

Das sind in der Regel kleine Dateien, die auf dem Win10-Laptop schnell verarbeitet werden. Die Sendungen können Wochen liegen, bevor ich eine ansehe. Ich stellte fest, dass der Ton für die erste Hälfte in Ordnung ist, dann aber asynchron wird. Heute versuchte ich, das Problem mit einem neuen Comskip zu lösen, wechselte dann auf die 64-Bit-Version 2.4.11, und die Konvertierungen schlugen fehl. Da es bei allen Sendungen passierte, nahm ich einfach eine zum Testen. Ich habe Spectrum und fragte mich, ob sie, da sie einen werbefreien Western-Kanal verkaufen, möglicherweise Änderungen an dem Kanal vorgenommen haben, den ich aufnehme. Als ich auf 2.4.11 wechselte, schlugen die Sendungen beim Tivo-Remux schnell fehl.

Also versuchte ich, die Sendung auf dem XP-Rechner zu konvertieren, der 2.3.15 läuft, und erhielt eine konvertierte Datei, bei der der Ton ebenfalls ab der Hälfte asynchron war.

Auf dem Win10-Gaming-Laptop benannte ich mein Comskip-Verzeichnis in comskip.old um, aber wenn Tivo-Remux fehlschlägt, kommt es natürlich nicht zu Comskip.

Auf dem Win10-Laptop gab ich gerade meinen Tivo Desktop Plus-Key ein, aber es stirbt immer noch beim Tivo-Remux.

Ich verwende die Standard-Comskip-Dateien, die ich bezahlt habe.

BillJ

Auf der Win10-Maschine ging ich zurück auf eine frühere Version, 2.4 Beta 1, und kann wieder über Tivo Remux hinausgehen und die Datei in mp4 konvertieren, aber es gibt wieder einen Sound-Sync-Fehler, der wahrscheinlich nach einem Werbeschnitt auftritt. Ich dachte, es könnte daran liegen, dass sich die Temp-Verzeichnisse auf dem D:-Laufwerk statt auf dem SSD-Element befinden, aber das Verschieben nach C: half nicht. Ich versuche jetzt eine andere Tivo-Datei.

2

Können Sie die Logdateien beider Konvertierungen anhängen, sowohl die alte 2.3.15 als auch die neuere 2.4.11? Beim TiVo-Remuxing sollte es keinen Unterschied geben, wenn die Konfiguration identisch ist. Verwenden Sie TiVo Desktop (schnell) oder langsame Übertragungen (KMTTG)? Es hängt nicht mit comskip zusammen, sondern damit, dass die Datei wieder zusammengesetzt wird; dabei geriet die ältere Version manchmal außer Takt, was in den neueren Releases behoben wurde.

3

Ich bin schon seit Stunden dabei und habe Änderungen vorgenommen, daher könnten die Log-Dateien verwirrend sein.

Nachdem ich auf dem Win10-Rechner zu einer früheren MCEBuddy-Version zurückgekehrt bin, konnten wieder Konvertierungen durchgeführt werden. Es gab im Wesentlichen keinen Unterschied zu dieser und der Konvertierung auf dem XP-Rechner mit 2.3.15. Beide haben Sound-Sync-Probleme.

Auf dem Win10-Rechner habe ich verschiedene Konvertierungen ohne Werbeentfernung ausprobiert. Ich habe AVI unbearbeitet versucht und hatte am Anfang eines Westerns einen guten Sync – ich bevorzuge die vor 1955 gedrehten –, aber als ich ans Ende sprang, gab es einen Sync-Verlust.

Ich habe gerade AVI Mpeg2 ohne Werbeschnitt versucht, derselbe Roy-Rogers-Film. Die Prüfung zeigt, dass der Ton synchron ist, bis zur ersten Werbung danach ist er außer Sync.

Es liegt also an den Werbespots, selbst wenn sie ignoriert werden, ruinieren sie den Sync.

Interessanterweise habe ich, als ich anfing, Westerns zu bekommen, die Aufnahme aller „Zane Grey Theatre“-Folgen geplant, aber Charter/Spectrum listete 4 oder 5 Folgen verschiedener Staffeln hintereinander auf und strahlte stattdessen auffällige Werbung aus, blockierte dadurch effektiv die Aufnahme dieser Folgen, falls sie erneut ausgestrahlt wurden.

Ich denke also wieder, dass absichtlich etwas unternommen wird, um die Werbeentfernung zu blockieren.

BillJ

4

Also, eine Tivo-Datei (Western) verliert nach der ersten Werbung die Synchronisation – sowohl auf dem XP-Rechner mit 2.3.15 als auch auf dem Dell G3 mit 2.4 beta, während der Dell G3 mit 2.4.11 beim Remuxen scheitert.

Heute früh habe ich eine Folge von „Death Valley Days“ über die HDHR auf einer dedizierten Leitung zum XP-Rechner aufgenommen und anschließend mit MCEBuddy 2.3.15 konvertiert. Das Video war perfekt: keine Werbung und kein Ton-Sync-Verlust.

Ich stelle fest: Kopiere ich die HDHR-.ts-Datei auf einen USB-Stick, um die Konvertierung auf dem Win10-Dell zu testen, erscheint die Meldung „/Confirm Stream Loss. Die Datei … enthält zusätzliche Informationen, die beim Kopieren verloren gehen könnten. Der Inhalt der Datei bleibt unberührt. Möglicherweise geht verloren: :metadata.xml:$DATA & :Timing.Info:$$DATA“.

Ich habe die Sendung auch auf dem Tivo aufgezeichnet. Ich werde sie auf den XP-Rechner übertragen und versuchen, sie auf den Stick zu kopieren. Kommt dabei keine Warnung über Datenverlust, liegt das Problem möglicherweise daran, dass Tivo Timing.Info:$$DATA nicht überträgt.

BillJ

5

Die von Silicondust HDHR3 aufgezeichnete Death Valley Days-.ts-Datei, die auf den USB-Stick und anschließend auf den Win10-Rechner kopiert wurde, wurde von MCEBuddy 2.4 Beta in MP4 Normal konvertiert. Ich hatte keine Werbeentfernung aktiviert, da das der letzte Test gestern Nacht war. Die resultierende MP4-Datei läuft einwandfrei bis zum Ende. Das bei der Übertragung der .ts-Datei vom XP-Rechner zurückgehaltene Timing.Info:$$DATA ist also für eine erfolgreiche Konvertierung nicht entscheidend. Es müsste ein anderes Problem mit .tivo-Dateien geben.

6

Das Kopieren der .tivo-Datei vom XP-Rechner auf den USB-Stick führt zu keiner Meldung über zurückgehaltene $$DATA.

Wenn man die Konvertierung auf dem XP-Rechner gleichzeitig mit dem Win10-Rechner startet … ist der XP-Rechner langsamer und braucht etwa 3½ Minuten (das s/w-Video ist verhältnismäßig sehr klein) … Win10 ist mit 2.4 Beta zuerst fertig, am Ende fällt die Synchronisation aus. Prüft man die auf dem XP-Rechner mit 2.3.15 fertig konvertierte Datei – auch hier bricht die Synchronisation in der zweiten Hälfte der konvertierten Datei zusammen.

Die von SiliconDust HomeRun 3 aufgezeichnete Datei konvertiert also erfolgreich, die übertragenen TiVo-Aufnahmen auf beiden Rechnern verlieren jedoch den Ton-Sync während des gesamten Videos.

Ich stelle fest, dass TiVo Desktop Fast Transfer deaktiviert ist.

7

Ich teste MCEBuddy 2.5 Beta 1 auf dem Win10-Computer mit .tivo-Datei. MP4 Normal schlug beim Remux fehl. AVI MPeg2 schlug beim Remux fehl. Einstellungen auf „nicht remuxen“ geändert. Rechner neu gestartet, kontrolliert, dass „kein Remux“ angehakt war, Konvertierung gestartet – die Beta ignorierte das „kein Remux“, Konvertierung brach ab. AVI Mpeg2 unprocessed und erneut mit „kein Remux“ angehakt versucht; das Programm versuchte trotzdem zu remuxen, Konvertierung brach ab.

Ich sollte erwähnen, dass ich nicht nur Tivo Desktop Slow Transfer nutze, sondern ausschließlich die MCEBuddy.ServiceCMD.exe und den MCEBuddy-Windows-Dienst deaktiviert habe. Ich werde einen Tivo Fast Transfer versuchen.

Win10-Rechner, Dell G3 Laptop, Tivo Desktop-Transfer der Death Valley Days-Folge per Tivo Fast Transfer (von einem XL4), MCEBuddy 2.5 Beta 1 (18. Juli 2019), MCEBuddy 2.x CommandLine Service, Konvertierung nach MP4 mit „nicht remuxen“ angehakt; Konvertierung schlug nach Remux-Versuch fehl. Vielleicht senden moderne Tivo-Geräte eine andere Datei?

8

Eine saubere Aufnahme auf dem XP-Rechner über die Leitung zum SiliconDust zu bekommen, war mühsam – möglicherweise lag das Problem aber auch an der MCEBuddy-Datenverarbeitung. Zunächst hatte ich den SiliconDust im Netzwerk; die Situation besserte sich, als ich eine zweite NIC ausschließlich für den SiliconDust einsetzte. Dennoch blieben Fehler in den fertigen Dateien. Die letztlich beste Konfiguration bestand darin, die internetverbundene NIC vor Beginn der nächtlichen Aufnahme zu deaktivieren. Am Ende der Nacht aktivierte ich die internetverbundene NIC wieder und startete MCEBuddy. Noch ein Schritt war nötig: Vor jeder Aufnahme führte ich mein kill.tivo.bat aus, das die beiden TiVo-Prozesse tivotransfer.exe und tivonotify.exe sowie alle offenen Browser- und E-Mail-Programme beendete. Mindestens einer der beiden TiVo-Prozesse führte regelmäßig Aktionen aus, die entweder die Aufnahme oder die anschließende MCEBuddy-Verarbeitung störten. Die Auswirkung der TiVo-Dateien bestand darin, den SiliconDust zu beeinträchtigen oder MCEBuddy daran zu hindern, eindeutig zwischen Programminhalt und Werbung zu unterscheiden.

9

Habe etwas anderes auf dem Dell G3 Gaming-Laptop mit Win10 ausprobiert. Nachdem ich die MCEBuddy 2.5 Beta 1 64-Bit deinstalliert hatte, installierte ich die neueste stabile 32-Bit-Version, 2.4.11. Ich habe einen kürzlich aufgenommenen Film ausprobiert, der vom Tivo übertragen wurde. Im Moment ist er schon weit beim Remuxen der TiVO-Datei… So weit bin ich vorher nie gekommen. Als ich diesen Film mit der 64-Bit-Version versuchte, bekam ich eine „System.BadImageFormatException“ im Log, also habe ich danach gesucht. Laut codeproject.com „Hängt das meist mit Unterschieden zwischen 64-Bit- und 32-Bit-DLL-Builds und -Prozessen zusammen.“

Nach dem Remuxen fehlgeschlagen. Aus dem Log: „Nicht unterstützter Codec mit ID 0 für Eingabestream 2“. Stream #0:0 Video mpeg2video; Stream #0:1 Audio ac3; Stream #0:2 Unbekannt:none – das war mit Tivo Desktop Schnell-Übertragung. Werde es mit Langsam-Übertragung versuchen…

Remux..Werbescan… läuft… schlägt fehl. Hinweis: „Copy Protection ignorieren“ war nie aktiviert.

Habe meinen Fehler gefunden. Bei der 32-Bit-Version landet man im 32-Bit-Programme-Ordner MCEBuddy2x und obwohl ich den Speicherort der comskip.ini geändert hatte, habe ich vergessen, ebenfalls den Speicherort der comskip.exe anzupassen. Werde ein paar Tests wiederholen.

Zu Serien statt Filmen gewechselt und noch mal eine Death Valley Days-Tivo-Aufnahme versucht. Fast geklappt. Bis Minute 14 der 22-minütigen Folge lief alles synchron, dann ging es auseinander. Allerdings habe ich den Rechner währenddessen nicht komplett in Ruhe gelassen. Werde wieder einen Film probieren.

10

Ich habe dir soeben eine PN geschickt und werde mich darum kümmern.

11

32-Bit stabil, langsamer Transfer, Film Revolver.tivo, Remuxing, Analysieren, Comskip arbeitet, Schneiden… Zusammenführen… Analysieren… Konvertieren… (12 Minuten 44 Sekunden erwartet)… fertig. Prüfen. Sync bei 57 Minuten 1:41 gut, fast perfekt, leicht versetzt bei 1:19, und auch am Ende leicht daneben. Vielleicht ein Speichergrößenproblem und dass das Laufwerk ein Hybrid- statt eines Voll-SSD ist.

Umgestellt auf shows/other und shows. Gestartet mit Zane Grey s/w .tivo. Sync gegen Ende etwas daneben.

Versuche 3 Death-Valley-Days-Videos vom SilconDust HDHR3. Ich stelle fest, dass bei Aufnahmen mit HDHR3, wenn an einem Tag oder Abend mehr als eine Episode vorhanden ist, alle die Serie, Episode und Namen der ersten Aufnahme dieser Sendung in dieser Nacht anzeigen. Manchmal schafft es das Gerät nicht einmal das, sondern liefert nur Datum und Uhrzeit der Aufnahme. Alle aufgenommen/konvertiert, einwandfrei.

Gehe nun zurück zu Beta 1 64-Bit und lade erneut schnell herunter, um den Fehler zu reproduzieren, der heute früher auftrat.

Laufe 2.5 Beta 1, Revolver.tivo, schneller Transfer, fehlgeschlagen. Habe die System.BadImageFormatException reproduziert und sende das Log an Goose.

12

Die BadImageFormatException mit der 64-Bit-Version von MCEBuddy für TiVO-Remuxing wurde im heutigen 2.5.1 BETA-Build behoben. Es handelte sich um ein Problem, das im 64-Bit-Build 2.4.9 während einer Optimierungsänderung eingeführt wurde.

13

Danke, Goose.

14

Sehr schön. Danke.