×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Ekos keeps saving same image file

  • Posts: 37
  • Thank you received: 1
I've found a couple of time a very odd behaviour: while taking picture, at about the 7th - 8th picture Ekos does not write new image files but continues overwriting the 8th file with the last image taken. The counter of taken images goes on on the screen but the files stays at 8. Other than that no other issues can be found. This is the log from the CCD tab in Ekos:

2022-08-03T23:55:51 Capturing 300.000-second image...
2022-08-03T23:55:51 Dither complete.
2022-08-03T23:55:51 Dithering succeeded.
2022-08-03T23:55:35 Dithering...
2022-08-03T23:55:35 Captured /home/astroberry/Light/Pickering_Light_008.fits
2022-08-03T23:55:35 Received image 12 out of 30.
2022-08-03T23:55:35 Download Time: 1.18 s, New Download Time Estimate: 1.27 s.
2022-08-03T23:50:33 Capturing 300.000-second image...
2022-08-03T23:50:32 Captured /home/astroberry/Light/Pickering_Light_008.fits
2022-08-03T23:50:32 Received image 11 out of 30.
2022-08-03T23:50:32 Download Time: 1.31 s, New Download Time Estimate: 1.28 s.
2022-08-03T23:45:30 Capturing 300.000-second image...
2022-08-03T23:45:28 Captured /home/astroberry/Light/Pickering_Light_008.fits
2022-08-03T23:45:28 Received image 10 out of 30.
2022-08-03T23:45:28 Download Time: 1.21 s, New Download Time Estimate: 1.28 s.
2022-08-03T23:40:27 Capturing 300.000-second image...
2022-08-03T23:40:26 Dither complete.
2022-08-03T23:40:26 Dithering succeeded.
2022-08-03T23:40:12 Dithering...
2022-08-03T23:40:12 Captured /home/astroberry/Light/Pickering_Light_007.fits
2022-08-03T23:40:12 Received image 9 out of 30.
2022-08-03T23:40:12 Download Time: 1.26 s, New Download Time Estimate: 1.29 s.
2022-08-03T23:35:11 Capturing 300.000-second image...
2022-08-03T23:35:09 Captured /home/astroberry/Light/Pickering_Light_007.fits
2022-08-03T23:35:09 Received image 8 out of 30.
2022-08-03T23:35:09 Download Time: 1.27 s, New Download Time Estimate: 1.29 s.
2022-08-03T23:30:07 Capturing 300.000-second image...
2022-08-03T23:30:06 Captured /home/astroberry/Light/Pickering_Light_007.fits
2022-08-03T23:30:06 Received image 7 out of 30.
2022-08-03T23:30:06 Download Time: 1.25 s, New Download Time Estimate: 1.30 s.

As you can see, it first wrote twice image 8 and 9 on 007 file and then after it wrote image 11 and 12 on 008 file.

Anyone any idea? At the moment I tried to manually change the file name after the download, but when it happened on the first time a month or two ago it worked and numbering resumed correctly, yesterday it led to a "write file error" and crash of the program...
1 year 7 months ago #85042

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

  • Posts: 437
  • Thank you received: 31
This not a new issue, it started just over twelve months ago and I have been using various workarounds since, but they often fail.

indilib.org/forum/ekos/9913-image-counte...ages-to-be-lost.html

Paul
1 year 7 months ago #85045

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

This was reported in an old version of KStars. Can you reproduce this issue on 3.6.0 stable release?
1 year 7 months ago #85053

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

  • Posts: 96
  • Thank you received: 25
I had this too, once or twice upon a time. I enabled timestamps in the filename and haven't had the problem again.
1 year 7 months ago #85054

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

  • Posts: 37
  • Thank you received: 1
Thank you both! I'll try the timestamp trick to see if it works...

It's only strange that it's not a consistent issue but happens quite randomly...
1 year 7 months ago #85062

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

  • Posts: 96
  • Thank you received: 25
So I just happened to be paying attention and saw this happening on fully updated stellarmate 1.7.2 (kstars 3.6.0, built on 2022-08-02)

Note that the capture module shows 8 exposures taken, while the analyzer module shows many more exposures taken in this schedule. At least the timestamps prevent data loss.

Last edit: 1 year 7 months ago by Chris Kuethe.
1 year 7 months ago #85282
Attachments:

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

Thank for the update. Without using timestamps, can you please outline to steps the reproduce this?
1 year 7 months ago #85291

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

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

It appears randomly, however, it most often occurs when I have taken some images using the capture page and then remove an existing line or two and put some more lines in.
My original work around was to add a single capture and another line with the number I needed. It seems to reset the counter after doing this, although it would sometimes not work.
I have since added the time stamp, and last night it did the same thing again, where it started with a count of 010 and got stuck there until midnight local time when it started incrementing.
This started at the same time, just over a year ago, when the original count started at 000 instead of 001.
So, when I start a new capture run it begins at 000, but if it changes filters or starts a new capture run it always starts at 001, assuming there are not already images in the directory.

If I could reproduce this consistently, it would be easier.

Paul
1 year 7 months ago #85292

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

  • Posts: 237
  • Thank you received: 33
I have noticed this mismatch between the Analyser and Capture module too, but this is only around 1 or 2 images off. And if you are storing the images remotely, it just gets worse :-(
1 year 7 months ago #85293

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

  • Posts: 96
  • Thank you received: 25
Unfortunately I haven't found a consistent way to reproduce this. I'm just using Kstars like normal and sometimes it happens, but I'll give you as many observations as I can in hopes that something obvious falls out. I do have logs from the last couple of months if that'd help.

- The issue happens with or without the scheduler. The first couple of times this occurred, I was just running a single sequence in the capture module... point 'n' shoot, hope I have good data in the morning. Last night I was using the scheduler. The second target in my schedule failed to align because the moon was overpowering my guide camera so the scheduler just went back to my lower priority target (Thanks Hy!)
- It seems to happen fairly quickly after sequence start - usually around exposure number 8.
- I am not using network storage for my captures; they're going directly to a dedicated, USB-attached, SSD.
- I've had this happen with two different main cameras: ASI482MC and ASI533MC-Pro

Current equipment profile
Raspberry Pi 4B+ 8GB
DS1307 I2C RTC
256GB Sandisk USB Extreme Pro SSD
64GB Sandisk
Skywatcher AZ-GTi (EQmod driver)
Ublox M8N GPS (GPSD driver)
ZWO ASI120MM-mini + Orion 30mm ultra-mini guide
ZWO ASI533MC-Pro + SVbony 70mm SV503 refractor
1 year 7 months ago #85307

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

Time to create page: 0.848 seconds