MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

Fejl / Funktionsanmodninger Bugs
1

MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

Jeg har lige givet yderligere donationer til MCEBuddy og Comskip.

Jeg har 2 systemer, hvor jeg kører MCEBuddy: en XP med dedikeret linje til HDHomeRun og en Dell G4 gaming-laptop med Win10.

Det er den anden, jeg bruger til at downloade fra min Tivo XL4 sort/hvide eller farvelagte westerns, så de efter MCEBuddy kan køre reklamefrit på en WDTV Live via USB-stick om natten, hvis jeg ikke kan sove eller vågner.

Det er generelt små filer, der crunches hurtigt på Win10-laptopen. Programmerne kan gå uger, før jeg ser en. Jeg opdagede, at lyden var fin i første halvdel, men så gik den ud af sync. Jeg prøvede at fejlsøge i dag med en ny comskip, gik så over til 2.4.11 64-bit-versionen, og konverteringerne fejlede derefter. Da det skete for alle programmerne, brugte jeg bare én til at fortsætte test. Jeg har Spectrum og tænkte på, om de – eftersom de sælger en western-kanal uden reklamer – måske har lavet ændringer på den kanal, jeg optager. Da jeg skiftede til 2.4.11, fejlede programmerne Tivo-remux hurtigt.

Jeg prøvede derfor at crunche programmet på XP-maskinen, der kører 2.3.15, og fik en konverteret fil, hvor lyden også gik ud af sync halvvejs.

På Win10-gaming-laptopen omdøbte jeg min comskip-mappe til comskip.old, men når det fejler ved Tivo-remux, når det jo ikke til comskip.

På Win10-laptopen indtastede jeg lige min Tivo Desktop Plus-nøgle, men den dør stadig ved Tivo-remux.

Jeg kører de standard, betalte comskip-filer.

BillJ

På Win10-maskinen gik jeg tilbage til en tidligere version, 2.4 Beta 1, og kan nu igen komme forbi Tivo-remux og konvertere filen til mp4, men der er stadig et lyd-sync-problem, og det sker sandsynligvis efter et reklameklip. Jeg troede, det kunne skyldes, at temp-mappen lå på D:-drevet i stedet for SSD-elementet, men at flytte den til C: hjalp ikke. Prøver nu med en anden tivo-fil.

2

Kan du vedhæfte logfilen fra begge konverteringer, den gamle 2.3.15 og den nyere 2.4.11. Der burde ikke være nogen forskel i tivo-remuxing-delen, hvis konfigurationen er den samme. Bruger du TiVO-Desktop (hurtig) eller langsomme overførsler (KMTTG)? Det er ikke relateret til comskip, men snarere til at sætte filen sammen igen, hvor den ældre version nogle gange gik ud af synkronisering, hvilket blev løst i de nyere udgivelser.

3

Har arbejdet på det i timevis og lavet ændringer, så logfilerne kan virke forvirrende.

Efter at have rullet tilbage til en tidligere MCEBuddy på Win10-maskinen kunne jeg igen få konverteringer. Der var stort set ingen forskel mellem denne og konverteringen på XP-maskinen med 2.3.15. Begge har lyd-synkroniseringsproblemer.

På Win10-maskinen har jeg prøvet forskellige konverteringer uden fjernelse af reklamer. Jeg prøvede AVI ubehandlet og fik god synkronisering i starten af en western – jeg går efter dem lavet før 1955 – men ved at springe til slutningen var der tabt synkronisering.

Jeg prøvede lige AVI Mpeg2 uden reklameklip, samme Roy Rogers-film. Undersøgelse viser, at lyden er synkroniseret indtil den første reklame og er ude af synkronisering efter reklamen.

Så der er noget ved reklamerne – selv når de ignoreres – der ødelægger synkroniseringen.

Interessant nok, da jeg begyndte at få westerns, planlagde jeg optagelse af alle Zane Grey Theatre-afsnit, men fandt ud af, at Charter/Spectrum ville liste 4 eller 5 afsnit fra forskellige sæsoner i træk, men vise smarte reklamer i stedet, hvilket effektivt blokerede optagelsen af disse afsnit, hvis de blev sendt igen.

Så igen tror jeg, det er noget, der bevidst gøres for at blokere fjernelse af reklamer.

