×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Image counter issues causing images to be lost

  • Posts: 437
  • Thank you received: 31
In the last week I have had two similar but probably related issues.

In the first I was using the scheduler and found after an hour of imaging I only had a single image.
I quickly realised the counter had "stuck" and was overwriting the image each time.
My solution was to renumber each image after it was written and before the next was written.

The second was last night where I left the program to write 27 images but found only about half were there numbers from 8-23 only.
I can only assume it started at 8 wrote to 23 and then not sure. It showed 27 images had been written on the screen.

In both cases the folder was empty before starting.

In both cases I had altered the "script" after it had been used for a previous object.
I can only assume that it is losing count of something when this is done.

Paul
Last edit: 2 years 9 months ago by Paul.
2 years 9 months ago #72830

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
I have been reluctant to update INDI unless something has been done to address this, so if anyone is aware of any fixes, I would be pleased to hear.

Last night, after resetting the capture job, which was 30 luminance frames I found that job number 12 had the fit extension but all others fits - very odd.

A further thing to note was the first job started numbering from 000 but after a reset it correctly started at 001. I have seen this a few times.

A further reset and then clearing all jobs and added a new job of 15 luminance of a different object and I ended up with only 1 file number 15 or 16, I cannot recall, it had overwritten the same file number 14 times.
Last edit: 2 years 8 months ago by Paul.
2 years 8 months ago #74355

Please Log in or Create an account to join the conversation.

  • Posts: 351
  • Thank you received: 108
As workaround I would add timestamp into filename.
2 years 8 months ago #74373

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
Hi Paul,
could you please share the logs?
Wolfgang
2 years 8 months ago #74376

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
The following are of note from the attached log, which was too large so I have split into 3 files.
  1. The numbering started with SN2009G_b1g1T-15_1m_L_Light_L_000.fits.
  2. The SN2009G_b1g1T-15_1m_L_Light_L_031.fits file is saved repeatedly.
2 years 8 months ago #74401
Attachments:

Please Log in or Create an account to join the conversation.

IIRC, the current system uses "_" as a separator to identify different parts of the fields. Perhaps drop that from the prefix?
2 years 8 months ago #74403

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
Jasem,

The first two underscores are part of my naming convention, the others were added by INDI.
It should also be noted that INDI automatically replaces spaces with underscores when it populates the Prefix field, so I imagine more people would experience this if that was the cause.
I have the same problems when I don't include underscores and this doesn't happen all the time, only "randomly".
This started happening around 3-9 months ago, and I have used this naming convention for over 10 years.
I have brought all the software up-to-date, so I will see how it goes when we next get a break in the weather.

Paul
Last edit: 2 years 8 months ago by Paul. Reason: additional text
2 years 8 months ago #74425

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
Further to my last update, a partially clear night has allowed me to provide more information.
I was not using the scheduler last night.
I created a job that had 11 images through each of  my L, R, G and B filters and everything went fine. This job was not loaded or saved.
After completion, I removed those jobs and added two jobs for 11 H and S images.
This is when the problems started.
The first "new" job started at 011 and continued to overwrite the same job number.
I then stopped and started the capturing and the next job saved was 012 and the counting started to increment.
It then finished the H and started capturing the S images.
These started at 001 and incremented until cloud hit.
So,I experienced the overwrite problem without the numbering going to 000.

Paul
2 years 7 months ago #74661

Please Log in or Create an account to join the conversation.

I just tried to reproduce this with simulators but couldn't. Any way to reproduce this behavior ?
2 years 7 months ago #74666

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
Jasem,
When testing I have had trouble reproducing the "stuck" counter number, but will keep trying.
I have however found a way to consistently reproduce the counter starting at 000 issue, which I assume is related.
To see this problem you must disconnect the camera and stop INDI.
You must use a camera, I have a QSI camera, and NOT use the simulator.
When testing this,I have no other devices connected, but this may not be important.
1) Disconnect the camera
2) Stop INDI
3) Start INDI, which automatically connects the camera
4) Go to the capture page
5) Set an exposure, say 11 seconds
6) Set a count, say 41
7) add a job
8) run the job

I have filter ticked and have an empty directory selected so I can see what is happening.
Normally what happens is a sub directory called 'Light' is created and a sub directory under that called 'L' or whatever is defined.
However when following the above steps the sub directories are NOT created immediately they only get created after the image is downloaded, and the counter is 000.
If I delete the folders and start the process , <strong>without</strong> stopping and starting INDI only disconnecting or not the directories are created immediately and file numbering starts with 001.
This is all running locally on the same machine, a Raspberry Pi 4.
Paul
 
Last edit: 2 years 7 months ago by Paul.
2 years 7 months ago #74690

Please Log in or Create an account to join the conversation.

  • Posts: 437
  • Thank you received: 31
I have attempted to follow the code but I am not familiar enough with the language.
It appears to me that a file name with 000 seems to indicate that the counter is set to -1, which I assume is undefined.
Paul
2 years 7 months ago #74729

Please Log in or Create an account to join the conversation.

  • Posts: 35
  • Thank you received: 0
Hi Paul

did you solved the problem ?
i have the same behaviour, i'm using time stamp for the picture naming and after sometime (never the same)
the counter stuck to a value, so as filename are timestamp i see many files with the same number (but with different timestamp), so Ekos continue to acquire images
but image counter does not increase anymore. And after sometime ekos crash (kstar and ekos automaticaly close) and i'm back to the desktop.
typically i have between 2 and may be 20 images max with the same number.

Regards
Eric




 
2 years 2 months ago #79605

Please Log in or Create an account to join the conversation.

Time to create page: 1.176 seconds