This is the 2nd time that it has happened. The first time, it stopped at 66 and this time it 256. Example
So recently I notice that this bug has happened again. Not sure what happened but the UI shows up
No tasks available even though there still some images left to annotate. (Example: I got 266 images to label but the page shows up
No tasks available when labeled 253 images.).
For it to show up the rest of the image, I have to restart the app.
Will this issue be fixed on the next update or is this user error in code that causes it?
This is difficult to say because it depends on your setup etc. How large are your images? Are you using a custom recipe, and are you doing anything to preprocess the images? Are you using any libraries (PyTorch etc.) that start multiple threads?
Basically, the most likely explanation for seeing "No tasks available" prematurely is that the stream produces an empty batch. Once an empty batch is sent to the app, it thinks there's nothing more coming in. You could try setting
"force_stream_order": True in your config if you're not doing it already to make Prodigy re-sent unannotated images so you can just reload in your browser when you hit an empty batch.
I would say it a standard 1080p sized image.
Yes custom receipt (the one I mentioned on my last issue). Nothing other than generating the input ID and check if it valid before yielding it.
I don't think so.
But I can definitely try
"force_stream_order": True as a solution but won't know if it will fully solve it since this issue will randomly occurs.
Okay, that's good to know and definitely eliminates some potential problem sources (like multithreading). I'd love to get to the bottom of this, even though issues like this are always very tricky to debug because it sounds non-deterministic and could be potentially caused at any level (within Prodigy's feed/streams logic, but also within the REST API / server etc.).
One possible theory is that it's somehow related to sending the image data over the REST API and a slight delay or race condition caused by the images taking slightly longer to generate/encode/send. So another thing to try could be to use a lower batch size, like
5 instead of
10, or maybe even lower. If that makes the problem go away or happen less often, this could support that theory (I think?).
Alright, ill consider trying that if the issue arises again.