Totally bizarre SLL bug

[aparker]

So I finally got a clear night to go out and play with the scope.

I had set up a new USB cabling configuration, running short cables form Ultrastar, finder, and filterwheel to a mini USB hub actually mounted on the telescope, so there was only one cable running off the OTA to the powered extender cable I run to my laptop (this is really a subject for a different post, but I mention it here because it was a change I made before I ran into this perplexing SLL behavior).

So I fire up SLL (v1) and use it in focus/frame mode to run through the mount alignment per my usual process.  No problems here, everything worked as it always has.  I then switched the filterwheel to the blank filter and went to take darks, and clicked the "Dark Frames" tab, and went to exposure control.  Set my exposure (15 sec) and clicked the green arrow.  The software started running exposures (progress bar was moving), but the counter did not increment (never moved off of 0 dark frames).  After a few seconds the progress bar stopped and the software became unresponsive - no screen controls worked and had to be force-quit.

I re-started the application and tried the light frames acquisition mode, with the same result - counter does not increment, then software freezes.  As a minor observation, right at the end of the first "exposure", the SLL window would flash a bit and the "Image Acquisition" button (rightmost of the three at lower left) would lose it's darker grey "selected" state and revert to light grey. 

So I re-started the app again and tried the focus/frame mode.  This still worked normally.

I then went through the usual permutations:

Rebooted the computer (I was running OSX 10.11.1)

Tried SLL v2.0

Reverted the cabling setup back to the way I had it before.

Rebooted in safe mode.

Disconnected all other peripherals and wired the Ultrastar straight to the laptop.

Downloaded a new copy of SLL from the SX website.

Updated the OS to 10.11.3

NONE of these produced anything other than the first observed behavior - Focus/frame mode works, the other two modes hang.

 

I am at my wits end - the fact that both versions of SLL exhibit the problem STRONGLY leads me to suspect that the issue is that something changed with my laptop, but I'll be darned if I know what it is.  The software update log indicates a couple of trivial auto-updates since the last time I used SLL successfully.   

 

I'm out of evening now, but can think of at least two other things I could do:  1. bring my work laptop home, install SLL, try it out.  2. hook up the old Lodestar and see if it behaves the same way.

 

Paul, when you read this, if you have any suggestions I'd be very happy to try them out (once I get another night with at least some stars out).  At one point I think there was mention of a way to launch SLL from the command line and turn a logging function on.  Happy to try this if I can get instructions.

 

If anyone else has ideas for other things I could try, I'd love to hear those too.  Sadly it looks like I'm out of the EAA game until I get this resolved...

 

[aparker]

One other thing before I forget.  Right before the above ordeal began, I used the "F3" key to find and pull back a "lost" application window (PHD Guiding) that was off-screen because I had last used it with a second monitor plugged in.  So there were two notional "desktops" active from the OS's point of view.  I can't see how this would affect things, but I mention it because it is something I did that is outside of my normal routine when using SLL.

[RobertI]

The main problem I have had with V1.1 (not sure about V2.0) is when using switching on the live preview window and having it display on another monitor (by extending the desktop) the s/w will slow right down to the point where it seems to freeze. This only seems to happen when exposures are very short say a few seconds (sorry I never reported this Paul, I never had time to test the conditions properly). Did you try running the s/w with the live preview window disabled?

rob

[aparker]

Rob,

 

I'm not sure I know what you are referring to re live preview window.  I only ever use SLL as it starts up out of the box, with the main window that the image ultimately appears in active.  I do not know how to disable that.  Is there a different function that you are describing?

 

Thanks

 

alex

[aparker]

So a few more experiments.

Tried the old Lodestar with my laptop, same software freeze problem.

Took the Ultrastar to work, DL SLL onto the work machine (running OSX 10.10.2), works great (at least it will run and collect darks without freezing).

So it looks like the problem is my laptop.  But what about my laptop?  I updated to 10.11 (El Capitan) quite a while ago, and had run SLL successfully under 10.11.1 multiple times, so that's not it.  I suppose maybe it could be a result of touching this weird multi-desktop function which I never normally use, but I'm amazed that this could cause some permanent change to the OS that persists through rebooting.  

I suppose I could figure out how to do a clean slate OS reinstall and try that, even back up to Yosemite, but I'd hate to have to go through resetting all my configs and reinstalling all the software I like to use...

Any other ideas?

 

[Martin Meredith]

Hi Alex

By live preview, maybe Rob means the Repeat Image Window (half way down the settings tab)?

Since you're desperate for possible solutions, my only thought is that you might have some other process running that has 'control' of the camera (though that would be odd since you've rebooted -- but worth checking via Activity Monitor or similar). I've noticed that if I have Nebulosity running weird things can happen (and Neb also leaves open windows way off screen when I unplug an attached monitor). Since you mentioned PHD I wondered whether something similar could be happening.

