4.0.8 Browser Bugs, App Unresponsive
Since upgrading to Spy 4.x I have found the browser window to be buggy with my DLink and Samsung IP cameras.
Aside from the 4x playing error some other users are having, I also experience videos in the timeline appearing black in the interface (despite the video being present on the file system and in the list and the timecode in the GUI scrolling), and times of recording being represented incorrectly in the list (e.g. 1730 video appears at 1400 on the timeline, for example).
Finally and most frustratingly, Browser always makes SSpy unresponsive after a few segments of video have been reviewed. Console throws the following error. This is only resolved by a force-quit. Any clues?
30/10/2016 23:10:18.970 SecuritySpy[22588]: <<<< VT-DS >>>> VTDecompressionSessionWaitForAsynchronousFrames: WARNING: waited 80 seconds for video decoder to complete asynchronous frames; maybe it is stuck or has a buggy path that does not complete a frame?
30/10/2016 23:12:58.970 SecuritySpy[22588]: <<<< VT-DS >>>> VTDecompressionSessionWaitForAsynchronousFrames: WARNING: waited 160 seconds for video decoder to complete asynchronous frames; maybe it is stuck or has a buggy path that does not complete a frame?
Aside from the 4x playing error some other users are having, I also experience videos in the timeline appearing black in the interface (despite the video being present on the file system and in the list and the timecode in the GUI scrolling), and times of recording being represented incorrectly in the list (e.g. 1730 video appears at 1400 on the timeline, for example).
Finally and most frustratingly, Browser always makes SSpy unresponsive after a few segments of video have been reviewed. Console throws the following error. This is only resolved by a force-quit. Any clues?
30/10/2016 23:10:18.970 SecuritySpy[22588]: <<<< VT-DS >>>> VTDecompressionSessionWaitForAsynchronousFrames: WARNING: waited 80 seconds for video decoder to complete asynchronous frames; maybe it is stuck or has a buggy path that does not complete a frame?
30/10/2016 23:12:58.970 SecuritySpy[22588]: <<<< VT-DS >>>> VTDecompressionSessionWaitForAsynchronousFrames: WARNING: waited 160 seconds for video decoder to complete asynchronous frames; maybe it is stuck or has a buggy path that does not complete a frame?
Comments
-
I am having similar problems. The VTDecoderXPC process ramps up CPU percentage and eventually makes the mini unresponsive. Like camguyfbr, SS won't quit without a fight (force quit). I can't gracefully quit SS even after being up for a few seconds or after disarming all cameras.
Normally my cameras utilize under 10% CPU but after a few hours they have ramped up to well over 50% each. -
Your analysis is much more in depth than mine, I just want it to end.
After further reading I determined that it is in fact the VTDecoderXPCService process. Not wanted to mess with this any further I programmed a schedule in Indigo to kill the process once a day at 23:59. The process starts right up again with no hesitation and it keeps the CPU consumption at bay. If you don't have Indigo you can easily do it with cron or less easy with a launch daemon.
For Indigo I used a simple AppleScript command: do shell script "killall VTDecoderXPCService" -
There are two distinct issues above.
VTDecoderXPCService is a separate process spawned by Apple's video decoding libraries (which SecuritySpy uses), which decompresses the incoming video from the cameras. Depending on your cameras' resolution and frame rates, this can use significant CPU time. I'm surprised to hear that this ramps up after time @protean, this is not something that has been reported by other uses, nor something we've seen ourselves. If you check the CPU section in Activity Monitor, what is shown for the "Idle" percentage in the lower left corner? This is the amount of your Mac's total processing power that is unused. Does this figure go down steadily, or remain the same? You don't want it to drop below 10% otherwise this could cause your Mac to be unresponsive.
@camguyfbr - I see your problems are with the Browser, not live incoming live video. Could you please download and install the latest version of SecuritySpy (currently 4.0.10) and let me know if this fixes it.
