Update from 2.4.11 to MCEBuddy 2.5.2 SLOW!

Today I upgraded from MCEBuddy 2.4.11 to 2.5.2 by uninstalling the old version and then installing the new version. It is my understanding that settings are retained. I am using the MKV normal profile for conversion. I found that v2.5.2 processes at 0.1x the speed of v2.4.11. I tried with hardware encoding enabled and disabled and the results are identical. Are there other settings I can try to get back to the old performance?

I have attached log files from the both versions.

Thank you for the help.

log_2411.log (645.7 KB)

logo! Die Welt und ich 2020_01_11_13_50_00 - logo! Die Welt und ich.ts-Convert to MKV-2020-01-11T14-05-02.6534887-05-00.log (2.0 MB)

Thanks for the logs, very helpful.

With the 2.5.x release the hardware encoder support has been expanded and it looks like the hardware encoder settings wasn’t enabled after the upgrade.

Prefer Hardware Encoding → False

Enable that option in your Conversion task → Expert Settings page and it should start using your QuickSync encoder.

The hardware encoding was initially turned on but the speed was just as slow, I got ~13 fps on average. I then turned it off to see if software encoding was faster. It was not as the log I sent shows. For now I reverted to 2.4.11.

If you can attach a log with the hardware encoding option enabled I can then compare your 2.4.11 log to that one and see what’s going on.

I am about to go on business travel and need to defer until next weekend. My apology.

We’ve made some enhancements to the latest 2.5.3 BETA build to improve hardware encoding speeds. Also turn on hardware encoding in your conversion task.

I apologize that it took me a while to get back to this. Unfortunately, this issue has not been fixed for me using v2.5.3. I first tried with the Hardware Encode setting set to “any”. In this case, i get a lot of QSV decoding errors and the encoding eventually fails with

Blockquote ERROR> 2020-04-12T09:39:54 MCEBuddy.AppWrapper.Handbrake → Hardware encoding appears to have hung, no progress in the last 300 seconds.
This is likely due to an unstable Graphics Display Driver. Try updating or using a stable Graphics Display Driver.
Terminating process.

Unfortunately, I cannot update the video driver, as I am already using the latest version available for my motherboard. I then disabled hardware encoding and conversion times for a 30 minute show went up to 2.5 hours again. So I reverted again to v2.4.11, which is much faster (but I have issues with corruption of video files when commercials are cut.)

I have log files but they are too large and upload feature refuses them. I tried pastebin but files too large for free account, so I give up. Please provide an email address for sending these.

Thank you for helping.

Here is the log file for hardware encoding disabled. This one is short enough to be accepted. Again the encode time for 30 min show is 2.5 hours, which is unacceptable and 10x longer than 2.4.11 need.

HardwareEncode_Disabled.log (1.7 MB)

Here is a link to the log with hardware endocing ENABLED.

Reverting to 2.4.11 did not work, I suspect the settings are now incompatible. How do I completely remove MCEBuddy including the settings please?

So I tried the 2.5.3 release again with a different show and I seemed to have had more luck with this even with hardware encoding enabled on my old but final video driver. So I am wondering if the recording I used for testing yesterday was somehow corrupted. I will monitor the situation but if I can get feedback on any issues seen in the source file from above log files, please let me know. Thank you.

If it works with hardware encoding disabled and doesn’t with hardware encoding enabled then it’s your graphics drivers → As mentioned before latest is not always the most stable

I understand what you are writing. The problem I am having is that the latest driver for my SANDY BRIDGE processor is v15.28.24.64.4229 (9.17.10.4229). This is older than any of the drivers listed in the FAQ you linked. Per the Intel website, the drivers listed in the FAQ post will not work with my processor. Is this information not correct?