This project has moved and is read-only. For the latest updates, please go here.

Quick Sync Driver Issue

Jan 6, 2015 at 1:49 PM
I have a i7 with quick sync and a Nvidia GTX670. I followed the guide at When I load the 3379 drivers my computer reboot and will not work at all off my Nvidia card and the intel gpu boots to 800x600.

The latest drivers from intel work fine except I am pretty sure they are unstable for quick sync because I get the issues in the file below:
Jan 6, 2015 at 1:53 PM
Is there a way for me to email you the log file, I even tried to pull a couple of errors out but I am not sure what messages are important or not.

Jan 6, 2015 at 10:12 PM
message me through the codeplex system or drop an email to with the logs. please ensure you're using the latest build.
Jan 6, 2015 at 10:22 PM
Jan 7, 2015 at 1:23 AM
Hmm never seen that one before, I guess Intels' at it's best in creating new issues.

Also check your bios settings, try switching between Intel and Nvidia as your primary card (and try the dummy monitor trick connect to activate the intel card)
There are 2 recommended drivers, try the older 3621 if that works, check out both of them and if neither work then try to use the latest windows update driver (uninstall and selection option to delete the intel driver when uninstalling from device manager, refresh and repeat process until it uses microsoft WHQL driver, then do a windows update).
Jan 9, 2015 at 8:47 PM
Ok, well I've tried a bunch of thing but have not been able to get quick sync to reliable convert videos. It seems like it will get through some but not others. Most of them end in failure and then it reverts back and sometimes still has problems. The problem I'm having now is that it seems to keep trying hardware even though I have made sure it's unchecked.

I only have one conversion profile and felt it was pretty simple setup.

Any thoughts would be great.
Jan 9, 2015 at 9:29 PM
I checked your logs, handbrake is using the software encoder:
2015-01-09T03:43:31 MCEBuddy.AppWrapper.Handbrake --> [03:43:31] + encoder: H.264 (libx264)
I know you're seeing the hanging error message which actually just indicates that handbrake has hung and is incorrect. We've never seen handbrake hang so this is new for us. Can you upload the original video to our server to analyze and replicate.
Jan 12, 2015 at 12:43 PM
I finally got a zip file of the video that I used uploaded.

Jan 13, 2015 at 8:14 PM
Thanks checked it out, interestingly it ran with hardware encoding enabled without and the driver version: without any issues.
Rerunning with software encoder.
Jan 13, 2015 at 9:26 PM
Are there any issues with the monitor being turned off during a run? I know that windows will try to change resolutions / change primary monitors if you just hit the power button. The computer that is doing my encoding is also my media pc. It's a decent core i7-3770K with good ram but the monitor is my 55" sony tv. When I walk away from watching tv, I end up turning off the tv.
Jan 14, 2015 at 1:28 AM
Okay the software encoding also passed without event. Here's what I think is going on. You computer may have been overloaded the CPU was being dedicated to something else instead of MCEBuddy which caused the progress to be very slow. MCEbuddy have a timeout of 5 minutes to see if there's any progress. If there's no progress it assumes it hung.
2 things:
  1. You can change the timeout in the system settings from 300 to a higher number or 0 to disbale detection (not advisable). This can counter any overloading you may have
  2. We'll look to optimize the conditions for the hang also.
Regarding the monitor, I would like to say no but I can't, if the monitor is turned off the device driver would come to know and if it does something to adjust for it, it may end up interfering with the encoding (can't say, reduce GPU power etc etc). You can just try it see what happens with monitor on/off. Alternative to off you may want to do a blank screen saver without a timeout.

thanks for reporting this.
Jan 14, 2015 at 2:12 AM
Try the new 2.4.2 build and it should now only detect no progress when using hardware encoding that way software can continue taking all the time it needs.
Marked as answer by rboy1 on 1/13/2015 at 6:12 PM
Jan 14, 2015 at 2:15 AM
And I actually missed this in your logs, we were right about the time being spent elsewhere leaving handbrake with little encoding time which led to no progress and MCEBuddy erroneously thinking it was a hang (which is now fixed, thanks).
I just saw this
Process Priority -> Low
You had it set to low priority, which in MCEBuddy terms is actually IDLE priority which is the lowest system priority, it gives way to anything you're doing on the computer even moving a mouse or browsing. So thanks - another one hits the dust!
Jan 15, 2015 at 9:23 PM
Is the new 2.4.2 build actually different than the 2.4.2 build that I am currently using? What is a "normal" priority level. I don't mind running with higher priority.

Thank you for all the help.
Jan 15, 2015 at 10:01 PM
Yes each build has a change log with it specifying the big fixes. You can update to the new build as it will fix your issues

Jan 15, 2015 at 10:39 PM
I downloaded / installed the latest 2.4.2. Set the priority to normal. I'm making a run right now with hardware encoding on and will make a run with hardware encoding off. I have 3621 installed.

With encoding turned on and using QSV Library I am getting around 12fps and 100% cpu load. I'm guessing that it's not using hardware encoding. Will upload the log when it's done.

Jan 16, 2015 at 1:45 PM
I've included to conversion logs.

The earlier one at around 1643 was an attempt at hardware that failed at 100% then switched to software. The second attempt was at 2009 and was the same but I changed the profile to mp4 fast. I made sure that nothing else was running while I did both of these conversions .

The 1643 attempt was also using 100% cpu and going at 10fps during the hardware attempt. The second 2009 attempt was doing 30fps and only 50ish cpu.

I was wondering if this had to do to with the decombing that I saw in other threads. I have noticed a large quality difference between the two files and would like to close the quality gap. Would MP4 Normal be better? I also only have an Ivy-Bridge cpu so my QSV is going to be limited to what is in the hardware.
Jan 17, 2015 at 1:23 AM
It's slower that usual because you're using a very high bitrate 6000 (quality) and at full resolution 1080p.
Lower it to 720 and standard 800kbps, it'll speed up. Trade off quality vs speed.

Jan 17, 2015 at 2:52 AM
Ok, will give that a try.

Sorry to take up so much of your time and thank you for helping.

I have one tv show Parenthood that keeps converting the wrong audio track and not sure how to get it to use the correct one. It's using a commentary track.

Also now my recordings all skip around, the video and audio will play find then video will stop while the audio jumps backwards by 30 seconds. It will catch up and then both will play and then repeat that same process.

I've been doing my conversions with nothing else left. I thought my settings were pretty basic. I'd be interested in just using mcebuddy to run my donor comskip on a wtv file and move the file to a storage folder to be used as a pvr versus archive in mp4.
Jan 17, 2015 at 4:07 AM
Please start a new thread of new issues. This was also recently answered for another user.