Pask problem was that GPhoto itself cannot even capture an image, so it's not related to INDI per se.

Andreas, you problem is different, it crashed in subframing, I think I fixed it right now in GIT. Another issue, it seems your requested a frame with size (5300 x 3500) while your camera size is (5208, 3476)

Hello Jose,
When Jasem did it from terminal, it gives the same issue.

We did a full trace of the debug , and you have the result in my first post in the attachement. (I'm not enough an expert to do it by myself but if you give me the list of command i can do it again.

(By the way, i did a reinstall of indiserver and the driver came back in indiserver)

In middle of the night i did a full new install on a different sd card. I use a the ubuntu mate and the astroPi3 scripts. I did again the shooting and the issue remain the exact same.

I tried to use the mirror block or not , i also tried the option "fast looping" but we stay at same level with same issue.

I am free to investigate more but i'm not enough a linux guru to do more .. we can open a remote session at anytime if you'd like

Jose : sorry i did not see until now your last post ( and i was up working on that almost all night long
Thanks for your patience,
Pask

This is not an INDI issue since you cannot capture by using gphoto2 command. As I suggested in our chat, you need to report the detailed debug log file for GPhoto2 to their Github issues page and see what they have to say about that.

Sorry.. just waking up and i thought i was o. The git issue part (
Mea culpa jasem !

Hi Jasem,

I wasn't able to save the image properties in the beginning (don't know why, had to reenter them often until I managed to save the updated values after a shot) but in my latest testing they were allright for sure. So they are now and I can reproduce the issue.
I turned of mirrorlockup and tested, did lieveview twice - its the same the mirror stays up after this. Difference: you can shoot pics (i did only short daylight exp) and it seems not to hang. The idle state of the mirror is "up" then.
In other cases this causes problems too:
indilib.org/forum/ccds-dslrs/3206-stock-...uto-focus.html#24468
this seems somehow related indilib.org/forum/ccds-dslrs/3186-canon-...dangerous.html#24255
or this one maybe too: indilib.org/forum/ccds-dslrs/2714-proble...non-dslr-driver.html
I read through the ccd&dslr forum and in some posts I find something like "...I can do a preview and a liveview but not take a picture" and than people are beginning updating and compiling and changing cables or what is worse the thread ends and people quitting INDI quietly ...

Andreas

Thanks, Pask, I know this is frustrating, I had a similar problem at the very beginning when I was connecting my Nikon D3300 to Indi and it would always crash. I do not remember exactly anymore how I solved it, now I am trying to retrace my steps. Also, this is kind of a fun detective game and it helps me also understand the programs and the integration of the different parts into Indi better. So I have to beg you and Jasem to have patience with me, not the other way round.

I looked at your log file and from what I am seeing all goes well with the camera connecting, taking a 10s exposure and then it falls apart due to an 'Unknown event'. That doesn't tell me (at least) anything, except that something went wrong. I can deduce that from the ensuing crash. That's why I proposed to start at the very beginning of the problem, i.e. gphoto2. It could be a gphoto driver problem, as Jasem suspects, or it could be Pi3-related hardware limitations with just too big a data file coming in and the Pi can't handle it. That's my pet theory here. To distinguish between the two I suggested a very simple test: Stop Indi, quit Kstars, open a terminal and simply paste the following commands:

$ cd ~/Pictures

(so that the tmp file I am interested in gets temporarily saved in the same folder as the final image file downloaded from your Canon instead of the /home folder and so you don't clutter your home folder with files you want to manually delete again later)

$ gphoto2 --capture-image-and-download --filename ~/Pictures/Test.CR2 && eom ~/Pictures/Test.CR2

(this will command your Canon to take an image at the settings you specified on your Canon, i.e. with exposure time and the format settings RAW, mRAW or sRAW that you have specified there, then download it to the Pictures folder, calling it Test.CR2, and once that is done open it using the Eye of Mate image viewer. If this all works, then this would likely not be a gphoto problem, but I suspect it will fail)

This is what you should see if gphoto completes the task successfully (not that because I do not have a Canon, but a Nikon, the file is called Test.NEF):



If you are paying close attention to the Terminal after pressing 'Enter', you will briefly see a download bar/notification appear that gphoto is now downloading and saving the file. As you can see from the screenshot, the file will now appear as Test.NEF in my Pictures folder and EoM shows a red image (since my telescope has filter mounted and it is just pointing at my wall inside the house).

If you now repeat the last command again, i.e. take the picture and have it downloaded (you have to close the image window first, because that process is still running in the terminal), gphoto will note that there is already a picture present with the same name and ask you whether you want to overwrite it or give it a new name. That in itself is not important, what is important is that gphoto saves an intermediate tmpfile until you have made up your mind about what to do with it:



It is this tmpfile I am interested in, because the size of it will tell us whether gphoto starts to download the file from your Canon and then gets overwhelmed by the size and aborts, leaving a truncated tmpfile behind, or whether it doesn't start at all. If it doesn't start at all, this would point to a driver problem inasmuch as there is an issue with initiating the download of a full size RAW file, and then that would indeed be a problem for the gphoto development team. If it, however, downloads the file in part and then aborts along the way, that might suggest to me that the Pi3 hardware can't handle the data influx from the large file and crashes at that point.

Do this with the camera settings at sRAW, mRAW and RAW. According to what you wrote before, sRAW and mRAW files were no problem, so they should complete in this simple test as well, while full RAW images crash the program.

It would be interesting for me to see what happens. I would predict that you will end up with a tmpfile of approximately 35MB when you use full RAW and gphoto gets stuck.

Bonne chance!

Jo

Thank you very much Jo for all these inputs,

Well i am just cooking the dinner (making my head to breath a bit out of gphoto & rpi3 !! loool) - i will look better your inputs in a few...

my morning message was related to the issue i open on GIT regarding gphoto2 in fact, where i attached the debug file.
You can read the exchnage and see the file there : github.com/gphoto/gphoto2/issues/127
(i just recently send a new message with the new debug file...

the "unknow event" is trange but i see them also when it is a success with the jpg. The trouble is after that and after the exposure...

I am right now trying to install a ubuntu astro (astronomy linux distrib) to a hardrive and i will try it on my laptop (to see if the laptop has same issue this would take out the rpi3 possibilty)

hoping Marcus or other people could check from gphoto2 side ..
I will come back to your message later tonight
thank you very much for taking time to look & remember your experiences

That's what I was also driving at:



The problem is likely file size related. Since you are using a full frame Canon, your full size RAW files are larger than the images most other Canon users here are dealing with, so they don't encounter the problem.

The tmpfile should then tell you where in the transfer gphoto aborts.

There is another test you could do: Just try to download large full size RAW files from the memory card of your Canon 5D3. If that also fails then this has nothing to do with the capture process per se, but with the file transfer process from the camera to the Pi/?communication speed?.

Here a link to all the relevant gphoto commands:

gphoto.org/doc/manual/ref-gphoto2-cli.html

And here a link to a somewhat older, but still informative, youtube tutorial on communicating with your camera:

Muchas gracias otra ves Jo !

So i did many tests .. and the results are ... weird ! .. here the thing :

dev-driver (2.5.15.1 & 2.5.16.1) :
RAW/mRAW/sRAW => Err70 on the camera, and tmpfile=0ko
JPG => OK fully

stab-driver (2.5.15 & 2.6.16)
RAW = blocked at some % like 26% (see file : tmp-RAW-stab-blocked) size 3.1Mo
mRAW = fully ok (see file : tmp-mRAW-stab-OK) size 8.3Mo
sRAW =!!! blocked at some % like 30% (see file :tmp-sRAW-stab-blocked) size 2.6Mo
JPG = fully ok (see file : tmp-JPG-stab-OK) size 655ko

Very strange to see the sRAW doesn't pass !!! And i did the test 3x for each format, and i get the same result each time, with same size of tmpfile !

hope you can see things there

Pask

OK, I admit defeat! This has got to be a 5D3 specific driver problem.
Jasem always wins.. )
But I suspect/hope, this will help the gphoto team to figure out what they need to change in the driver.
Please let us know if you see the same behavior when you test gphoto file transfer on your laptop or if any of the numbers change.
The only thing I still don't understand is that in your previous post you stated that an image was transferred and rendered when you used mRAW and sRAW. Not sure how I can reconcile that with these tests.
Anyway, thanks so much for you extraordinary patience with me. Hopefully these driver issues will be resolved soon.
Best
Jo

Well thank you Jo for your time and explanation!
I learnt a lot about the gphoto lib with this and it's highly appreciable. !!

So you right in mRaw & jpg it was all OK (except with the dev-driver that i found today) -- but honestly i did not try the sRaw before, for me if mraw&jpg were fine the sraw should have beeen also....
But making the full detailed test for the tmpfiles.. i discovered the sraw doesnt pass to the rpi3 ! Strange....

I posted the same results to gphoto issue team.. keeping finger crossed it will give thdm some ideas !

I will keep posted any progress here for the sake of the community and if anybody has the same issue .. (i would love to know if anybody with 5d3 & pi3 get same results btw ..)

Best regards,
Pask

I have to tell, that i have the same Problem from today on. Worked like a charme since about 5 months, but today the issue began. Cant save file, file is no raw image, everything like discribed in this thread. The only thing i made was a system-update... no way to get a preview...

Cheers Niki


Gesendet von iPhone mit Tapatalk