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?
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.
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.)
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.
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?