BillJ

4

Så en Tivo-fil-western mister synkroniseringen efter den første reklame, både på XP-maskinen med 2.3.15 og på Dell G3 med 2.4 beta, mens Dell G3 med 2.4.11 fejler ved remux.

I morges optog jeg derfor en episode af Death Valley Days med HDHR på en dedikeret linje til XP-maskinen og kørte den igennem MCEBuddy 2.3.15. Resultatet var en perfekt video uden reklamer og uden lyd-synk-tab.

Jeg bemærker, at hvis jeg forsøger at kopiere HDHR-.ts-filen til en USB-nøgle for at teste konvertering på Win10-Dellen, popper der en besked op:
“/Confirm Stream Loss. The file … has extra information attached to it that might be lost if you continue copying. The contents of the file will not be affected. Information that might be lost includes: :metadata.xml:$DATA & :Timing.Info:$$DATA”

Jeg optog også udsendelsen på Tivo. Jeg vil overføre den til XP-maskinen og flytte den til USB-nøglen. Hvis der ikke optræder en advarsel om datatab ved kopiering, er problemet måske, at Tivo ikke overfører Timing.Info:$$DATA.

BillJ

5

Silicondust HDHR3 optagede video Death Valley Days .ts-fil kopieret til USB-drevet og derefter til Win10-maskinen blev behandlet af MCEBuddy 2.4 beta til MP4 Normal. Jeg havde ikke fjernelse af reklamer markeret, da det var den sidste test i går aftes. Den resulterende MP4-fil afspiller perfekt til slutningen. Så Timing.Info:$$DATA, der blev tilbageholdt ved kopiering af .ts-filen fra XP-maskinen, er ikke afgørende for den succesfulde konvertering. Der ville være et andet problem med .tivo-filer.

6

Kopiering af .tivo-filen fra XP-maskinen til USB-nøglen giver ingen henvisning til nogen $$DATA, der holdes tilbage.

Påbegyndelse af konvertering på XP-maskinen samtidig med på Win10-maskinen … XP-maskinen er langsommere og vil tage cirka 3½ minut (b&w-videoen er en meget lille fil relativt set) … Win10 blev færdig først med 2.4 beta, synkronisering mislykkes mod slutningen. Tjekker XP 2.3.15 færdigkonvertering – synkroniseringen mislykkes også i den sidste halvdel af filen konverteret på XP-maskinen.

SiliconDust HomeRun 3-optagelsesfilen konverteres med succes, men de overførte TiVo-optagede filer til begge maskiner formår ikke at bevare lydsynkroniseringen gennem hele videoen.

Jeg bemærker, at TiVo Desktop hurtig overførsel er fravalgt.

7

Forsøger MCEBuddy 2.5 Beta 1 på Win10-maskinen med .tivo-fil. MP4 Normal mislykkedes ved remux. AVI MPeg2 mislykkedes ved remux. Ændrede indstillinger til ikke at remuxe. Genstartede maskinen, tjekkede at “ingen remux” var markeret, startede konvertering, og denne beta ignorerede “ingen remux”, hvorved konverteringen døde. Prøvede AVI Mpeg2 ubehandlet og igen med “ingen remux” markeret; programmet forsøgte at remuxe, og konverteringen døde.

Jeg bør nævne, at jeg ikke kun bruger Tivo Desktop slow transfer, men udelukkende bruger MCEBuddy.ServiceCMD.exe og har MCEBuddy Windows Service deaktiveret. Jeg vil prøve en Tivo fast transfer.

Win10-maskine, Dell G3 bærbar, Tivo Desktop-overførsel af Death Valley Days-afsnittet ved hjælp af Tivo fast transfer (fra en XL4), MCEBuddy 2.5 Beta 1 (18. juli 2019), MCEBuddy 2.x CommandLine Service, konverter til MP4 med “ikke remux” markeret, konvertering mislykkedes efter et remux-forsøg. Måske sender moderne Tivo-enheder en anden fil?

8

