• I have noticed that when i run SecuritySpy that it uses more resources than Firefox (which is a memory hog) and if i have anything else running the fan kicks in on high.

    I am wondering if something is awry.
  • For me it only uses about 300 MB of ram and about 30% of one CPU (across 2-3 processes - SecuritySpy, and VTDecoderXPCService)

    In another thread Ben linked this about Optimising Performance:
    to which the only thing I could add, is double-check the "Setup" tab of camera configuration, and if any transformations, or text overlays are used, turn them off in Security Spy, and do them on the camera itself. (This means the camera does the work, not the computer)
  • Iam pretty much bare bones here. I think it is the program. However... with Sierra coming out next week and its promise of being able to make the OSX work better, maybe something positive will happen.

    The machine I have is an iMac Retina 4K, one of those self contained, sealed up tighter than Tupperware, machine. No option of adding more memory. 8G of Ram. Maybe the next computer, I can get one with a boat load of memory and this won't be an issue.

    Seems the CPU runs hot, but I have fans on the back of the unit adding cooling.

    Lets see what happens after the upgrade
  • of course Security Spy also does use extra GPU resources (GPU is more efficient than CPU at doing video work) - so that could be pushing the CPU temp up on your iMac (which is integrated video to the main CPU) causing the fans to speed up.

    If you aren't familiar with Activity Monitor (in the Utility folder) it will show things like CPU, Memory - which can be sorted to show the most demanding in each area - Energy hopefully includes GPU usage as well - that might give the biggest clue to what is actually using the most system resources - in my case Security Spy (in Energy this automatically includes the sub processes of VTDecoder) uses about "30" on average. - for me Chrome averages about 3-4 times as much Energy Impact, everything else uses much less.

    There likely won't be much of a change from Sierra (10.12) in this regard - certain things take certain amounts of processing which generates heat.
    In the case of your iMac, it isn't how its sealed that is the issue with not adding more ram, it's apple's tendency of late to Solder the ram to the mainboard - it isn't in sockets like they used to use - only the Mac Pro and iMac 27" have sockets now, all others are soldered ram.

    If your fan speeds fluctuate (it goes faster up for a little bit, then slows down - and repeats) then there is other software out there that can set a higher minimum speed for the fans so the CPU stays cooler (it can still go faster if it needs to, but just has a higher minimum) I use one on my Mac mini 2012 quad i7 - a 3300 rpm minimum speed works for most of the general use I do - the iMac would need a different minimum - the internals are completely different from the Mac mini I have. If the fan speeds are relatively constant, then don't worry about it.
  • Please address this issue. I am on a clean install of 10.12 and up to date with Security Spy 4.0.8 but just now did the 4.0.10 update. As of earlier today VTDecoderXPCService was using 650% of my CPU. I am on a QuadCore i7 Mac mini with 16 GB of RAM and a 575 GB Crucial SSD. The longer Security Spy is open, the higher the CPU climbs. I can force quit VTDecoder and the CPU usage drops to 15% and Security Spy is unaffected. If Security Spy runs overnight my CPU will be at 200+%. If it runs for several days it will be at 600%. Here is a screen shot... Shot 2016-12-07 at 12.15.37 PM.png?dl=0

    This issue started immediately after upgrading to Security Spy 4. SP3 ran at about 60% on one CPU. This software has become unusable for long term monitoring. My only recourse right now is to write a script to kill VTDecoder every 12 hours. PLEASE address this issue!!

  • Hi @joesim this is not a known issue, but what you are experiencing does sound rather strange. Basically SecuritySpy sends compressed frames to Apple's VideoToolbox library to decode, which then hands decompressed frames back to SecuritySpy. The actual decompression task takes place wholly in Apple's VideoToolbox code, which is responsible for the VTDecoderXPCService task. If there is a problem with this task, it's unfortunately going to be difficult to debug and fix, because this is Apple's code and not our own. However maybe there is some workaround we can find, if indeed there is a problem.

    So that I can roughly tell what is a reasonable amount of CPU usage required for the decoding task, could you tell me how many cameras you are using, at what frame rate and resolution? Are they all supplying H.264 video to SecuritySpy, or are some cameras supplying JPEG or MPEG-4 format video?
  • I am having the same issue, the longer the App is open the higher the CPU goes on the VTDecoderXPCService. A few days ago it was over 1,100%, I restarted SecuritySpy it started out at 25% or so and after a day or or so it's climbed up to 555.7%.

    My Mac is as follows,

    Mac Pro Mid 2010
    1 Processor @ 3.46Ghz Xeon with 6 cores, 12 threads
    16GB DDR3 1333Mhz ECC Ram
    macOS 10.12.1 Server
    AMD RX 480 8GB driving a Dell P2715Q 4k display
    Genuine Apple Radeon HD 5770 1GB Driving a Dell E2414H Full HD display
    14.5TB of active storage
    Boot drive 500GB Crucial SSD (CT500BX100SSD1)
    SecuritySpy Storage - Was the boot drive during this prop, but now swapped over to a 1TB partition in one of my ST3000DM001-1CH166 drives.

    FYI, I currently have 5 cameras active with FPS set to 8fps max!
  • Please both of you download and install the latest beta version of SecuritySpy (currently 4.0.11b5) and let me know how it performs over a day or so. This version will reset the decompression sequences every 10 minutes, thereby hopefully avoiding this problem (though it's difficult for us to test as we can't reproduce the issue).
  • Hello everyone,

    So here is my setup. I have 6 cameras. All HikVision DS-2CD2432F-IW. They are all set to a 10 FPS max capture rate on camera. Here are the video stream specs...

    Variable Bitrate
    Quality High
    10 FPS Max capture
    2 Mbps H.264 Main Profile
    I Frame every 10 frames

    They are all connected via Wifi via 2 different WAPs on opposite sides of my building.

    Common network throughput to me is about 300 to 500 KBps for all 6 camera's streams combined.

    I will say that I installed the 4.0.10 yesterday as I was once again troubleshooting this issue and it has seemed to stabilize for me over the past 24 hours. VTDecoder is so far remaining low at only about 20% CPU usage. This has happened before where it seems fixed and low for a couple days then goes sky high again. But so far so good. I will certainly download the beta in a couple days if it spikes again. I just don't have time to spend on it right now today, and... so far so good for me. So, if it ain't broke, don't fix it, as they say.

    Thanks for the response!!
  • So the 4.0.10 update did not fully resolve my issue. It is MUCH better. VTDecoder still spikes up to 200% CPU usage regularly but then seems to recover. It runs as low as 40% for hours and hours, but trickles up to 100% with occasional spikes to or slightly above 200% over the past 48 hours of testing. The real test will be when I am out of the office for 4 days now. Last weekend it ramped up to above 700%.

    Is it possible the increase in CPU usage has something to do with me turning off my monitor? Could this somehow disable some sort of GPU acceleration causing the CPU to take over?

    As I said, 4.0.10 is much much better. I will try the 11beta next week if I get a high CPU spike again.

    That's my 2ยข.

  • Hi Joe,

    Thanks for the feedback. it would be useful if you could try the beta version linked to above, hopefully it will be even better than 4.0.10.

    Turning off or unplugging the monitor may have an effect here. The hardware-acceleration video processing is done in the graphics hardware (the GPU), so if this gets turned off then it will have a big impact on the CPU usage of the decoding process. Instead of turning off the monitor, I suggest you set a short "Display sleep" time in the Energy Saver system preference, and simply let your monitor sleep automatically after a few minutes. It would be interesting to hear back from you if this change results in a reduction of the CPU usage or not.
  • I am trying out 4.0.11b7, it has started out at around 45% CPU, so let's see how it goes.

    BTW This morning before trying out this beta version I was over 1,000% CPU
  • OK, have been running 4.0.11b7 for a number of days now, and my CPU usage tonight is at 1,152.9% !
  • For reference, my next highest CPU usage app is MenuMeterAPP @ about 13%
  • Hi @MacAssemble when this happens, can you tell me what the "Idle" percentage reads, this is toward the lower left corner of the Activity Monitor window (it represents the amount of spare CPU capacity for the whole Mac, normalised to 100%)? What does this say under normal conditions (soon after restarting SecuritySpy)?

    There's a new beta version available so please continue your testing with this new one.
  • Well this morning I went to check Activity Monitor but it just kept hanging without fully launching, this was the case for a few programs so I quit SecuritySpy and all is well again. SecuritySpy must have been using a LOT of resources to stall out 6-cores @ 12-threads! At any rate, now that I quit SecuritySpy my idle CPU is hovering around 98%-99%. I just installed 4.0.11b10 and will give it a try. I can tell you that it's currently using around 50%-51% CPU with idle around 93%-94%.
  • OK, checked in today, but I had trouble launching any new apps until I force quit SecuritySpy. I was able to coax Activity Monitor to open after the second try with a force quit in between but it was unresponsive and would not display CPU% for ANYTHING. I tried to launch terminal to check from there but it was also hanging. Everything INSTANTLY came to life the second I force quit SecuritySpy 4.0.11b10
  • Installed 4.0.11b11 today, will report back.
  • I'm running 4 IP cameras over Wifi on an older MacBook Pro and I have no issues.
    I run the latest SecuritySpy software and on the Apple I run latest update of Yosemite.

    Note that the frame rate will make a BIG difference and I run 10 fps and 640 resolution on three and 1 camera on 720P.

  • Today VTDecoderXPCService was up to 1,146% CPU usage and idle was just blank aka no idle... Just quit SecuritySpy and now idle is hovering around 96%-99%. Fresh re-launch of SecuritySpy and Idle is stable at 90%-94% and VTDecoderXPCService is around 46% to 50%. This of course running 4.0.11b11
  • 2 Cameras @ 2fps
    1 Camera @ 4fps
    3 Cameras @ 8fps
  • Hello everyone,
    I have been doing further testing on my system still using 4.0.10 and may have found something that is at least a correlation if not a causation. I noticed that during the day as I am using my system SecuritySpy (and by extension VTDecoder) sits at relatively low CPU usage, but on days when I have been out of the office the CPU usage spikes. I had set my displays to never sleep BUT I had not turned off the Screen Saver. So I disabled the Screen Saver and since then the CPU usage has been very low for me. Weeks worth of use with it rarely exceeding 150% CPU. Nothing else has drastically changed on my system. I have done all updates to macOS up to 10.12.2 but even before the latest updates the CPU usage had remained very low.

    So anyway, not sure this will help anyone else, but at least for me the issue has nearly stopped altogether.

    @MacAssemble, I see your frame rates are very low. I had my camera frame rates set very low in the past and noticed it actually made SecuritySpy (v3 at that point) very unstable. I was always dropping connections to my camera and SecuritySpy would crash. I increased my frame rate to 10 fps and those issues largely went away and it didn't really increase overall bandwidth on my network. Purely anecdotal, but again it worked for me, but that could be related to my camera hardware not SecuritySpy itself.

    Thanks all! Good luck!

  • I added one of the NewerTech headless video accelerators to my Mac Mini ("Late 2012", OS 10.11.5, 2.6 GHz i7, 4GB RAM) after reading another thread here and have not had the issue recur for about 4 days. Not sure why it cropped up - I had been running SS4 for weeks if not months and hadn't touched the Mac, but this seems to have fixed it for me. Screen Sharing performance it much improved too.

  • I experienced excessive CPU usage on my new Mac Mini, 16GB. Seems to be related to Quicktime. I have 1 Foscam, 1 Amcrest and 2 Wanscam cameras. After disabling the Foscam in Security Spy, I have not had an excessive CPU usage issue. I read somewhere on the internet that the excessive CPU usage may be caused by the Quicktime interface with the camera, a corrupt mp4 file may be the culprit. The Foscam is farthest from my router and has more concrete walls to penetrate therefore the signal is weakest. SS complains a lot about that connection or something of that nature. I think SS/Quicktime has issues with fragmented files as the RF signal drops in and out. The Foscam is the only camera I have that has a Quicktime interface. Three VTdecoder services are running now, each at 0%. The services seem to start randomly perhaps by processes other than SS. I can touch the top of my Mac Mini and tell if a VTdecoder is running wild (it will be warm).

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!