API bugs

rspears

New member
Hi,

I've been using the API to try to integrate the camera with our companies software and I've found a few possible bugs to report that are hopefully fixable.

1. My biggest issue is when saving the file to the SD card. I'm hitting the "startFilesave" endpoint, and then trying to use the "playbackLength" and "playbackPosition" parameters to track progress.
  a. First I need to get "playbackLength" in order to setup progress monitoring (progress will be currentPlaybackPosition / playbackLength). This value is not correct. When I try to save the file from the buffer into the SD card, "playbackLength" is stale, and appears to be the value from the previous video I saved. If I try to save the video again, it appears to be correct.
  b. For the "playbackPosition", I tried hooking into to the Server Sent Events to monitor this, but it doesn't seem to throw notifications when this value changes. I at least do get an event when the state changes away from "filesave", so I know when the save process has finished. But according to the docs, it seems like I should be getting these events when anything changes.
  c. So, because that didn't work for me, I resorted to manually polling "playbackPosition" in order to try to track progress. During the filesave operation, the playback position starts at a seemingly random value (I've seen it at 100, up around 1200, etc), jumps back to 0, then goes all the way to the end like it should, but then goes back to a different random value before I receive the SSE that the camera state has switched off of "filesave". I'm not sure what's happening here, but all these pieces together make it impossible to consistently and correctly track the progress of the save operation.

These bugs seem to be present on the web interface as well. I've noticed the stale "playbackLength" bug for sure, and the weird thing where "playbackPosition" jumps to some random value at the end of the filesave operation.

2. I can't connect to the rtsp stream. I'm using VLC to try to connect to it and it's just not working.

3. More minor, but some of the endpoints don't like if I specify an encoding in Content-Type in the headers. I'm using .NET HttpClient and the default Content-Type for json is "application/json; charset=utf-8". This seems to work for some endpoints but not others, so I'm just clearing out that "charset" piece and everything works. Still this seems buggy.
 
I may have found a workaround for my purposes for bug 1a, by using "totalFrames" instead of "playbackLength".
 
Another bug: Adjusting resolution - I can set the resolution to any supported value (incremented by 32 in the width, 2 in the height on the 2.1 camera I'm testing) via the camera interface. On the web interface and API, unless I set it to "standard" values - like 1920 x 1080, 1280 x 1024, etc. - I get blue lines or blue tint in the video. Even some of the common resolutions listed in the camera's datasheet exhibit these issues. Something is happening when I set it on the camera that is not happening when I set it via the API.
 
Even some of the common resolutions listed in the camera's datasheet exhibit these issues. Something is happening when I set it on the camera that is not happening when I set it via the API.
Same issue here, and I had the same thoughts... When you set the resolution in the camera, something additional is happening (looks like a small reset or so). But it doesn't happen when you set the resolution via API, resulting in unexpected behaviour.

During the filesave operation, the playback position starts at a seemingly random value (I've seen it at 100, up around 1200, etc), jumps back to 0, then goes all the way to the end like it should, but then goes back to a different random value before I receive the SSE that the camera state has switched off of "filesave".

How did you solve this...?
 
rspears said:
1. My biggest issue is when saving the file to the SD card. I'm hitting the "startFilesave" endpoint, and then trying to use the "playbackLength" and "playbackPosition" parameters to track progress.
  a. First I need to get "playbackLength" in order to setup progress monitoring (progress will be currentPlaybackPosition / playbackLength). This value is not correct. When I try to save the file from the buffer into the SD card, "playbackLength" is stale, and appears to be the value from the previous video I saved. If I try to save the video again, it appears to be correct.
  b. For the "playbackPosition", I tried hooking into to the Server Sent Events to monitor this, but it doesn't seem to throw notifications when this value changes. I at least do get an event when the state changes away from "filesave", so I know when the save process has finished. But according to the docs, it seems like I should be getting these events when anything changes.

Code:
playbackPosition
does not notify, therefor polling is indeed required for tracking the save progress. I believe
Code:
playbackLength
pertains more to playback mode in the later software versions. Make sure to specify the
Code:
start
and
Code:
length
in your request to
Code:
startFilesave
, and try tracking your
Code:
playbackPosition
relative to your requested values instead.



rspears said:
  c. So, because that didn't work for me, I resorted to manually polling "playbackPosition" in order to try to track progress. During the filesave operation, the playback position starts at a seemingly random value (I've seen it at 100, up around 1200, etc), jumps back to 0, then goes all the way to the end like it should, but then goes back to a different random value before I receive the SSE that the camera state has switched off of "filesave". I'm not sure what's happening here, but all these pieces together make it impossible to consistently and correctly track the progress of the save operation.

Although this seems a bit buggy, it's normal behavior with the Chronos 1.4 & 2.1 cameras. I believe internally these cameras require a lot of effort to switch into a saving state, which is also related to why the video signal shuts off while saving.



rspears said:
2. I can't connect to the rtsp stream. I'm using VLC to try to connect to it and it's just not working.

Make sure you're running the latest Chronos software version 0.7.2 and latest version of VLC. See section 2.2 of this guide for instructions:
https://www.krontech.ca/wp-content/uploads/2020/03/Network-Control-v0.6.5.pdf

However, I prefer to use MPV with the "low-latency" profile enabled. It tends to maintain the video stream much better compared to the default VLC setup.
https://mpv.io/manual/stable/#low-latency-playback



rspears said:
3. More minor, but some of the endpoints don't like if I specify an encoding in Content-Type in the headers. I'm using .NET HttpClient and the default Content-Type for json is "application/json; charset=utf-8". This seems to work for some endpoints but not others, so I'm just clearing out that "charset" piece and everything works. Still this seems buggy.

For requests which would respond with JSON, make sure your request header has
Code:
Content-Type
with a value of
Code:
application/json
. Many HTTP clients will inject other values, such as
Code:
charset=utf-8
, but the Chronos API will not respond correctly to that request. Furthermore, case sensitivity matters, so for example, a value of
Code:
Application/JSON
would also result in the request being ignored.



rspears said:
I may have found a workaround for my purposes for bug 1a, by using "totalFrames" instead of "playbackLength".

Code:
totalFrames
refers to the quantity currently in the buffer. It is a reliable value to key off of, because in many cases the
Code:
playbackLength
is not automatically updated. Another parameter you may want to consider referencing instead, is
Code:
videoSegments
, regardless if you're recording in segmented mode. The advantage is that you may retrieve the frame rate and exposure period originally used.



rspears said:
Another bug: Adjusting resolution - I can set the resolution to any supported value (incremented by 32 in the width, 2 in the height on the 2.1 camera I'm testing) via the camera interface. On the web interface and API, unless I set it to "standard" values - like 1920 x 1080, 1280 x 1024, etc. - I get blue lines or blue tint in the video. Even some of the common resolutions listed in the camera's datasheet exhibit these issues. Something is happening when I set it on the camera that is not happening when I set it via the API.

When you press the OK button in the Record Settings dialog, a "zero time" black calibration is automatically performed. You may achieve the same results by sending a
Code:
startCalibration
request after receiving the Event indicating the sensor configuration has changed.



Willa said:
Seems funny that Krontech doesn't care about this.

I'm guessing this thread was accidentally overlooked. I'm very experienced with the Chronos API and would be happy to help! Some minor revisions have been made to the documentation, and it now has a new home at the following URL in addition to being a downloadable PDF on the Software Resources tab of the main Kron site
https://support.krontech.ca/en/articles/9903772-chronos-0-7-0-api-documentation
Please let me know if you have any other questions!
 
Back
Top