At få en ren optagelse på XP-maskinen med linjen til SiliconDust krævede noget arbejde, selvom problemet måske lå i MCEBuddy’s databehandling. I starten havde jeg SiliconDust på netværket, men det blev bedre, da jeg installerede et andet NIC udelukkende til SiliconDust. Jeg fik dog stadig fejl i de færdige filer. Den endelige bedst fungerende opsætning var at deaktivere det internetforbundne NIC, inden optagelse startede om aftenen. Så ville jeg om natten aktivere det internetforbundne NIC og starte MCEBuddy. Men der var én ting mere: før optagelse startede, kørte jeg min kill.tivo.bat, der afsluttede de to tivo-filer, tivotransfer.exe og tivonotify.exe, samt browsere og e-mail-programmer, der måske var åbne. Enten tivotransfer.exe eller tivonotify.exe ville med jævne mellemrum gøre noget, der forstyrrede enten optagelsen eller den senere MCEBuddy-databehandling. Effekten af tivo-filerne var at gøre SiliconDust mindre effektiv eller forhindre MCEBuddy i at skelne mellem program og reklamer.

9

Prøvede noget andet på Dell G3 gaming-laptoppen med Win10. Efter at have afinstalleret MCEBuddy 2.5 Beta 1 64-bit installerede jeg den nyeste stabile 32-bit version, 2.4.11. Jeg prøvede en for nyligt optaget film overført fra TiVo. Lige nu er den nået langt ind i “Remuxing TiVO file…” – det er aldrig sket før. Da jeg prøvede denne film med 64-bit versionen, fik jeg en “system.badimageformatexception” i loggen, så jeg søgte på det. Fra codeproject.com: “Usually this is related to the difference in 64bit and 32bit DLL builds and processes.”

Fejlede efter remux. Fra loggen: “Unsupported codec with id 0 for input stream 2”. Stream #0:0 Video mpeg2video; Stream #0:1 Audio ac3; Stream #0:2 Unknown:none. Dette var med TiVo Desktop hurtig overførsel. Vil prøve med langsom overførsel…

Remux..Advertisement scan… arbejder… fejler. Bemærk: “Ignore copy protection” har aldrig været markeret.

Fandt ud af, hvor jeg begik en fejl. Ved at skifte til 32-bit går den til 32-bit program files MCEBuddy2x, og selvom jeg ændrede placeringen af comskip.ini, glemte jeg at ændre placeringen af comskip.exe filen. Vil køre nogle tests igen.

Skiftede til shows i stedet for film og prøvede en Death Valley Days TiVo-optagelse igen. Det virkede næsten. Nåede til 14 minutter af det 22 minutter lange show, før den mistede synkronisering. Men jeg lod ikke computeren være helt uforstyrret under processen. Vil prøve en film igen.

10

Jeg har lige sendt dig en PM og vil undersøge dette.

11

32-bit stabil, langsom overførsel, filmen Revolver.tivo, remuxing, analysering, comskip arbejder, klipning…fletning…analysering…konvertering…(12 minutter 44 sekunder forventet)…færdig. Tjekker. Synk god ved 57 minutter 1:41 stort set, lidt ude af sync ved 1:19, og stadig lidt ude af sync ved slutningen. Måske er det et hukommelsesstørrelsesproblem og at drevet er et hybrid-drev, ikke en fuld SSD.

Skiftet til shows/other og shows. Startede en Zane Grey b&w .tivo. Sync lidt ude mod slutningen.

Prøver 3 Death Valley Days-videoer fra SilconDust HDHR3. Jeg bemærker, at når jeg optager med HDHR3, hvis der er mere end én episode på den dag eller nat, viser alle serien, episoden og navnet på den første optagelse af det show den nat. Nogle gange gør den det slet ikke, men giver kun dato og tidspunkt for optagelsen. Alle optaget/konverteret perfekt.

Går nu tilbage til Beta 1 64-bit og genhenter hurtigt i et forsøg på at få den fejl, der viste sig tidligere i dag.

Kører 2.5 beta 1, Revolver.tivo, hurtig overførsel, fejlede. Har dupliceret System.BadImageFormatException og sender loggen til Goose.

12

BadImageFormatException med 64-bit builden af MCEBuddy til TiVO-remuxing er blevet rettet i dagens 2.5.1 BETA-build. Det var et problem, der blev introduceret i 64-bit builden 2.4.9 under en optimeringsændring.

13

Tak Goose.

14

Meget fint. Tak.