What is the status of the camera connected icon (lower left corner) when all this is happening? Does it change to a cross when you're collecting darks?

I have access to El Capitan 10.11.1. I'll plug the Lodestar in and see what I get soon.

[added in edit: just downloaded a fresh SLL v2.0 from the SX website and a fresh PHD Guiding; as expected, if PHD is the first to be opened and has control of the Lodestar, SLL does nothing; but closing PHD immediately makes the Lodestar available to SLL. In short, I tried various combinations but couldn't reproduce your situation under Capitan 10.11.1.]

I can only wish you good luck in finding a solution -- it sounds terribly frustrating!

Martin

[aparker]

Thanks Martin,

 

In every case the SLL camera connect icon is a positive - check not X.  My routine is always to start PHD and connect it to my Orion guide camera before starting SLL and letting it connect to the Lodestar.  I have been running the two in tandem for over half a year now.  I am thinking I'm just going to back my machine up and do a clean reinstall of the OS this weekend.  Hopefully that fixes it!

[RobertI]

3 hours ago, Martin Meredith said:

By live preview, maybe Rob means the Repeat Image Window (half way down the settings tab)?

 

That's what I meant!  Sounds like a red herring though, sorry.

[Astrojedi]

Alex,

From the symptoms it looks like you may invalid directories setup in the Image export and darks tab.

Make sure in Starlight Live you have valid directories selected for image export and for saving darks and you have enough disk space. Starlight Live always hangs on me if I delete the directory I was using to capture images in the prior session.

If that does not work try uninstalling drivers if any that you may have installed for the USB hub, filter wheel or SX cameras and peripherals.

Hiten

[Paul81]

Hi Alex,

Hmm.. This is a strange one indeed. I am tempted to side with Hiten's good suggestion in that maybe Image Export is enabled to an invalid directory or one that can't be written (even if it's not - thanks for the bug report I will investigate that one!).

I have read El Capitan has caused issue with other USB camera programs, and I have seen there are some bug reports with libUSB (the library I use for low-level USB comms on OSX), but given this is the first issue of this type reported and it worked before I am tempted to say its not that.

To enable the logging, launch terminal and (assuming SL is installed in your apps folder) type:

open -a StarlightLive --args -enable-logging

When it runs it will create a text file in your home directory - if you can send me the contents (or post it here) it may offer some further clues.

Definitely check to see if export is enabled, and try disabling it if it is enabled.

Let me know how you get on,

Paul

[aparker]

3 hours ago, Astrojedi said:

Alex,

From the symptoms it looks like you may invalid directories setup in the Image export and darks tab.

Make sure in Starlight Live you have valid directories selected for image export and for saving darks and you have enough disk space. Starlight Live always hangs on me if I delete the directory I was using to capture images in the prior session.

If that does not work try uninstalling drivers if any that you may have installed for the USB hub, filter wheel or SX cameras and peripherals.

Hiten

Hiten - that's an interesting idea, and one I did not check explicitly.  I did do one experiment where I downloaded a fresh copy of SLL where there should have been no directories set at all, but perhaps there was a hidden config that I am unaware of.  Thanks very much for your input!

[aparker]

1 hour ago, Paul81 said:

Hi Alex,

Hmm.. This is a strange one indeed. I am tempted to side with Hiten's good suggestion in that maybe Image Export is enabled to an invalid directory or one that can't be written (even if it's not - thanks for the bug report I will investigate that one!).

I have read El Capitan has caused issue with other USB camera programs, and I have seen there are some bug reports with libUSB (the library I use for low-level USB comms on OSX), but given this is the first issue of this type reported and it worked before I am tempted to say its not that.

To enable the logging, launch terminal and (assuming SL is installed in your apps folder) type:

open -a StarlightLive --args -enable-logging

When it runs it will create a text file in your home directory - if you can send me the contents (or post it here) it may offer some further clues.

Definitely check to see if export is enabled, and try disabling it if it is enabled.

Let me know how you get on,

Paul

Thanks Paul - I'll try getting some log data tonight.  Alex

[aparker]

So Hiten wins the guessing game on this one - indeed it was due to the fact that I had moved the directory that I had been previously saving FITS files into.  I ran the app once before directing it away from the non-existent directory just to record a logfile while the bug occurred (file attached), then pointed the app to a directory that did exist and voila, everything works again.  Thanks for your help, everyone.    StarlightLive_Log_2016.01.28_19.35.14.txt

[Paul81]

Superb news! 

To clarify, what should happen is a dialog appears to say an error has occurred during the raw FITS save, but for some reason that is getting lost (maybe on another desktop?). I'll make it just simply carry-on (i.e. a non-critical error).

I will get this fixed in V2.1 - it's a simple one to rectify!

All being well I should have V2.1 ready on Sunday...