I am using a web browser to view cameras on my Mac (since there is no Mac client) so that I can customize the camera matrix layout for my own preferences. I am using Jquery ($.get) to take a snapshot when the page loads, then using the returned libraryID to show the captured image (:8100/Library/id), then using a modal window to show realtime footage (:8100/Mjpeg) when the aforementioned snapshot image from the matrix is clicked on. This works great, but my issue is that when I take the snapshot using the :8100/Json/CapturePicture method, the actual picture is always much older (sometimes minutes) than when it was requested. When I look at the timestamp on the image (created by the Netcam overlay), it is always much older than the timestamp on the image file that is stored in the library folder:
How can I assure that when I take a snapshot using the :8100/Json/CapturePicture method that I can get a realtime image and not one that is minutes prior to the time it was taken?
To be clear, I am using web requests for these. Your port 8124 is confusing, as everything that I have seen from this forum references 8100 for Json/capturePicture (See this forum topic):
I tried port 8124, but it returns nothing.
It looks like the CapturePicture is pulling the last buffered frame for the current snapshot instead of grabbing a frame from the live camera feed. Changing the camera properties in the camera source’s Output Resolution to “Native” decreases the delay, but it still is a delay.
Here is my code for grabbing the picture with Jquery (for privacy issues I replaced the site and token in the URLs):
which immediately returns the libraryID of the picture (as referenced in the above topic). I then use the returned LibraryID as the src for the image in my web page using the Library call:
As stated above, it works perfectly except that the image is much older than the point in time that the picture was captured with the CapturePicture JSON web request.
I can also confirm that the image is truly old, as one time I opened the page initially, and it showed a car that was no longer there but was about an hour before. Timestamp on picture (overlay) was old, but timestamp on image file was precisely the time of the page opening (which means it refreshed as designed).
Hi,
Thanks for the information. This is something that need some further investigation and changes and cannot be solved just now. Most likely in a future update.
Question is if you can use another way using the Rules.
-Henrik
Can you at least reproduce the scenario so that you confirm/understand the issue? A web service that is intended to “capture pictures” should at lease capture realtime (or near realtime) pictures from the time they were requested.
This deflection of addressing the issue “in a future update” is extremely concerning to me…
Obviously it’s nothing wrong with the software so it must be local in your system. So you need to go through the time stamp process.
I would check in the folder where the image is saved at the same time when I send the command and correlate to the time in the video. According to your pictures it would take about two minutes between command and saved image.
Maybe add some more clocks in the video.
Not to worry, this gave me a reason to seek out other solutions that don’t run on Windows. ZoneMinder (running on Debian 10) has proven to have a reliable and realtime API. Thanks for your help.
Sorry, you didn´t find the problem in your system. However, Linux versions is a good alternative. They usually also use less cpu resources if that´s a problem.
Good luck,
Henrik
