15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
Hello Vincent, Hello Mabula. I'm having a problem, when I mount a Samba Nas share in Ubuntu in the file manager and want to open a Fits file, I get a message
"This fits file seems to be incomplete and/or corrupt !!!"
But with DSLR files it works.
When I copy the Fits files to the hard disk, they can be opened easily. Other applications like Gimp, Pi can open and display the Fits files via Samba.
Interesting, that seems to have something to do with the file transfer maybe, I'll forward this to Mabula. What kind of NAS do you use and I assume that connection is rock solid? @mabula-admin
It is a Synology Disk Station. The connection is flawless, and the NAS has been performing for years without any problems.
Ok, I've notified Mabula to check your post and see if he has an explanation for the difference with your fits and cr2 files. Normally I wouldn't recommend processing anyway using an external NAS though, as APP needs fast disk access usually.
No processing takes place on the NAS. I only move projects I am not working on to the NAS because of limited space on the SSD of my PC. But sometimes APP wants to access them via network so I don't have to copy them back and forth.
Ah ok, well let's see what Mabula might say, he'll be here when he has some time.
Any update on this? My workflow usually has my subs stored on my NAS (QNAP in my case, sharing via SMB) with working directory being on the local drive. Never had an issue before (let's just say bandwidth is not a bottleneck on my network) but always worked with NEF files.
Had a bunch of FITS subs to process yesterday (new EKOS install, forgot to check the file format) who would not process as described above. After a few choice words at potentially loosing a moonless night's worth of imaging, I found the above thread and just copied the FITS locally, and they worked without problem. Extremely weird behavior, I'm guessing APP is trying to read the file header before it's all cached and fails? Don't know enough about the FIT format to analyze this issue further myself.
Not really, it has to do with how APP handles the data and processing it needs a fast bandwidth. I'm sure your network connection is fast, but internal connections are way faster, this is where things can go wrong.As to why it did work with the NEF files, I'm not sure.
I am having a similar problem having used my Synology NAS with APP for over a year.
The problem however ONLY occurs when I am using an rsync'd folder - it's fine when I either use a regular "LAN" NAS share or even (and here's the amazing part), when I use ZeroTier and load the images over the WAN NAS share.
But if it's local I get the error above. It of course has me completely puzzled. Just to make sure the image wasn't corrupted in the process of moving it over I double checked and copied the image over to my local hard drive and, it loaded fine.
Super strange!
Yay! (I think!)
Being quiet puzzled about this (especially as PixInsight coudl open the same shared files fine) I discovered a little setting in the Advanced Permissions tab that was enabled on the destination - once I switched that off it seems to work fine - let's see....
Interesting. I have no experience myself with using data via a NAS, I only use a NAS to store my projects.
