MCEBuddy 2.4.8 64bit versus 2.4.11 64bit & Tivo Remux

Fouten / Functieverzoeken Bugs
1

MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

Ik heb zojuist extra donaties gedaan aan MCEBuddy en Comskip.

Ik heb 2 systemen waarop ik MCEBuddy draai, een XP met een dedicated lijn naar HDHomeRun en een Dell G4 gaming-laptop met Win10.

Het is de tweede die ik gebruik om van mijn Tivo XL4 zwart-wit of gekleurde westerns te downloaden om ze na MCEBuddy reclamevrij af te spelen op een WDTV Live via een usb-stick 's nachts als ik niet kan slapen of wakker word.

Dit zijn meestal kleine bestanden en worden snel verwerkt op de Win10-laptop. De shows kunnen weken duren voordat ik er een kijk. Ik merkte dat het geluid in het eerste deel goed was, maar daarna raakt het uit sync. Ik probeerde het vandaag te troubleshooten met een nieuwe comskip, ging toen naar de 2.4.11 64-bit versie en conversies mislukten daarna. Omdat het bij alle shows gebeurde, gebruikte ik er gewoon één om te blijven testen. Ik heb Spectrum en vroeg me af of ze, aangezien ze een reclamevrije westernzender verkopen, mogelijk wijzigingen hebben aangebracht aan het kanaal dat ik opneem. Toen ik naar 2.4.11 ging, faalden de shows snel bij Tivo remux.

Dus probeerde ik de show te verwerken op de XP-machine die 2.3.15 draait en ik kreeg een geconverteerd bestand dat ook halverwege geluid uit sync had.

Op de Win10 gaming-laptop hernoemde ik mijn comskip-directory naar comskip.old, maar natuurlijk, als het bij Tivo remux faalt, komt het niet bij comskip.

Op de Win10-laptop vulde ik zojuist mijn Tivo Desktop Plus-sleutel in, maar het sterft nog steeds bij Tivo remux.

Ik gebruik de standaard, betaalde, comskip-bestanden.

BillJ

Op de Win10-machine ging ik terug naar een eerdere versie, 2.4 Beta 1, en ik kan weer voorbij Tivo Remux komen en het bestand converteren naar mp4, maar opnieuw is er een geluid-sync-probleem en gebeurt het waarschijnlijk na een reclamesnede. Ik dacht dat het kon komen doordat temp-directories op de D:-schijf stonden in plaats van op de SSD, maar verplaatsen naar C: hielp niet. Ik probeer nu een ander tivo-bestand.

2

Kun je het logbestand van beide conversies toevoegen, de oude 2.3.15 en de nieuwere 2.4.11. Er zou geen verschil mogen zijn in het tivo-remuxen als de configuratie hetzelfde is. Gebruik je TiVO desktop (snel) of langzame overdrachten (KMTTG)? Het heeft niets met comskip te maken, maar met het weer aan elkaar plakken van het bestand; bij de oudere versie raakte de audio soms uit sync, wat in de nieuwere versies is verholpen.

3

Ben hier al uren mee bezig en heb wijzigingen aangebracht, dus de logbestanden kunnen verwarrend zijn.

Toen ik op de Win10-machine terugging naar een eerdere versie van MCEBuddy, konden conversies weer worden uitgevoerd. Er was vrijwel geen verschil met de conversie op de XP-machine met versie 2.3.15; op beide treden geluidssynchronisatieproblemen op.

Op de Win10-machine heb ik verschillende conversies geprobeerd zonder reclame te verwijderen. Ik probeerde AVI onbewerkt en kreeg een goede synchronisatie aan het begin van een western – ik kies voor die van vóór 1955 – maar bij het naar het einde springen was de synchronisatie verloren.

Ik probeerde zojuist AVI Mpeg2 zonder reclameknip, met dezelfde Roy Rogers-film. Onderzoek toont aan dat het geluid gesynchroniseerd blijft tot de eerste reclame en daarna uit de pas loopt.

Er is dus iets aan de reclame – zelfs als die genegeerd wordt – dat de synchronisatie verstoort.

Interessant genoeg, toen ik begon met westerns op te nemen, plante ik alle afleveringen van Zane Grey Theatre in, maar Charter/Spectrum gaf vaak 4 of 5 afleveringen van verschillende seizoenen achter elkaar aan en vertoonde vervolgens opvallende reclames, waardoor die afleveringen effectief geblokkeerd werden als ze later nog eens uitgezonden zouden worden.

Ik denk dus opnieuw dat er expres iets wordt gedaan om het verwijderen van reclame te blokkeren.

BillJ

4

