wmp-hc, cpu 100%

[BoseRoHS]

Phil, I have a trail cam that I am attempting to capture images from a video file. I'm using mpc-hc64 to view the captured information. I currently have mpc-hc64 to make small increments of "Frame-step" with the left and right keyboard arrows and F5 for quick capture of that frame. So, when I find a set of frames I'll spam the left arrow and F5 to capture them and I have no issues with CPU load. However, when I set up xmouse to minimize fatigue and automate the process the CPU spikes to 100% even when I have a wait set to 1 second per frame capture and that is slower than me spamming the keyboard manually. I'll also experience input delay after pressing the mouse button 5 10-20+ times in a row.

Mouse button 5
simulated keys
{LEFT}{WAITMS:1000}{F5}


2.19.2:
portable
Windows 19045.2311:

[phil]

Can I ask, which process is taking the CPU (check on the details tab in task manager which shows CPU usage by process).
I wouldn't expect XMBC to take anywhere near 100% CPU, if anything, I'd expect no more that a 1% or 2% increase in XMBC's CPU usage when sending the simulated keys (its not exactly a complicated thing to do!)

What spec is your machine (how many CPU cores) because again, I wouldn't expect anything except the most taxing, multi threaded applications to reach near 100% on a modern multi core CPU! (Generally, if it hit 25% on a 4 core CPU would be 100% of a single core (although its never quite that simple in reality))

[BoseRoHS]

wmp-hc64 is at 60-70% when using xmbc. xmbc is around 6-12% when using the simulated keys.

it's an i5-6200, but that's the beside the point. I can take more frame captures manually maybe 10-15 in a second and there is no load on the CPU other than the normal wmp-hc operation of around 20% vs using xmbc which seems to spike wmp-hc to 60-70%.

[BoseRoHS]

Another thing to note is that xmbc does not activate the simulated keys unless the mouse cursor is within the wmp-hc rendering window, if it's off to the bottom of the wmp-hc control panel or seek bar it does nothing. I wonder if the issue is wmp-hc favoring the keyboard and the mouse input is buggy.

[phil]

OK I have no idea why wmp-hc64 would be using higher CPU when receiving keys from XMBC compared to receiving keys from the keyboard....
XMBC just uses the Windows API "SendInput" to stuff the keys into the keyboard buffer which then get routed by windows (just like any key pressed on the keyboard) to the focused window. So it should make no difference as to the source of those keyboard messages!

But its clear that if XMBC is only using 6-12% then the issue must be in wmp-hc64 itself - and I'm not sure what I can do / suggest to make things any different as I am unfamiliar with how that works. Maybe that's a question for the wmp-hc64 developers?!

As for the mouse needing to be over, have you setup a specific profile in XMBC for wmp-hc64 or are you using the default XMBC profile? If you have a profile for wmp-hc64 and have the setting "enable profile switching on mouse move" (which is on by default) then XMBC will only enable the wmp-hc64 profile when the cursor is over the window/process. However, if you are just using the default XMBC profile then this is irrelevant and I don't know why it would be important where the mouse cursor is.

I don't expect wmp-hc favoring keyboard will make no difference because as far as wmp-hc is concerned, it should be receiving keyboard input (all be it simulated rather than physical).

EDIT: I'll have to have a play and see if I can recreate the problem here... cant do that right now but will try and get to it soon!

[BoseRoHS]

Okay. Let me know what you find out. I'll check with the wmp-hc

[Dolmatov]

Code: Select all

wmp-hc

There's no such thing. MPC-HC as mentioned earlier.

I checked on MPC-BE and found no issues. Try changing the player. This is another development branch of the MPC player.

You may have installed additional software (madvr, lav, etc.) or changed similar settings. This may create additional load or affect the processing of information received by the player.