Ken, your reply to me back in March regharding the crashes due to taking flats was …“We don’t technically support all aspects of UNC path naming. Can you please map your file destination to a driver letter and use that instead?”
This was why I tried mapping a drive to my server which did not help the problem. Here is the thread:
Yes, I recall that. I still stand behind that and my question still stands. My point is that a mapped drive letter AND a UNC path both save data directly to the network drive. The way you phrased your sentence made it sound like you might have switched to saving to a local (letter) drive.
I misunderstood that you wanted me to assign a drive letter to my server drive. Fact is all LRGB data saves fine directly to the network drive or the mapped network drive with no crashes. Only the flat has the issue. I will try to run his evening by saving flats to the local PC drive. Let you know the outcome.
So… this is not going to be super awesome to track down and fix. The fact that you have a tiff file means that DCRAW did what we asked it to do, but somehow the inter-process communication caused SGPro to crash. I set up a test program that calls DCRAW as many times as it can for 5 minutes (on your RAW image)… no failures, no crashes.
With this data in hand, I started doing what experienced, well-groomed software engineers are trained to do… began guessing.
Here is what I pulled out of my ass for this latest try:
This seems to work fine on a T1i… I am not currently in possession of the 6D. It will be variable in 2.5.1.9
Looks like at least one of your guesses has gone viral.
Won’t save any images. Tried both 6Ds, same result.
Ya. . Tested this on another machine. Looks like an issue with forcing processor affinity. Might not be compatible with all machines. I’ll release a version that returns control of this to the OS, but keeps all the other changes.
Saving images works fine again with 2.5.1.10, but crashes still occurring.
First run was looking great: It got to 25 images with 5 second delay and looking good, so I lowered the delay to 1 second and it kept on going to 50. At that point I lowered the delay to 0 and it crashed immediately.
Started it again with 1 second delay and it crashed on third image.
Started it again with 5 second delay and it crashed on second image.
Thx for the report… as suspected, this is going to be super awesome to track down. The DCRAW memory usage pattern (at least the final number) appears to be the same for successful conversions:
[5/2/2016 8:38:52 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 811008
[5/2/2016 8:38:52 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 22642688
[5/2/2016 8:38:53 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 39096320
[5/2/2016 8:38:53 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 42377216
[5/2/2016 8:38:54 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 164274176
For unsuccessful conversions, we seem to get only a single (reasonable) report, then it craps out:
[5/2/2016 8:38:59 AM] [DEBUG] [Sequence Thread] DCRAW Physical Memory Usage: 729088
So… there are basically two possible root causes here:
I ran the Flats again and got to frame 43 before the crash. I did lots of UI manipulations throughout.
Did not notice any unusual memory usage at the end. It built up to 280mb early on, stayed there throughout with a blip up to 360mb once for each frame.
Running pretty low on ideas… Can we consolidate what we know?
Did I miss anything? Any other DSLR users seeing this type of behavior?
Since you cannot reproduce this with your 6D, and it happens for me on both of my 6Ds, I conclude the following additional ideas:
It might help for you to detail the pc’s you have tried this on with your 6D. For me I have always been using my obs pc which is Win 8.1, quad core, 8gb.
This morning was not the best time for a 5 hour power outage in Taos, since I was in the middle of running some new tests. Last I saw it had successfully reached around 50 frames with a 12 second delay, taking 6.5 seconds for processing/download. Hopefully I can get reconnected to the internet before I go down next week.
Both my 6Ds are currently in Taos and I am in Colorado but will be down there next week and I will bring both 6Ds back with me. Here in Colorado I have several pcs I can test it on. When I go down I will test it on my Win 10 notebook.
In any case, I will be able to test both 2) and 3) which may help pin this down.
For the other users that have run into this problem, I think it would help if they could detail for us their hardware/software configurations, including OS, pc details, camera model.
REVISION: Run above finished all 120 frames just fine.
I have tested on Win 7 (64) and Win 10.
Hi Ken and jmacon,
I am fighting with what seems to be the same issue, only my camera is an STT-8300 with self-guiding filter wheel. I have not monitored the memory usage, but other bullet points “seem” to be true. When this happens, you actually see the images try to download faster, and the files get out of whack in the directory (that is, one frame number is skipped and an already used one with the “-01” suffix shows up instead. I have attached a log associated with this behavior as well as an image of the directory.
At some point, then, SGP stops working and Windows says it is closing the program and will look for a solution.
The same thing happens with short-ish exposure flats, but for the most part, I have been getting around this by taking them in rotation instead of sequentially, and that works almost always.
All of this has been replicated on and off the scope with two different laptops, different cables and different power supplies.
I also started a new thread with something I have started seeing recently… an alert showing SBIG Shutter Error… I am guessing that the issues are separate, but I am not sure.
For reference, I am running 2.5.0.23 and latest drivers from SBIG under Windows 7 Pro.
Thanks and regards,
Craig Smith
“Seems to be” is the operative phrase here… I’m not sure what issue you are encountering, but it is not related to the DSLR issue above (concerning usage of DCRAW).
Not sure what this means or how you are able to see this…
I’ll take a closer look tomnorrow.
Ken,
Fair enough, thank for the clarification. I thought I saw mention of (or question about) an 8300 chip earlier in the thread.
As far as the other intangible observation, I was referring to watching the bias frames being captured and downloaded. There is something of a rhythm to the process. You can see that process speed up (it doesn’t spend as much time downloading) when the subframes get mislabeled and also before SGP “crashes.”
For clarification, I believe that this a different issue that the other thread I started since this reliably replicates on different laptops and without any hubs or other devices in the way.
I guess the only other possibility is a camera or driver issue… SBIG drivers are all up to date.
Thanks again,
Craig
After imaging last night I added a 5 second flat sequence to the existing one after finishing. SGP crashed on the first flat. I restarted SGP and got to the second flat when it crashed again. Should I not add a sequence to an existing one on the fly? I saved the flat to the c drive this time as per recommendation with no improvement. I changed the type from flat to light and it worked fine for 15 “flats”. WIndows 7/SBIG camera.
In the interest of tidying up threads, this issue (as encountered by my STT8300) was resolved as of 2.5.1.17. There was also another release of an SBIG driver, so I’m not positive as to whether the SGP update did it alone, but it clearly is fixed.
Thanks a bunch!
Craig