Hi there,
since I switched to 2.6.0.14 my framing wizzard does not load a picture. I only geht the error picture with these asiatic symbols. Maybe one of the items that didn’t get upgraded correctly?
Before I was using a 2.5.x.x.
Regards,
Kai
This is not possible, the MFW does not have pieces… it’s just part of the application. This is the only known complaint against the MFW with respect to 2.6.0.14 so the issue you are seeing is likely local. I would start by clearing your MFW cache, by selecting “clear cache” from the Object drop down in the MFW window. If that doesn’t work, please reproduce the issue and send a screen shot and logs.
Hello Ken,
thanks for your answer. To clear the cash didn’t change a thing. I have the issue with two computers. With win7 notebook and a win10 PC. Here is a part of my logfile. Do you need more information?
Regards,
Kai
Logfile: http://photonenfangen.de/dowload
The good thing is, the issue is very easy to reproduce:
- Start SGP
- open MFW
- put in an object name (M42)
- press fetch
Kai
Unfortunately it doesn’t seem to be that simple. If it were that simple, it would not have been released (I hope). Several people are now reporting this (some intermittently). Because of the intermittent failure, part of me is wondering if it is something to do with the underlying services. Anyhow… hoping to see some other logs too. When I perform the steps above, I get this (what FoV are you using?):
Hi Ken,
was trying to get more information on the FoV. So far I used typically 2 to 5 degrees successfuly. No I checked 4,3,2,1 degrees with the error. Slightly distressed I tried 0.1 deg an it worked! Now I revelead that a FoW < 1 deg works correctly and a FoW>=1.0 produces the issue.
Hope that helps!
Kai
It me again. I played a bit. It seems now that the issue is with a FoV given in natural numbers (1.000 or 2.000), giving instead 1.990 or 3.990 works also!
Kai
Hi, The Fov Trick works for me as well.
Thanks for the workaround.
I bet I know what we are seeing here… I bet we are seeing a regional conversion issue for non-US(UK) machines. I think the FoV is possibly being requested with “3,” instead of “3,0”. This would certainly be a good reason as to why some users see it and some don’t.
So… 2.6.0.16 has some better logging in it that will hopefully allow us to find and resolve this error. If possible would you mind recreating the error scenario with that version and posting the logs? Thanks!
Ok Ken,
I was on a business trip offshore last week… If I understand well. Producing log files in our case will need 2.6.0.18? Then I will generate one as soon 2.6.0.18 is available.
Regards,
Kai
If you are able to reproduce this issue with 2.6.0.20 or better, it should have a bunch of debug information that might help us understand why you see that.
Hi Ken,
Yes the same with 2.6.0.20. I put the logfiles unter http://photonenfangen.de/astrophotography-and-equipment/download/. Hope it helps. Ask me, if you need more testing.
Regards,
Kai
Thank Kai,
Unfortunately the logs you posted were successful (presumably because you set your FoV to 2,1 degrees). Do you have logs for one that fails (presumably at 2,0 degrees)?
the log should contain two trials. The first one wih 2.0 and the secon one with 2.1. But I will generate a second log… Wait a few minutes…
Kai
Ok.
Now its getting interesting… I’ve put a new logfile on my server.
The strange thing is:
FoV 1,0 / 2,0 works not
FoV 3.0 works !?!?!?!? (not a joke)
FOV 4.0 works not
This is reproducible and you should have all cases in the log.
Cheers,
Kai
Thanks for the info. I see all the attempts now, but it is not entirely clear to me what is happening. The ones that fail for you seemingly never even make it to the point where we request the canvas. Will need to think about this one…
BUT, part of me is now wondering if this issue is related to possibly bad MFW cache items. If you have a spare moment, can you see if 1.0, 2.0 or 4.0 degrees fails for all targets or if it works for a target you are positive you have never used the MFW for…