I just took a look.   It looks like Hannah or somebody else did update libsamplerate.  So I copied in their changes.  Try it now, it might work better.

Read More...

I just checked on my system.  The command "craft -vi libsamplerate" in the craft environment builds it fine on my computer.  I am running Big Sur and on my system, Carbon.h is found at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Carbon.framework/Versions/A/Headers/Carbon.h

Is it there on yours?

Read More...

Yeah we may want to see if we can change the build to avoid this since audio, the GUI, or carbon should be needed at all for indiserver which is what it looks like was building at the time based on your post.  I think the reason it got included was probably ffmpeg, which is needed for the INDI Webcam, but we don't need those features of it.

Read More...

Hi there John,

I don't recall any issues with libsamplerate.  I also don't think it should require Carbon.  Wasn't that the old OS X GUI from way back?  What system are you building on?

Thanks,

Rob

Read More...

Thanks for the info.  I hope to get to the bottom of it.  It’s difficult though because it’s an issue with INDI and KStars communication of data not a clear issue with one or the other.  And it’s intermittent, only occurring under certain circumstances and we still don’t know exactly what the circumstances are.

Read More...

Well if you got a crash on disconnecting INDI server, that is a cross platform bug and is already under investigation.  I’m specifically focused on this INDI startup bug since that seems to be a Mac issue and is new as far as I know.

Read More...

John, you said it was just as I described.  Did you try removing the Guide Simulator from the Simulators profile or connecting to an already running INDIServer.  Did it not crash under these conditions as I found?  Also you noted that it didn't happen in 3.5.4, I think I downloaded the old DMG for 3.5.4 and tested it in my experiments yesterday and I think it crashed for me.  I will have to go back and try that again.

I guess the next question is what is different about my computer and John's computer vs. Simon's and Ryan's computer.  And the next question is why didn't this happen in the past but seems to happen now, what changed?  It is mysterious.

Thanks,

Rob

Read More...

Hello Fellow Mac users,

I recently built a DMG for testing the Mac build before the release of 3.5.5.  I was planning on sending this out on this forum about a week ago.  After I built it though, I found what may be a very significant bug.  So I asked for a delay in the 3.5.5 release.  I am not sure that it is actually a bug, however, it may just be some configuration issue specific to my machine.  But if it is really a bug, we should try to get to the bottom of it.  I haven't yet been able to determine a cause, but if. some folks can test to see if they have the same issue, then that might really help.  So I guess there are really two points to this beta:

1. Please, as usual, test to see that everything works well for the release in the Mac build.  Let me know of any Mac specific issues such as things not working like they do on Linux, dbus not working properly (such as in the scheduler or scripting), INDI drivers not included as they should be, or other similar issues.  Keep it just to Mac issues that are specific to this DMG please since I have my hands full right now.  As far as I can tell the bug below is the only significant issue holding us back and it shouldn't affect anyone actually doing deep sky imaging with real equipment.

2. Please, if you are willing, test to confirm the bug that I found, and maybe if you can find the conditions under which it might occur on your machine.  The bug is as follows:  If KStars locally starts up an INDI server (not connecting to one already started) that includes Guide Simulator, KStars crashes on the INDI Server startup.  At least in my testing, it seems if the INDI Server is already running or if the Guide Simulator is not included in the profile, the crash does not occur.  Incidentally, this does mean that if you start up the INDI Server in the Simulators profile from KStars with Guide Simulator included and it does crash, the INDI Server will still be running, so if you start up KStars and try the same experiment again, it will look like it works fine if you connect to the already running INDI Server.  So to test a second time, when that popup comes up that says and INDIServer is already running, you would need to tell it to start up a new one, then the crash may occur again.

The beta is posted here:  www.indilib.org/jdownloads/kstars/beta/kstars-3.5.5-beta2.dmg

Thanks,

Rob

Read More...

Fabio Papa,  that makes a lot more sense.  I didn’t understand why you would be saying that blind solves were impossible when I know that they are and that was a major focus of my work last year.  You meant blind solves were not possible in Ekos’s load and slew function.  I do think this needs to be fixed in Ekos and Jasem said he will change that.

The Radius is only used when the position is given, so it doesn’t affect a blind solve.  That’s why it is in the profile, since it is not something you want to change regularly.  Basically you want it to use a radius if the position is close to accurate but if it is not known or if it is wrong, you probably don’t want to use position at all.  I would say if it is off by more than 15 degrees something is very wrong and a blind solve is needed.  Using a radius of 180 might work, but it has an equal chance of not working too.  Also I am not sure that a radius of 180 is much better than a blind solve.  15 is the default and has worked every time for me that I didn’t need a blind solve, if you prefer 180, you can change the profile on your machine.  It wasn’t my decision to use 15 degrees, that is the recommended number from the folks who made astrometry.net.

Another thing we have been discussing is that Ekos might want a fallback method for using a blind solve after an informed solve fails.  I think that would save a lot of people frustration and also having to turn off scale and position just to do a blind solve and then turn them back on later.

 

Read More...

Sorry that I couldn't log in here before, something was wrong with my password, but I have now fixed it.  Hopefully I have provided helpful feedback in the GitHub site.  I think I have fixed the first problem, the hard coding of the nova site should now be fixed.  If you are using a package manager to install stellarsolver or if you are using Windows with embedded stellarsolver, there will be a delay to update it.

I think there were a couple of questions here I didn't address on the other site, so I will try to answer them now.  

I am not sure what you mean by the internal solver can't blind solve, because that is one of the main things I worked really hard on last year during the pandemic, and one of the best features of StellarSolver is now that it can blind solves an image in less than a minute, often just a few seconds (depending on the image and computer of course).  It manages this by doing several things that really can speed up solving such as parallel threads on multiple cores.  Yes it can use a decent amount of energy and processing power, which is why you should only do a blind solve if it doesn't solve any other way.  Even the raspberry pi can do it, but it isn't as fast as other computers.

I agree that under 1 second true blind solve on a Pi as you stated is not likely at this time.  I typically use my laptop for solving images and controlling the session, where the PI is used for acquisition.  My main computer solves images with scale and position information in about 0.3 seconds or so, the pi might take a few seconds (unless it is a pi 4).  For blind solves it really really depends on the image.  Here is an example of StellarSolver solving an image in less than 2 seconds on my main laptop.   This is mostly a blind solve since the file is a JPEG, it has no idea about anything about the image.  The only information it has is that it should use the parameters in the "ParallelSolving Small Scale" options profile.  This profile does limit the scale to telescope sizes which makes it a bit faster, but if you don't limit the scale, it doesn't increase the time that much.  Other images will have different solving times since blind solving is blind, but typically it is less than a minute.  For a PI, the time estimates would be larger of course.

  

Good job!  Glad to hear you fixed it!

Read More...

Hmm, I'm not sure, as far as I can tell, the file I built today included this fix in the source code before building:

github.com/indilib/indi/commit/47d23904c...c5ca4e2d645cbd8935d0

and I checked that the DMG included the file that was built and they were identical (at least my computer said they were).

so I think that it should include this fix.

I can send this to Jasem and see if he has any ideas of what might be wrong.

Read More...

I agree, perhaps we can have an option that tries to solve once with using position and scale, if that doesn't work it can try again with just position, and if that doesn't work, it can do a totally blind solve.

Read More...