I always run the full shebang on the Pi4 on the mount and connect via VNC. Avoids any network disruptions. I never have any of these problems. The Pi4 is plenty mighty to handle it all locally. And if the network hangs, as sometimes happens, the scheduler will complete without outside help and also park the mount and shut down the cameras.

I would run everything directly on a Pi4 attached to the mount.

Well, first: not triggering a bug will not get it fixed (or even tell me what is the reason of the failure).

Running everything on the mount computer might work nice for you, but not for me, as I do a lot of live analysis on my data, so I want it on the laptop. I also would miss the dual monitor setup for the various windows. And finally, I wouldn't want to downgrade my mount computer to a Pi 4

In short, I'd really like to know why the scheduler uses a wrong directory path....

Hi Pit,
I'm not 100% sure but it looks like you stepped into a bug that must have appeared recently. I tested it and had the same problem.

I would recommend that you go back to commit c55eb81a - and you need to re-create the capture sequence file, since it's syntax changed.

HTH
Wolfgang

p.s.: If that is working, you could take a closer look how to use the scheduler. I would recommend using "Repeat for ..." and having shorter sequences in the capture sequence file. I for example typically use a LLRGBLLL capture sequence file and repeat it 15 times followed by a LL sequence that is repeated 50 times. In combination with "Remember job progress" selected, you can run such a schedule over several days or weeks until you have 15xRGB and 100xL.

I don't have access a recent .esq file of my own at the moment, but it looks to me like there could be a syntax typo specifying the directory for the image download. The .esq file you posted shows that you are saving your files to

<fileDirectoryTectory>/home/pit/EKOS/2020.09.19</fileDirectoryTectory>

<fileDirectoryTectory> does not feel right. Looks like a cut/paste problem(?)

In my older .esq files I could access off-hand, that address is called <FITSDirectory>

Whatever it is, however, it must be limited to instances where you are running Ekos in server mode. The problem definitely does not exist when Ekos runs autonomously on my Pi4 on the mount itself. And that is with an installation I compiled from source only 2 days ago.

I will check one of my most recent .esq file as soon as I have access to my equipment again.

I hear ya! The Pi4 is definitely not fast enough or has enough memory to handle live stacking in parallel to image acquisition.

BUT... you could just use Rsync to transfer your images from the Pi to your desktop or laptop. It gives you an immediate backup and you still have all the images in near real time for analysis.

I find the Pi4 is plenty powerful on its own. ASTAP solves within 3 seconds now, running autonomously on the Pi at the mount. The solver always was the limiting factor in the past that just did not work well on a Pi3. But that is all in the past now.

Hola Wolfgang!

Thanks for the confirmation! Yes, ISTR that I had used it successfully before, with normal sequences and a mosaic.
I've compiled a package with the c55eb81a status, and will keep that available until the bug gets squished

Yes, I've played with shorter sequences, too. But right now I don't trust the filter offset values too much, and do an AF run on filter change. That rather excludes short sequences....

Not really sure what you mean with 'server mode'. I assume it has to do with whether you do local or remote saves, but EKOS will always communicate with INDI via sockets, whether they point to a different or the same host should not make a difference, IMO.

As for the "fileDirectoryTectory": Yes, I had noticed that, too. It is however consistent within the capture module it seems (and capture itself stores the files in the proper location). But a grep on the sources seems to suggest that the scheduler still uses FITSDirectory:

I checked my latest .esq files and indeed, the naming changed between September 17 and September 19, AFTER the last time I recompiled again on September 19. As of September 17, the Capture sequence still referred to the FITSDirectory.
However, I did not have your problem. The only reason I can think of why I did not is that I have unchecked the 'Remember job progress' box in the Ekos>Scheduler Tab. I presume you have yours checked?

Your log suggests that you do and that triggers the scheduler to look for the images that have already been acquired. Since it its looking in the wrong directory (starting at top level, instead of your home subdirectory /home/pit/EKOS/2020.09.19, it naturally can't find any images there, so the scheduler can never progress.

Ah, I'm compiling less regularly, last version before the current was from Sep 6 or so...
But yes, the old sequence files I had did use FITSDirectory...

Yes, it's checked. Guess that is the default? Can't remember having changed settings there.

Absolutely makes sense like that!.
I wonder if manually adding a <FITSDirectory> tag in the sequece file would make the scheduler happy (without irritating capture) but I'd have to use the simulator to check - weather prediction for the coming days are awful. I thought clouds are forbidden in a professional observatory...

Yepp, I guess adding the tag would solve the problem (until the bug is fixed).

I stumbled across this too .

www.indilib.org/forum/development/7857-n...is-broken.html#60692

Is the plan to align the scheduler with the capture module naming convention or the other way round. I think I'm going to have a go at fixing this, but don't bank on that getting done...

J.

Edited to add:

Forked the repo and see what needs to be done. It's clear the intent was to rename the directory to fileDiretory from FITSDirectory in capture.cpp.

I'm not convinced this was a good idea because this is a breaking change to the sequence file format that doesn't add any additional functionality that I can see. Just done a side by side compare of the before and after sequence files and the tag name change is the only difference I see.

I'm going to revert to the FITSDirectory tag and test.

J.

Should be fixed in commit 480e2db4