Our best guess so far has been that the next frame has been half-written to the buffer before it was locked. The issue seems to go away when I use ACCESS_READ instead of ACCESS_READ_WRITE, but I need to be able to write to the image buffer.
The overall effect of this seems to be that it makes playing back an rssdk very difficult as the application tends to hang when it comes to this frame in the depth stream on playback.
Has anyone experienced this, or know how to keep it stable while keeping read/write? It could very well be something simple I may have overlooked, any help is appreciated!
My workplace won't let me share code, but the only fix I could find to this issue was to set to read only instead of read/write, copy to a new image, and write to that image. Otherwise, the recordings get corrupted.