MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

MCEBuddy 2.4.8 64bit vs 2.4.11 64bit & Tivo Remux

I just made additional donations to MCEBuddy & Comskip.

I have 2 systems on which I run MCEBuddy, an XP with a dedicated line to HDHomeRun and a Dell G4 gaming laptop running Win10.

It’s the second that I use to download from my Tivo XL4 black and white or colorized westerns to run commercial free, after MCEBuddy, on a WDTV Live via thumbdrive at night if I can’t sleep or wake up.

These are generally small files and crunch quickly on the Win10 laptop. The shows might go weeks before I watch one. I found that sound was fine for the first half then gets out of sync. I tried to troubleshoot it today with a new comskip then went to the 2.4.11 64 bit version and conversions then failed. Since it was happening to all the shows, I just used one to keep testing. I have Spectrum and wondered if since they sell a no commercial westerns channel, they might have made changes to the channel I record. When I went to the 2.4.11, the shows would fail Tivo remux quickly.

So, I tried crunching the show on the XP machine which runs 2.3.15 and I got a converted file that also started sound out of sync half way through.

On the Win10 gaming laptop I renamed my comskip directory comskip.old but of course when it fails Tivo remux it doesn’t get to comskip.

On the Win10 laptop I just entered my Tivo Desktop Plus key but still dies at Tivo remux.

I’m running the stock, paid, comskip files.


On the Win10 machine I went back to an earlier version, 2.4 Beta 1, and I can again get past Tivo Remux and convert the file to mp4 but again there’s a sound sync glitch and it likely happens after a commercial cut. I thought it might be due to having temp directories on the D: drive instead of the solid state element but moving it to C: didn’t help. Trying another tivo file now.

Can you attach the log file from both conversions, the old 2.3.15 and newer 2.4.11. There shouldn’t be any difference in the tivo remuxing part if the configuration is the same. Are you using TiVO desktop (fast) or slow transfers (KMTTG)? It’s not related to comskip but rather stitching the file back together there the older version sometimes went out of sync which was addressed in the newer releases.

Been at this for hours and made changes so the log files might be confusing.

After going back to an earlier MCEBuddy on the Win10 machine I could again get conversions. There was essentially no difference between this and the conversion on the XP machine having 2.3.15. Both have sound sync issues.

On the Win10 machine I’ve been trying different conversions without commercial removal. I tried AVI unprocessed and got a good sync at the start of a western, I go for those made before 1955, but jumping to the end there was a sync loss.

I just tried AVI Mpeg2 no commercial cut, same Roy Rogers flick. Inspection shows the sound is in sync until the first commercial and is out of sync post commercial.

So, there’s something about the commercials, even when ignored, that ruins the sync.

Interestingly, when I started getting westerns, I scheduled recording of all Zane Grey Theatre episodes but found that Charter/Spectrum would list 4 or 5 episodes of various seasons in a row but run glitzy commercials instead, effectively blocking the record of those episodes if aired again.

So, again I think it’s something deliberately done to block commercial removal.


So, a Tivo file western gets fouled sync after the first commercial on either the Xp running 2.3.15 or the Dell G3 running 2.4 beta while the Dell G3 running 2.4.11 fails at remux.

So, this AM I recorded an episode of Death Valley Days using the HDHR on a dedicated line to the XP machine then ran MCEBuddy 2.3.15. I got a perfect video, no commercials and no loss of sound sync.

I note that if I try to copy the HDHR .ts file to a thumbdrive to test its conversion on the Win10 Dell, there’s a pop up saying "/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

I also recorded the show on Tivo. I’ll transfer that to the XP machine and try to move it to the thumbdrive. If there’s no mention of data loss in copying then the problem is perhaps that Tivo doesn’t transfer Timing.Info:$$DATA.


The Silicondust HDHR3 recorded video Death Valley Days .ts file copied to the thumbdrive and then to the Win10 machine was crunched by MCEBuddy 2.4 beta to MP4 Normal. I had no commercial remover checked as that was the last test last night. The resulting MP4 file plays perfectly to the end. So, the Timing.Info:$$DATA that was held back when copying the .ts file from the XP machine isn’t critical to the successful conversion. There would be some other problem with .tivo files.

Copying the .tivo file from the XP machine to the thumbdrive gets no mention of any $$DATA held back.

Starting the conversion on the XP machine same time as on the Win10 machine … XP machine is slower and will take about 3½ minutes (the b&w video is a very small file relatively speaking) … Win10 finished first using 2.4 beta, sync fails toward the end. Checking the XP 2.3.15 finished conversion - the sync also fails in the latter half of the file converted on the XP machine.