Dus, een Tivo-bestand western raakt de sync kwijt na de eerste reclame op zowel de XP met 2.3.15 als de Dell G3 met 2.4 beta, terwijl de Dell G3 met 2.4.11 faalt bij remux.

Vanmorgen nam ik een aflevering van Death Valley Days op met de HDHR op een dedicated lijn naar de XP-machine en draaide daarna MCEBuddy 2.3.15. Ik kreeg een perfecte video, zonder reclame en zonder verlies van geluidssynchronisatie.

Ik merk dat als ik het HDHR .ts-bestand naar een usb-stick probeer te kopiëren om de conversie op de Win10 Dell te testen, er een pop-up verschijnt met: “/Bevestig verlies van stream. Het bestand … heeft extra informatie die verloren kan gaan bij het kopiëren. De inhoud van het bestand wordt niet aangetast. Informatie die verloren kan gaan: :metadata.xml:$DATA & :Timing.Info:$$DATA”

Ik heb de show ook op Tivo opgenomen. Ik zal die naar de XP-machine overzetten en proberen hem naar de usb-stick te kopiëren. Als er geen melding komt over gegevensverlies, dan is het probleem mogelijk dat Tivo de Timing.Info:$$DATA niet overdraagt.

BillJ

5

De Silicondust HDHR3 nam de video Death Valley Days op. Het .ts-bestand dat naar de usb-stick en daarna naar de Windows 10-machine werd gekopieerd, werd door MCEBuddy 2.4 bèta naar MP4 Normal omgezet. Ik had geen reclameverwijdering aangevinkt, want dat was de laatste test van gisteravond. Het resulterende MP4-bestand speelt tot het einde probleemloos af. De Timing.Info:$$DATA die achterbleef bij het kopiëren van het .ts-bestand van de XP-machine is dus niet cruciaal voor een succesvolle conversie. Er moet een ander probleem zijn met .tivo-bestanden.

6

Het kopiëren van het .tivo-bestand van de XP-machine naar de usb-stick geeft geen melding van $$DATA dat wordt vastgehouden.

Het starten van de conversie op de XP-machine tegelijk met de Win10-machine … de XP-machine is trager en duurt ongeveer 3½ minuut (de zwart-witvideo is relatief gezien een heel klein bestand) … Win10 is als eerste klaar met 2.4 beta, synchronisatie faalt tegen het einde. Bij controle: de XP 2.3.15-conversie is voltooid – ook hier faalt de synchronisatie in de tweede helft van het bestand dat op de XP-machine is geconverteerd.

Het door SiliconDust HomeRun 3 opgenomen bestand converteert dus succesvol, maar de overgezette TiVo-opnames naar beide machines behouden de geluidssynchronisatie niet gedurende de hele video.

Ik zie dat TiVo Desktop Fast Transfer uitgeschakeld is.

7

MCEBuddy 2.5 Beta 1 uitproberen op de Win10-machine met .tivo-bestand. MP4 Normal mislukte bij remux. AVI MPeg2 mislukte bij remux. Instellingen gewijzigd naar niet remuxen. Machine opnieuw opgestart, gecontroleerd of ‘niet remuxen’ was aangevinkt, conversie gestart en deze beta negeerde de ‘niet remuxen’-optie, waardoor de conversie mislukte. AVI Mpeg2 onbewerkt geprobeerd en opnieuw met ‘niet remuxen’ aangevinkt; het programma probeerde te remuxen en de conversie mislukte.

Ik wil vermelden dat ik niet alleen Tivo Desktop slow transfer gebruik, maar uitsluitend de MCEBuddy.ServiceCMD.exe gebruik en de MCEBuddy Windows Service uitgeschakeld heb. Ik zal een Tivo fast transfer proberen.

Win10-machine, Dell G3-laptop, Tivo Desktop transfer van de Death Valley Days-aflevering via Tivo fast transfer (van een XL4), MCEBuddy 2.5 Beta 1 (18 juli 2019), MCEBuddy 2.x CommandLine Service, converteren naar MP4 met ‘niet remuxen’ aangevinkt, conversie mislukte na een remuxpoging. Misschien versturen moderne Tivo-apparaten een ander bestand?

8

