While playing with a homemade scheduling software, I recently came across a problem, although I have been using the blob reception code for quite a while, things apparently started to change, as I instantiated two camera device in my code.
The problem is recurring, I can reproduce it every time I run my code, but the path to get there is pretty complicated, and I haven't been able to setup a minimal working code to exhibit the problem.
To give you a bit of context:
I am using both CCD Simulator and Guide simulator. I have a single client object that manages both (drivers are running on localhost).
The Guide Simulator is used by PHD2 in parallel for guiding.
I am interacting in my code with CCD SImulator device in order to acquire while the virtual setup is guiding.
What happens every time, while I am trying to use the CCD SImulator (while Guide simulator is used by PHD2) is that I end up receiving a 'CCD1' blob for the right device (ie blob.bvc.device is CCD Simulator) but its size is 0, and it cannot be read as a fits file.
It is not clear to me how I should deal with an indiclient that should be able to handle two cameras shooting at the same time, because I suspect the problem is coming from there, apparently indiclient offers only one blob identifier in that case, which is "CCD1".
Can someone help me understanding what is wrong with my approach, or what should be the right approach for a dual camera setup with pyindi.
For mobindi, I set up a dedicated connection for blobs - to avoid interleaving them with other small & important messages, and never had that issue. Never tried with two sensor ccd though
Thank you pludov ! I checked and it looks like this is also what Gulinux did with AstrophotoPlus, he has a blob client specific class.
I decided to keep a "Big" client, responsible for every callbacks related to one server, but I changed the newBlob callback to use something less naive that was I was using before, with a proper process-based mechanism to enqueue the very next blob that comes in after an acquisition has been triggered. (Again, I took was Gulinux did in AstrophotoPlus, which is an amazing software).
I might change the big client approach in the future, depending on the performances.
Anyway, thanks to this queuing mechanism, it looks like I don't have this problem anymore, now, I don't really now if the problem was due to timing issues, or memory space / multi process synchronization (I don't remember if client callback are run in the same process or not), but now the problem is gone.