BackyardEOS 3.1.0 Release Candidate 02 is ready for download

[admin]

BackyardEOS 3.1.0 Release Candidate 02 is ready for download.

 

Free upgrade from 3.0.x to 3.1.0 to everyone as usual.

 

Change log (from RC01)

- Weather Center C to F degrees conversion bug fix

- PHD dithering port number bug fix

- Image not displayed in Image Capture bug fix

- Maximum Aperture setting is renamed to Maximum Sensitivity and the default is now OFF.

- Minor performance improvement

- Testing on XP, Vista, W7, and W8

 

The "

Image not displayed in Image Capture bug fix" was a bit tricky to solved because there were 3 different issues leading to this bug; (1) cross thread method invoker failed sometimes, (2) the background worker failed to start on some computers, and (3) loading a jpg image failed sometime and threw an 'out of memory' error.  All 3 are fixed.  However, the out-of-memory error still occurs from time to time but it is not critical because the image was downloaded properly.  The error occurs inside .Net trying to update the image picture box <_ i continue to dig in hoping find a solution.>

This Release Candidate will NOT overwrite your current v3.0.x installation.

http://www.binaryrivers.com/download/setup-BackyardEOS-v310-RC02.exe

 

PLEASE REPORT ISSUES using RC02 in this thread.

 

Thank you,

[Ron Hillstromb]

Thanks

 

  I got out last night and had some scope time with RC02.  The .jpg recording worked fine* on short exposures.  I was playing with Saturn in some cirrus and used 1/15 sec as the longest single frame.

 

  When I went to M57 and used 30 sec.  The first frame of the initial 3 frames wrote the .jpg but all the rest were not transferred but left with the img xxx in the download folder.  All .jpgs after that did not write to the target folder but only to the Download folder as IMG XXX.

 

* all .jpgs transferred still had different xxx ms in the tile and one or two had a later sec.  The differences are not uniform but on the order of 500 ms +_ 50 ms.

 

  I did not have time to work up to see where the problem started.  If I get a chance to get out tonight I will start at 1 sec and go down to shorter exposures, probably with Saturn as a target, and report the outcome tomorrow.

 

  Logs are available but expect them to show the same pattern as the logs sent yesterday.

 

Ron

[admin]

Thanks

 

  I got out last night and had some scope time with RC02.  The .jpg recording worked fine* on short exposures.  I was playing with Saturn in some cirrus and used 1/15 sec as the longest single frame.

 

  When I went to M57 and used 30 sec.  The first frame of the initial 3 frames wrote the .jpg but all the rest were not transferred but left with the img xxx in the download folder.  All .jpgs after that did not write to the target folder but only to the Download folder as IMG XXX.

 

* all .jpgs transferred still had different xxx ms in the tile and one or two had a later sec.  The differences are not uniform but on the order of 500 ms +_ 50 ms.

 

  I did not have time to work up to see where the problem started.  If I get a chance to get out tonight I will start at 1 sec and go down to shorter exposures, probably with Saturn as a target, and report the outcome tomorrow.

 

  Logs are available but expect them to show the same pattern as the logs sent yesterday.

 

Ron

 

Please post the log files.  There is not much I can do to find/fix the issue without them <_>

 

This bug is the only one preventing me from releasing 3.1 in production so the more feedback/log files I get on it the better.

 

Thank you for testing.

 

Regards,

 

 

[Ron Hillstromb]

Here is the Backgroundworker log.

 

  The 'regular' log exceeds the 256 KB limit.  do you want me to send it to Backyard EOS site.  I forgot the address but I have other files I have sent to you and can get it from them.

 

I will go back out and try to find the start point of the .jpg problem.

 

Ron

logfile-[20140723-21h11m24s673]-backgroundworker-[3944]-2014-07-23.txt

[admin]

Here is the Backgroundworker log.

 

  The 'regular' log exceeds the 256 KB limit.  do you want me to send it to Backyard EOS site.  I forgot the address but I have other files I have sent to you and can get it from them.

 

I will go back out and try to find the start point of the .jpg problem.

 

Ron

 

Yes, send it to support@binaryrivers.com.

 

Guylain

[dts350z]

With RC2 last night the images were taking a LONG time to load back into BYEOS. We're talking 3 to 4 minutes. 

 

