Author Topic: API bugs  (Read 22465 times)

rspears

  • Newbie
  • *
  • Posts: 4
    • View Profile
API bugs
« on: March 11, 2021, 01:49:37 PM »
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.
« Last Edit: March 11, 2021, 02:44:25 PM by rspears »

rspears

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: API bugs
« Reply #1 on: March 12, 2021, 09:43:49 AM »
I may have found a workaround for my purposes for bug 1a, by using "totalFrames" instead of "playbackLength".

rspears

  • Newbie
  • *
  • Posts: 4
    • View Profile
Re: API bugs
« Reply #2 on: March 17, 2021, 07:59:36 AM »
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.

Willa

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: API bugs
« Reply #3 on: May 11, 2022, 08:02:44 AM »
Quote
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.

Quote
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...?

Willa

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: API bugs
« Reply #4 on: April 02, 2025, 10:48:19 PM »
Seems funny that Krontech doesn't care about this.

hummingbirdography

  • Newbie
  • *
  • Posts: 44
    • View Profile
    • Instagram
Re: API bugs
« Reply #5 on: April 03, 2025, 01:04:32 PM »
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.

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



  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.



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



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 Content-Type with a value of application/json. Many HTTP clients will inject other values, such as charset=utf-8, but the Chronos API will not respond correctly to that request. Furthermore, case sensitivity matters, so for example, a value of Application/JSON would also result in the request being ignored.



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

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



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 startCalibration request after receiving the Event indicating the sensor configuration has changed.



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!