Een schone opname maken op de XP-machine met de lijn naar de SiliconDust vergde wat moeite, hoewel het probleem mogelijk in de MCEBuddy-gegevensverwerking zat. Aanvankelijk had ik de SiliconDust op het netwerk staan, maar het verbeterde toen ik een tweede NIC installeerde die exclusief voor de SiliconDust was. Toch kreeg ik nog steeds storingen in de uiteindelijke bestanden. De uiteindelijk beste werkende configuratie was om de met internet verbonden NIC uit te schakelen voordat ik 's nachts begon met opnemen. Aan het einde van de nacht schakelde ik de met internet verbonden NIC weer in en startte MCEBuddy. Maar er was nog iets: voordat ik begon met opnemen, voerde ik mijn kill.tivo.bat uit, waarmee ik de twee tivo-bestanden afsluitte – tivotransfer.exe en tivonotify.exe – evenals browsers en e-mailprogramma’s die mogelijk open stonden. Zeker één van die twee – tivotransfer.exe of tivonotify.exe – deed periodisch iets dat ofwel de opname verstoorde, ofwel verhinderde dat MCEBuddy later een schone scheiding kon maken tussen programma en reclame. Het effect van de tivo-bestanden was dat de SiliconDust minder effectief werd, of dat MCEBuddy geen schone lezing kreeg van wat programma was en wat reclame.

9

Ik probeerde iets anders op de Dell G3 gaming-laptop met Win10. Nadat ik de MCEBuddy 2.5 Beta 1 64-bit had verwijderd, installeerde ik de nieuwste stabiele 32-bit versie, 2.4.11. Ik probeerde een onlangs opgenomen film die vanaf Tivo was overgezet. Op dit moment is hij al ver in het remuxen van het TiVO-bestand… Ik ben hiervoor nooit zo ver gekomen. Toen ik deze film met de 64-bit versie probeerde, kreeg ik een “system.badimageformatexception” in het log, dus zocht ik daarnaar. Op codeproject.com staat: “Meestal heeft dit te maken met het verschil tussen 64-bit en 32-bit DLL-builds en processen.”

Mislukt na remux. Uit het log: “Niet-ondersteunde codec met id 0 voor invoerstroom 2”. Stream #0:0 Video mpeg2video; Stream #0:1 Audio ac3; Stream #0:2 Onbekend:none Dit was met Tivo Desktop snelle overdracht. Ik probeer het met een trage overdracht…

Remux..Advertentiescan… bezig… mislukt. Opmerking: negeer kopieerbeveiliging is nooit aangevinkt.

Ik vond waar ik een fout had gemaakt. Bij het overschakelen naar de 32-bit versie ga je naar de Program Files (x86)\MCEBuddy2x-map en hoewel ik de locatie van comskip.ini had aangepast, vergat ik de locatie van het comskip.exe-bestand te wijzigen. Ik zal enkele tests opnieuw uitvoeren.

Ik schakelde over van films naar series en probeerde opnieuw een Death Valley Days-opname van Tivo. Het werkte bijna. Tot 14 minuten van de 22 minuten durende aflevering bleef alles gesynchroniseerd, daarna raakte het beeld uit sync. Maar ik had de computer tijdens het proces niet volledig met rust gelaten. Ik probeer opnieuw een film.

10

Ik heb je zojuist een PB gestuurd en zal hier naar kijken.

11

32 bit stabiel, langzame overdracht, film Revolver.tivo, remuxing, analyseren, comskip werkt, knippen…samenvoegen…analyseren…converteren… (12 minuten 44 seconden verwacht)…voltooid. Controleren. Sync goed op 57 minuten 1:41 vrijwel, lichtjes uit sync op 1:19, en nog steeds lichtjes uit sync aan het einde. Misschien is het een geheugengrootteprobleem en dat de schijf een hybride is, geen volledige ssd.

Overgeschakeld naar shows/other en shows. Begonnen met een Zane Grey b&w .tivo. Sync aan het einde een beetje uit sync.

3 Death Valley Days-video’s van Silicondust HDHR3 aan het proberen. Ik merk dat wanneer ik opneem met HDHR3, als er meer dan één aflevering op die dag of nacht is, ze allemaal de serie, aflevering en naam van de eerste opname van die show die nacht tonen. Soms doet het dat zelfs niet en geeft alleen de datum en tijd van de opname. Allemaal perfect opgenomen/geconverteerd.

Nu terug naar Beta 1 64 bit en opnieuw snel downloaden in een poging de fout van eerder vandaag te reproduceren.

2.5 beta 1 aan het draaien, Revolver.tivo, snelle overdracht, mislukt. De System.BadImageFormatException is gedupliceerd en de log wordt naar Goose gestuurd.

12

De BadImageFormatException met de 64-bit build van MCEBuddy voor TiVO-remuxen is opgelost in de huidige 2.5.1 BETA-build. Het was een probleem dat in de 64-bit build 2.4.9 is geïntroduceerd tijdens een optimalisatiewijziging.

13

Dank je wel, Goose.

14

Heel mooi. Bedankt.