I know it wasn't download delay, because Astrotortilla acted normally. Very quick processing start after shutter close.

 

Apps running at the time:

 

Stellarium scope

Stellarium

BYEOS

Astrototilla

 

New Dell Ultrabook running windows 7 Enterprise 64 bit with 8Gb of RAM.

[admin]

With RC2 last night the images were taking a LONG time to load back into BYEOS. We're talking 3 to 4 minutes. 

 

I know it wasn't download delay, because Astrotortilla acted normally. Very quick processing start after shutter close.

 

Apps running at the time:

 

Stellarium scope

Stellarium

BYEOS

Astrototilla

 

New Dell Ultrabook running windows 7 Enterprise 64 bit with 8Gb of RAM.

 

Send me both log files.

 

In v3.1 I'm using a commercial library to load raw image data (GdPicture).  I'm thinking now that this might not have been the best decision on my part if indeed this is the root cause.  If this is the case I spent $1000 for a library that is not necessarily the best for what i'm using it for <_>

 

I'm now looking at using DCRAW to load images... which is retrospect may have been the best choice to begin with.  My tests with DCRAW are promising so far.  If all goes well I'm probably release RC03 with DCRAW as the default tool to load raw data.

 

Please send me both log files and I'll confirm the cause.

 

Regards,

[PoppaChris]

Here's waiting with fervent anticipaction for this final bug to be worked out and the full release to be issued.  I'm like a kid peeking into a candy store window.

[admin]

Here's waiting with fervent anticipaction for this final bug to be worked out and the full release to be issued.  I'm like a kid peeking into a candy store window.

 

LOL

[admin]

I have locked this thread because BackyardEOS v3.1 RC03 is released and ready for download.

 

http://forum.otelescope.com/post/backyardeos-3-1-0-release-candidate-03-is-ready-for-download-7017967

 

Thank you

[s3igell]

Looking Good...  At least initial Download and Install...

  (No problems with Norton AV "File Insight" "Reputation Scan" (RC01 required Norton to be Shut Down - "Unknown Reputation" is treated worse than "Infected" as such "Unknown" files are Removed instead of just Quarantined...))

 

Installation interestingly picked up my customized Directories defined in v3.0.3, but reverted all other Settings to Default values.  (It took a few minutes to compare/contrast Settings v3.1.0rc2 vs v3.0.3, due to both Settings Forms bringing their Parent App Windows to Foreground.  Luckily, with a large high-res LCD I could resize and reposition windows so as to see MOST of the settings values for comparison purposes.)

 

I noted a few oddities in the Default Settings assigned for v3.1.0rc2:

 

Advanced Settings:  "Skip WRITE EXIF Data" is Checked ON, as is "Ask for Camera Drivers".

What is the new Advanced Setting "Progress Wheel Blink" ??

What happened to Advanced Settings:  Camera Auto-Connect and Planetary JPG Only ??

What happened to Experimental Settings:  Allow 10x Zoom and Virtual Mirror Lock ??

Some Desktop Imaging Tests to follow later this afternoon...

 

Thanks again for the Combined Effort to see BYE v3.1.0 out into Beta while still managing an active Beta for BYN...

 

[admin]

Looking Good...  At least initial Download and Install...

  (No problems with Norton AV "File Insight" "Reputation Scan" (RC01 required Norton to be Shut Down - "Unknown Reputation" is treated worse than "Infected" as such "Unknown" files are Removed instead of just Quarantined...))

 

Installation interestingly picked up my customized Directories defined in v3.0.3, but reverted all other Settings to Default values.  (It took a few minutes to compare/contrast Settings v3.1.0rc2 vs v3.0.3, due to both Settings Forms bringing their Parent App Windows to Foreground.  Luckily, with a large high-res LCD I could resize and reposition windows so as to see MOST of the settings values for comparison purposes.)

 

I noted a few oddities in the Default Settings assigned for v3.1.0rc2:

 

Advanced Settings:  "Skip WRITE EXIF Data" is Checked ON, as is "Ask for Camera Drivers".

What is the new Advanced Setting "Progress Wheel Blink" ??

What happened to Advanced Settings:  Camera Auto-Connect and Planetary JPG Only ??