So, the SiliconDust HomeRun 3 recorded file converts successfully but the transferred Tivo recorded files to either machine fail to maintain sound sync throughout the video.

I note that Tivo Desktop fast transfer is unchecked.

Trying MCEBuddy 2.5 Beta 1 on the Win10 machine w/.tivo file. MP4 Normal failed at remux. AVI MPeg2 failed at remux. Changed settings to don’t remux. Rebooted the machine, checked no remux was checked, started conversion and this beta ignored the no remux with the result conversion died. Tried AVI Mpeg2 unprocessed and again with no remux checked, the program attempted to remux and the conversion died.

I should mention that I not only use Tivo Desktop slow transfer but I use the MCEBuddy.ServiceCMD.exe exclusively and have the MCEBuddy Windows Service disabled. I’ll try a Tivo fast transfer.

Win10 machine, Dell G3 laptop, Tivo Desktop transfer of the Death Valley Days episode using Tivo fast transfer (from an XL4), MCEBuddy 2.5 Beta 1 (18 July 2019), MCEBuddy 2.x CommandLine Service, Convert to MP4 with do not remux checked, conversion failed post a remux attempt. Maybe modern Tivo devices send a different file?

Getting a clean recording on the XP machine with the line to the SiliconDust took some doing, although the problem might have been in the MCEBuddy data crunching. Initially I had the SiliconDust on the network but things improved when I put in a second NIC exclusively to the SiliconDust. But I was still getting glitches in the finished files. The final best functioning setup was to disable the internet connected NIC before starting to record for the night. Then at the end of the night I’d enable the internet connected NIC and start MCEBuddy. But there was one more thing, before starting recording I’d run my kill.tivo.bat taskkilling the two tivo files, tivotransfer.exe and tivonotify.exe as well as browsers and email programs that might be open. For sure either the tivotranser.exe or tivonotify.exe would periodically do something that would disrupt either the recording or the later MCEBuddy data crunching. The effect by the tivo files was to make the SiliconDust less effective or to prevent MCEBuddy from getting a clean read on what was program and what was commercials.

Tried something different on the Dell G3 gaming laptop with Win10. After uninstalling the MCEBuddy 2.5 Beta 1 64 bit, I installed the latest stable 32 bit version, 2.4.11. I tried a recently recorded movie transferred from Tivo. Right now it’s gotten well into Remuxing TiVO file… Never got this far before. When I tried this movie with the 64 bit I got a “system.badimageformatexception” in the log so I searched that. From “Usually this is related to the difference in 64bit and 32bit DLL builds and processes.”

Failed after remux. From the log: “Unsupported codec with id 0 for input stream 2”. Stream #0:0 Video mpeg2video; Stream #0:1 Audio ac3; Stream #0:2 Unknown:none This was with Tivo Desktop fast transfer. Will try with slow transfer…

Remux…Advertisement scan… working…fails. Note: Ignore copy protection has never been checked.

Found where I made a mistake. Going to the 32 bit goes to the 32 bit program files MCEBuddy2x and although I changed the whereabouts of the comskip.ini, I failed to change the whereabouts of the comskip.exe file. Will rerun some tests.

Changed to shows from movies and tried a Death Valley Days Tivo recording again. Almost worked. Got to 14 minutes of the 22 minute show before losing sync. But I didn’t leave the computer completely undisturbed during the process. Will try a movie again.

I just PM’d you and will look into this.

1 Like

32 bit stable, slow transfer, movie Revolver.tivo, remuxing, analyzing, comskip working, cutting…merging…analyzing…converting…(12minutes44seconds expected)…finished. Checking. Sync good at 57 minutes 1:41 pretty much, slightly off at 1:19, and still off slightly at end. Perhaps it’s a memory size problem and that the drive is a hybrid not a full ssd.

Changed to shows/other and shows. Started a Zane Grey b&w .tivo. Sync off a bit toward the end.

Trying 3 Death Valley Days videos from SilconDust HDHR3. I note that when I record with HDHR3, if there are more than a single episode on that day or night, all show as having the series, episode and name of the first recording of that show that night. At time it won’t even do that but only give the date and time of the recording. All recorded/converted perfectly.

Now going back to Beta 1 64 bit and re-downloading fast in an attempt to get the failure that showed up earlier today.

Running 2.5 beta 1, Revolver.tivo, fast transfer, failed. Have duplicated the System.BadImageFormatException and sending the log to Goose.

The BadImageFormatException with the 64bit build of MCEBuddy for TiVO remuxing has been fixed in today’s 2.5.1 BETA build. It was an issue introduced in the 2.4.9 64 bit build during an optimization change.

Thank you Goose.

1 Like

Very nice. Thanks.