@Fitchie,

There is an issue when you use the same name for different jobs. (It probably nagged you in the log window about this, but it is easy to miss.) Since they have the same name, they wind up generating the same filename prefix and the progress counting gets confused. If you are using 'Remember Job Progress' the 2nd, 3rd, ... jobs will probably not execute at all. If you are not using that, it will probably work normally.

What I'd recommend are 2 things:
1) Why are you repeating the jobs at all? Why not just have one job with "Repeat 15 runs", or "Repeat until Terminated"?
2) If you do have a reason to repeat the jobs, you should name them uniquely, e.g. NGC6888-1, NGC6888-2, NGC6888-3, ...

Hy

Owkeyyyy !

That's very good to know.
I actually didn't have a particularly good reason to do the same job 5 times, but it seemed mathematically easy to have a job of 1 hour each time.

And as I write this the first hour has passed and as we speak I see moving the mount to park position. The 5 jobs have indeed ended at the same time.

I'm glad to notice that now, otherwise the night would have passed without pictures.

Thank you!

New night, new try !

This time I'll go for 150 x 120 seconds in 1 job. The only thing I do not understand is the red circled timer in the screen dump:



5 lights of 10 are done, number 6 has 18 seconds to go. So countdown timer should be something like 9 minutes.
What is the 20:44:11 ?

That's really strange. The middle indicator should calculate the remaining time of the currently active capture sequence, the right one the remaining time of all planned captures.

Is it possible that you had significant download times? At least the middle indicator takes this into account as well.

Could you reproduce it with simulators instead of your original imaging train?

Greetings
Wolfgang

Hi Wolfgang,


Thank you for your reply.
I was trying to reproduce the error by simulation a 10 x 10 x 2 minutes sequence, but now all countdown timers looks OK.



Download time 1,08 seconds.

Will try to reproduce the error during the night...

Hello,
I am still trying to understand some behaviours I consider illogic.
This mainly relates to local vs distant mode in CCD tab.

1. If I chose to save to local, it opens the viewer after each take, though I did deactivate this. It does not happen in distant mode.
2. In local mode, a delay of three to six seconds is added between each take. This does not happen in distant mode.
3. In local mode, the pattern for file naming is taken into account. It is ignored in distant mode.
4. In local mode, the pictures are saved to the local SD card. In distant mode, they are saved to the same SD card.
5. I did set my train and almost every data I was aware of. Despites this, the metadata claim that I used a simulator instead of the lens I registered.
6. I own SLR lenses of 500, 800 and 1000 mm, which I still cannot register as lenses.
7. When using my 500 mm f/8 with x2, it is reported as a 1000 mm f/8 instead of f/16. This seems to be because the doubler is not viewed as such in the optical train.

The manual still was of no help - but maybe I did not correctly read it.
Rgrds,
J.-Luc

Thank you for the feedback.

1. For preview image, it will always trigger FITS Viewer. For batch images, it shouldn't use FITS Viewer.
2. That's probably the time it takes to parse and open the image in FITS Viewer tool?
3. I couldn't reproduce this issue with master.
4. SD card shouldn't matter local or remote, it depends on DSLR configuration. You can configure DSLR driver to save or ignore SD card image.
5. Cannot reproduce
6. Fixed in 3.6.6 GIT.
7. Fixed in 3.6.6 GIT.

Hello Jasem

1. The behaviour I describe happens while running batch - sequences in capture tab - and not in preview mode.
2. Alright, so where can I disable the viewer in local mode, as I did for distant mode, so it does not bother me anymore ?
3. I will edit this further and attach a picture so you can parse the header and view it - better than long explainations.
4. Not a DSLR, a ZWO ASI183MC, as stated in this post in which I also describe what happens with file naming according to whether I select the destination as local or distant.
   In the post, the window on the left is related to saving to distant, while the right one shows file names when saved to local, despites the main window only showing distant - I was too lazy to take two separate screenshots.
   BTW, would all this happen to be recorded in the log if I activate it ? It might help to confirm what I state.
5. Same as above about logging.
6. 
7. again
So next update will bring both these

I don't know if it could be of any help, but I am using Rob Lancaster's fine script on a RPI4, and so invoking setupUbuntuSBC.sh.
Edit : screenshot of fit header added - I could not attach the fit itself.

Hello,
Back again with my unsolved problems :

1. saved filename do not match the pattern
   Given a pattern set as /%t/%T/%f_%D_%e, as shown on my previous screenshots, with target=Lune
   I vould expect the files nammed as follow : Lune_2023-08-06T00-46-28.730_0.013_secs_001.fits
   But in fact I get : Lune_Light_0.013_secs_2023-08-06T00:46:28.730_001.fits
2. even worse, the filename format does not match the one displayed by built-in help
   As you can see just above, the "-" in the time format are replaced by ":", which leads to unhandable files.
   The buil-tin help displays the correct format with "-", however.
3. delay is added to the scheduled time
   Yesterday, I set a sequence with 1800 frames of 0.0125s each, which ought have resulted in 30 min duration (see Lune.seq.txt file attached).
   It lasted over 90 min. I still cannot understand why those 3 sec are added in distant mode.
   I tried to redo this a few minutes ago, and the delay was not added anymore.
   How on earth can the same thing done two times lead to two different results ?

The second attachment nammed log_19-42-59.txt is the result of tests I did yesterday : 1 sec frames, first batch in distant mode, the second one in local mode.
Same settings for both, however different results.
Please, do pay attention to the resulting file nammings and execution delays.
Regards,
J.-Luc

Hello! In order not to make a new topic with a small problem, I want to ask.
In live view mode, the memory buffer fills up very quickly. How to avoid it?

Increase maximum buffer size in INDI control panel? not sure if that would help but might worth a try. It's now set to 512 so make it 2048 for example

I'm afraid I will never get my problem solved, plus my topic has been hijacked twice so it becomes very difficult to tel what is whose.
I give up here and start another one, on better basis. I hope.