What happened to Experimental Settings:  Allow 10x Zoom and Virtual Mirror Lock ??

Some Desktop Imaging Tests to follow later this afternoon...

 

Thanks again for the Combined Effort to see BYE v3.1.0 out into Beta while still managing an active Beta for BYN...

 

 

The advance settings did not changed in the RC, they are the same.

 

EXIF Write is now OFF by default.

 

I find it odd that your folder settings crossed over.  The only way this can happen is if you installed in an existing folder where BYE was installed previously.  I see no other way <_>

 

10x zoom is if you want the option in planetary.  Not recommended due to loss of quality.  For this reason is is off by default.

 

EDIT: The Progress Wheel blink option will have the progress wheel blink once every 2 seconds instead of spinning.  On setup where battery consumption is a an issue this should help a little bit.  This was requested by a user. 

 

Regards,

 

 

[dts350z]

Maybe this should be a "How To" for planetary?

 

 

 

[admin]

Maybe this should be a "How To" for planetary?

 

 

 

Yeah, it should

[Jerry_K]

Guylain,

English is my second language but shouldn't "Maximum Aperture setting is renamed to Maximum Sensibility" be "Maximum Aperture setting is renamed to Maximum Sensitivity"? It just doesn't sound right

Jerry

[admin]

Guylain,

English is my second language but shouldn't "Maximum Aperture setting is renamed to Maximum Sensibility" be "Maximum Aperture setting is renamed to Maximum Sensitivity"? It just doesn't sound right

Jerry

 

Yes it should, English is also my second language

 

The setting is actually called Maximum Sensitivity, the error was in the thread, not the application... phew

 

Regards,

[dts350z]

Maybe this should be a "How To" for planetary?

 

 

 

Yeah, it should

 

Strange. I thought I posted that in this thread:

 

http://forum.otelescope.com/post/saturn-help-6998131?pid=1283639889

 

but now it's in the RC02 thread. Anyway, the Saturn thread was what I was referring to.

 

 

 

[Jerry_K]

Guylain,

English is my second language but shouldn't "Maximum Aperture setting is renamed to Maximum Sensibility" be "Maximum Aperture setting is renamed to Maximum Sensitivity"? It just doesn't sound right

Jerry

 

Yes it should, English is also my second language

 

The setting is actually called Maximum Sensitivity, the error was in the thread, not the application... phew

 

Regards,

 

Yah, I noticed that minute after sending off my comment after I downloaded the Candidate 02.

Looks good but cloudy skies will not allow me to test it.

Jerry

[Ron Hillstromb]

  I am having problems with RC02.  I save RAW + jpg and the jpgs are not always being saved in the folder with the raw and txt files.  I do find them in the Temp/download folder.

 

  When the jpgs are saved to the folder they do not have the same file name as the others.  I have always used the xxx ms to match the cr2 and jpg images.

 

  The same problem happens on an I-7 Win 7 and I-5 Win 8.1 Surface Pro.   It occurs in random fashion but the jpgs are not saved more times than being saved to the folder..

 

  On the positive side the Background processor does let me execute a second multiple exposure plan while processing the first.

 

Backgrounder log file attached.

 

Ron

logfile-[20140723-14h13m31s794]-backgroundworker-[1972]-2014-07-23.txt 

[admin]

  I am having problems with RC02.  I save RAW + jpg and the jpgs are not always being saved in the folder with the raw and txt files.  I do find them in the Temp/download folder.

 

  When the jpgs are saved to the folder they do not have the same file name as the others.  I have always used the xxx ms to match the cr2 and jpg images.

 

  The same problem happens on an I-7 Win 7 and I-5 Win 8.1 Surface Pro.   It occurs in random fashion but the jpgs are not saved more times than being saved to the folder..

 

  On the positive side the Background processor does let me execute a second multiple exposure plan while processing the first.

 

Backgrounder log file attached.

 

Ron logfile-[20140723-14h13m31s794]-backgroundworker-[1972]-2014-07-23.txt     

 

I'll check the jpg/cr2 not having the same name by a few ms.  They should be the same so this is probably a bug.

 

As far as missing jpg you have a lot of "WARN  - The process cannot access the file because it is being used by another process." warning in your log file.  I'll investigate.

 

Thank you,