Skip to content

VTDecoderXPCService CPU usage

24

Comments

  • Hi BrianM
    I give up. You are right, I have now had time to test SMC and slowly moved it back to 3000revs, and it has made no negative difference whatsoever.
    I have no idea what has suddenly changed now.

    I am now back to running everything as I was yesterday, yet the system has 90% idle, and no strain on the system at all.
    I am lost tbh.

    With the powercut, I had the system off for a few hours due to that which I never do. In fact I hardly ever restart the system, so unless something new has happened due to that power down, I am now at a total loss. But a happy one nonetheless :)

    Any ideas?






  • Hi BrianM
    Me again
    Ignore last message. I am definitely seeing a relationship between SMC and the cpu usage.
    I turned down to 3000 revs as last reported, and within 1hr the VTD was back to 300%+ and kernel was 200%+.
    I then took the fan up to 4000 revs and the VTD dropped back to 45%, and kernel dropped to 10%
    The fan was at 67°

    I can't tell you why, but I observed a definite connection.
    I am now at 4000revs on SMC, 67°, the idle on system is a fantastic 87%.
  • I have now removed smcfancontrol from my system, and I am constantly at 90% idle.
    Fan is louder, and running at an average of 5000 revs, temp approx 69°, but cpu usage is very low.

    I cannot explain it, but I don't care tbh, my system is perfect, I can use my Mac once again as if it was new, and yet I still run 6x 2mp cameras on full record on SS in the background.
  • Hmm, restarted Security Spy and watched the CPU go from 50% idle to 2% idle (majority of CPU burnt by VTD). Installed SMC and set to maximum fan speed, CPU temperature dropped from 90 to mid 80s. Idle was sitting around 3%.

    Exited SS, system dropped to 99% idle and CPU temp dropped to 44 (machine is sitting on top of an external cooling fan as well as the system fan). As soon as I started SS, CPU temp went up to 55, idle dropped to 50% and VTD consuming 200% CPU with 25 threads. Also turned screen brightness to minimum. Temperature seems to be stable at 70, CPU at 45-50% and VTD seems to be stable with 26 threads and 150% CPU!

    I'll have to keep monitoring to see if it slowly climbs through the day.
  • Spoke too soon. CPU usage has slowly climbed, but is currently stable at around 3-5% idle. CPU temp is at 90 and there are 41 VTD threads (25 on start up, slowly climbed over the last 50 minutes, but relatively stable now) and VTD is consuming 360% of CPU.
  • I've used gfxCardStatus to force either "internal" or "discrete" and things seem a lot more stable, when forced to use the "internal" GPU. Sitting at around 45% idle, temperature sitting around 70 and threads count for VTD isn't deviating from 25. It will take a couple of hours to verify, but looking good so far.
  • I'm having the same issue VTD is running 12 threads and % CPU >300. CPU Temp was well over 200 Deg F. I have a headless Macmini 6,2 i7 quad core w/16Gb of RAM. The fan is maxed out at 5500 rpm most of the time and only 40-50 % idle CPU

    I shutdown one of my six cameras. Somewhere I saw somebody added an OWC headless adapter, not sure why that'd have a thing to do with it, but I added it anyway. Today with 5 cameras and the adapter I'm running ~170 Deg F, still with 12 VDT threads, but % CPU is down to 80 (from 300), and the CPU is 75% idle. My fan is still maxed out to keep it that low [I use TG Pro fan control] Very weird, still at the high end of where I'd like to be given that SS is the ONLY APP running other than Plex & TimeMachine Server.
  • MikeM: what resolution are those cameras?
    The headless "adapter" makes the Mac think that a display is connected so the OS loads the drivers for the GPU (even integrated GPU still helps) - Security Spy can then use the GPU for one camera stream reducing CPU load. (also helps with Remote Desktop responsiveness)
    I find it interesting there are 12 VTD threads... and ChrisCam mentions 41. I have 1 VTD thread for my 4 H.264 cameras - uses about 20-23% of one CPU core. (my SD cameras use JPEG video instead of H.264)
    Are all of those VTD threads active? or are many showing 0% or 100% CPU? (could be crashed threads)
  • I know these are basics, but sometimes it turns out something basic is overlooked because we assume the basics were already correct. I just recently participated in a high pressure air compressor troubleshooting thread where we chased down all sorts of possible, complex issues only to discover the owner had not connect the end of the output hose to his tank. Super basic error, but we all assumed no one would have made so basic an omission.

    Let's make sure you have lightened Security Spy's work load.

    1. Is videodecode only when necessary selected in Security Spy preferences? It should be.

    2. For each camera's motion and continuous capture frame rate settings in SS exactly the same as the camera is delivering?

    3. Are you avoiding addition of any titling by SS? All titling and time marking in the videos should be done by the cameras, not SS.
  • Hi
    Removed the back off my Mac mini, now running 1800revs and not 5500revs, 90% cpu free, and my VT usage has dropped from 300%+ to 40%!

  • edited June 2017
    Wow. That was a LOT of thermal throttling. Maybe it is time to redo the CPU's thermal paste? I do that on my Mac laptops after about 4-5 years. By then, the factory paste is pretty badly dried up. Best to enlist a overclocking, geek friend if you have not previously done thermal compound application.
  • I've switched on continuous recording (5 minute blocks) and switched off motion detection. SS still starts off consuming 5 VTD threads per camera (each camera is encoding at 6FPS), I confirmed this by switching off one camera in SS and the thread count dropped by 5. Over the course of 12 hours the thread count has increased from 25 to 31 and the idle CPU from 42 to 24%. Switching the web server on and off doesn't impact the thread count at all.

    As far as I can tell, I've switched off every option that may require SS to decode video (and trigger VTD).

    I'm surprised that VTD is still being invoked when SS isn't doing any decoding or encoding (no cameras are being displayed).
  • One correction to make. Even though motion capture was switched off for each camera, I also turned off the Motion trigger "Video motion detection" each camera's setup screen and the VTD thread count dropped by one for each active camera (from 25 to 20). Not sure why this was consuming a thread when motion capture was already switched off!
  • Tried to edit my previous comment, but couldn't. Opening a window to display all cameras increased the thread count by 5 and the thread count didn't go down again when I closed the window (but CPU load did).
  • I'm running a Mac mini 2014 with 8 GB. 6 cameras, 5 of which are Foscam, 1 is D-Link.
    The Foscams running H264 require 75 KB/s each at 1280x760.
    The D-link running JPEG requires about 10x the bandwidth at 750 KB/s, 640 x 360.
    The VTDecoderXPCService uses 10 threads and 10% of the CPU.
    Generally CPU utilization is 75% idle.
    I gait on motion and send PNGs to email and record 10s movies.
    Performance is great. This thing actually paid for itself earlier this month.
  • edited June 2017
    On my Mac Mini (Core i5/ 2.5 Mid-2011), I have 4 wireless Sharx Security SCNC cameras. CPU is 40-50% idle, but VTDecoderXPCService uses 17 threads and 110-120% of the CPU. Also, when SecuritySpy is running, it takes 20-30 seconds to Remote Desktop to the Mac mini on my subnet. When SecuritySpy is closed, that connection is near-instantaneous. Something is not right.

    For further consideration - The cameras periodically throw SecuritySpy 22185,-8969 errors, yet are BULLETPROOF when connected to MobiLincCam. Doesn't it sound like a SecuritySpy/ Sierra 10.12.5 bug?
  • Restarted the system on 22 June, after making sure that every reference to motion detection was off (video motion detection is not selected in camera setup and motion detection is not enabled in motion detection). Continuous recording was set on, with 5 minute recording blocks.

    Since then everything has been stable with around 53% idle CPU. VTD is consuming 21 threads. If I use the app to view the cameras, the CPU idle drops around 10% and an additional 5 threads are consumed by VTD, but this goes away when I close the app.

    Looks like something to do with motion detection.
  • BUSTED (maybe)! Since my last post about two hours ago, I just attempted to connect to the Mac mini with Apple Remote Desktop. Lethargic 20-30 second connection, but when the desktop appeared, I had Activity Monitor at the front. VTDecoderXPCService was using zero CPU and zero threads. All cameras were disconnected, but started reconnecting just as the desktop appeared, and VTDecoderXPCService immediately returned to the 17-thread, 110% CPU usage I typically see.

    It appears something SecuritySpy does is crashing or overloading VTDecoderXPCService. Maybe motion detection like mentioned earlier. Unfortunately for me SecuritySpy is useless with out that feature.
  • s6275, just to be sure the basics are covered, you DO have a video dongle attached to the Mac Mini, right? Without something to force the video driver load, screen sharing will be extra sluggish getting started. I know there may also be an odd VTDecoderXPCService issue, but the video dongle is a required element for any headless MacMini

    Repsolkid's report makes the VTDecoderXPCService issue sound like a thermal overload causing CPU throttling and subsequent failed video decoding threads due to the CPU running too slow. Would be great if we had another user test if removing the back of the MacMini and doing additional cooling makes a difference.
  • edited June 2017
    Video dongle attached.

    Noticing today that some of my preferences appear to have been reset (?) after a recent update, I returned the frame rate settings on all 4 cameras to something more reasonable than what the gremlins had settled on. I managed to get VTDecoderXPCService into the 50-60% CPU range...but SecuritySpy is still disconnecting from my cameras every 10-20 minutes, with a nudge with Remote Desktop restoring the connections.

    Another component of all this is that at the same time this other business all started, I stopped being able to successfully load H.264 streams in the web interface.
  • edited June 2017
    The continuous and motion capture frame rate settings in Security Spy probably should be exactly the same as the frame rates set in the cameras. Otherwise, there has to be decompression and recompression to change the camera frame rate to the recording frame rate. Has that also been done?

    As I recall, the web browser interface works best if the output stream to the web browser is motion jpeg. That reduces the CPU load for compressing the outgoing video.
  • OK. They are. Connection issues remain in spite of making that correction.
  • By any chance are you recording to a network attached drive instead of a locally attached drive? I've also see some 20-30 second periods of Mac unresponsiveness when a network attached drive was busy. Switched to Thunderbolt connected RAID and no more spinning wait cursors. Just another thought to complete the picture.
  • Thunderbolt drive.
  • Hmmnnn. I might have to see what my Mac Mini does instead of my iMac. The iMac is doing great handling 14 cameras.
  • edited June 2017
    Hi - I have the same problem with resource use (or rather the VTDecoder battering my CPU). This was never a problem on earlier versions, and it has persisted through the last couple of betas and the current app.

    These are my cameras:
    https://www.dropbox.com/s/a5dumffxkdwt7zf/cams.png?dl=0

    The spec of the machine (which is only used to run SSpy, with a GPU-enable dongle):
    https://www.dropbox.com/s/pbqzec6j4vsykoe/spec.png?dl=0

    The load / temp of the CPU, showing a couple of SSpy restarts:
    https://www.dropbox.com/s/phdju8kunenxa7f/temps.png?dl=0

    And finally the resource usage:
    https://www.dropbox.com/s/fbidtu972uml0sl/VTdecoder.png?dl=0

    Any way ahead on this would be great. This machine was an appropriate spec for months (I have logs of load and temps to prove) but the off-loading of H.264 decode to the Apple process has seen a dramatic increase in duty cycle / thermal load which is really bad for the hardware.

    Previously a fan setting of 3k RPM constant was enough to keep everything cold. Occasionally it would spike. Now the main fan is pegged and the CPU bounces off 100 degrees!

    Help!

    PS > I am using a SSpy title / timestamp, which I know forces a recompression. I guess you'll suggest turning this off, but for me it's a critical feature.
    PPS > I have matched the frame rates with those set in the camera GUIs.
    PPPS > I am also using an external fan pack to force air over the Mini case to try and improve thermal scavenging. Probably helps a little, but obviously not enough.
  • After installing the latest Security Spy update (with cameras set for continuous recording), the system is now 90% idle and I’m not seeing VCD consuming any CPU, unless I open a window to view cameras! I see that the release notes mentioned something about connection issues with ONVIF cameras being resolved.

    I’ll experiment with turning off continuous and turning on motion detection and see what happens to the CPU load. Some people like the continuous recording and others like the motion detection (easier to figure out when an event was), so I’ll try both and then discuss which to keep active.
  • Interesting.

    My system has been sitting at 90% idle (continuous capture, all motion detection turned off, all cameras set to 10 FPS), with no VTD threads active (21 threads 0% CPU).

    Open a window to view one camera, CPU idle drops to 80%. Open a window to view all 5 cameras, CPU idle drops to 25% and fans kick in.

    Next test will be to turn motion detection on and see what happens.
  • I always have the "All Cameras" window open showing 6 cameras (usually, sometimes 7) and my idle remains at 90% (across all CPU cores) on average with VTDecoder using about 14-18% (of one core) on average with 11 Threads. 2 camera's on continuous 24/7, other camera's sometimes continuous recording on schedule, 2 always motion & action set, others on schedules.

    camguyfbr: do your cameras not have an option to embed the time directly on the camera? (4 of my 6 do)
  • Hi - my idle is around 30%. This looks like a runaway process spawning threads in VTDecoder to me. If I kill the process (even from terminal) it takes several hours to creep back up to maxing out the CPU / thermal throttling with max fans. Brian, I can run an OSD with date/time/name on my cams, but they are Samsung firmware and the labels are like something from a 1980s VCR. Plus the other cams I use (Hikvision) use a different format of OSD. Previously I was fine with the overhead of re-compressing because CPU usage was reasonable for H.264. Now I'm not so sure. I might try disabling all of the recompression and SSpy OSDs to see what difference it makes....
Sign In or Register to comment.