Accessing snapshot URL results in 50x/40x errors, sprodically.

[JohanMynhardt]

Documentation: https://developer.cisco.com/meraki/api-latest/#!generate-device-camera-snapshot

Endpoint: /devices/{serial}/camera/generateSnapshot

I have been trying to build a flow around MQTT events and requesting snapshots.via the API.

What troubles me is that accessing the image at the location in the snapshot request's response has rather sporadic results. Sometimes there is an image, sometimes the response has an HTTP/40x or HTTP/50x response. Sometimes I get an image response, then requesting the URL again, one of the error responses.

I have never received an HTTP/429 (RateLimit) response and have been trawling the forums in an attempt to find anyone with similar experiences, but no luck as yet.

I'm trying to find out if it is a network issue from the camera or a Meraki network issue. Unfortunately, I'm only on the consumer side, so I don't know the specifics of installation and the network on-premises. In the video dashboard, I hardly notice any issues, which makes my experience more frustrating when trying to use the Snapshot API.

Update:

I am aware of trying to request the resource with a delay, and even with that, I observe the same sporadic behaviour.

[Greenberet]

If I remember right, then there was/is an issue with the redirect from api.meraki.com to the shard with this endpoint.

Try it again with the shard url (nXXX.meraki.com) of your dashboard instead of api.meraki.com

[JohanMynhardt]

Thank you! I will try and confirm whether that improves the experience.

[JohanMynhardt]

OK, I'm not sure I'm on the same page.

I'm using the v1 API, calling /devices/:device-id/camera/generateSnapshot, which returns a JSON response indicating the URL from where to fetch the snapshot.

The URL looks like https://spn2.meraki.com/stream/jpeg/snapshot/{some-long-string-here},  which is not an api.meraki.url endpoint. Replacing spn2 in this example with the shard, doesn't appear to be valid.

In my case, I have never had an issue with the /devices/:device-id/camera/generateSnapshot endpoint.

[Greenberet]

ah sorry, I misunderstood you. I thought, that you mean the generateSnapshot endpoint.

I had problems with dowloading the screenshots too. I've created a script to download images for a time lapse.

My solution: between every generateSnapshot call there is a 0.3 second delay

between generateSnapshot and downloading the image is a 5 second delay - The api request will be sent to the camera, which must decrypt and upload the image to the meraki cloud. This process might take a while.

[noname1]

We're facing the exact same issue as of May 2023. Can't really find a stable steps to reproduce this issue. It just happens randomly as the OP described.

@JohanMynhardt  have you heard anything from Meraki Support Staff about this issue or possibly found a reason for this happening that is worth sharing?

[JohanMynhardt]

@noname1 unfortunately not. The workaround is to delay requests by a sufficient amount of time. I'm intently vague on a value as it's by trial-and-error.

[noname1]

OK, so in the beginning I thought it may be the issue with camera being offline due to power outage which would cause a gap in a video stream. However by inspecting Meraki Dashboard I can see that the video for the specific timestamp is there! Either way if you query for a camera snapshot when there is no footage for the specific timestamp, you will get error at the point when generating the URL for snapshot file rather than at the point of downloading the file.

What I tried next is generate URL & download snaps for +/- few seconds and apparently this works for every single time. Whenever I hit 400/502 I just try again with +1s. So if you can allow for this difference in timestamp for your snaps then I believe it's stable enough solution until we hear back from Meraki about the issue.

P.S.

There is no need for delaying requests. In my experience during the debugging time the file is ready for download as soon as the URL is generated for it. Although as a safeguards I also implemented some loop which retries download file again with 1s delay whenever there is error in response - you can cap it at few times not to run it indefinitely just in case