BackyardEOS 3.1.0 Release Candidate 01 is ready for download

[admin]

I've decided to release 3.1 sooner as Release Candidate 01.

 

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

 

I did not get the chance to compile a list of changes yet but there is very little UI change.

 

The huge change in this release is the way downloaded images and planetary AVI encoding are handled. These are now processed in a separate low priority Windows process... leaving more CPU cycle to the user interface.  As a result the UI is able to proceed to the next image even if you have selected BULB < 30 seconds. 

 

In BackyardEOS 3.1, IT IS SAFE to close BYE even if images are still in the queue (flashing number in Camera Information Center).  The new background worker process will continue working on them

 

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

 

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

 

PLEASE REPORT ISSUES using RC01 in this thread.

 

Thank you,

 

 

[Jim]

Guylain,

 

Just opened RC01 and in the PHD dithering settings it is defaulted to "localhost:4300". When tested it failed to connect each time. On looking in my previous version it was set to just "localhost". I amended the setting to just "localhost" and all worked fine.

 

Regards

 

Jim

[admin]

Guylain,

 

Just opened RC01 and in the PHD dithering settings it is defaulted to "localhost:4300". When tested it failed to connect each time. On looking in my previous version it was set to just "localhost". I amended the setting to just "localhost" and all worked fine.

 

Regards

 

Jim

 

Are you using PHD2 or PHD?

 

Thank you

 

 

[Jim]

PHD 2.2.2 on this PC.

 

Jim

[admin]

PHD 2.2.2 on this PC.

 

Jim

 

Are you sure PHD2 is on port 4300?

 

 

[Jim]

Guylain,

 

I don't know which port PHD 2 is on. I have not changed anything since I started using PHD with BYE some time ago (long before BYE version 3 and both PHD 1 and 2) and have never changed anything as PHD and BYE have gone from version to version.

 

I was surprised to see a port number in BYE 3.1 RC01 as there has not previously been a defined port in the PHD Guider settings of BYE, just "localhost".

 

Now I have changed BYE 3-1 RC01 back to being just "localhost" without a defined port it is all working fine (as far as the test button is concerned).

 

Regards

 

Jim.

[admin]

Guylain,

 

I don't know which port PHD 2 is on. I have not changed anything since I started using PHD with BYE some time ago (long before BYE version 3 and both PHD 1 and 2) and have never changed anything as PHD and BYE have gone from version to version.

 

I was surprised to see a port number in BYE 3.1 RC01 as there has not previously been a defined port in the PHD Guider settings of BYE, just "localhost".

 

Now I have changed BYE 3-1 RC01 back to being just "localhost" without a defined port it is all working fine (as far as the test button is concerned).

 

Regards

 

Jim.

 

Not a big surprise.  PHD 1 is hard-coded to port 4300 while PHD2 can have several instances on different ports; hence the new config in BYE.

 

I'll run a few more tests with with both PHD and PHD2 tonight.

 

Thanks,

 

 

[s3igell]

PHD2 listens to the same Port (starting at 4300) for the first Instance of the PHD2 Application, as PHD1 did. (Yes, PHD2 will allow multiple Instances - IF you manually start up those extra Instances.  Similar to BYE's multiple Instances.)  But, since BYE v3.x successfully connects to the "standard" (and almost always ONLY) Instance of PHD2 when the older "localhost" identifier is stipulated, is it possible that BYE v3.1 is having an issue parsing the ":4300" (or adding a non-zero offset to that value) ??

 

Hopefully, we'll hear that you've resolved the issue with your efforts this evening...

[admin]

PHD2 listens to the same Port (starting at 4300) for the first Instance of the PHD2 Application, as PHD1 did. (Yes, PHD2 will allow multiple Instances - IF you manually start up those extra Instances.  Similar to BYE's multiple Instances.)  But, since BYE v3.x successfully connects to the "standard" (and almost always ONLY) Instance of PHD2 when the older "localhost" identifier is stipulated, is it possible that BYE v3.1 is having an issue parsing the ":4300" (or adding a non-zero offset to that value) ??

 

Hopefully, we'll hear that you've resolved the issue with your efforts this evening...

 

Could be... but I remember testing it and it was working... but it does not mean there isn't a bug.  I'll test and report my findings later today or tomorrow.

 

Regards,

[s3igell]

It's great to see that BYE v3.1 has now progressed to the Release Candidate (slash Beta) stage.

 

Perhaps you could lay out for our edification the manner in which you plan this Beta effort to proceed:

• BYE v3.1 RC01 asks for User Licensing Keys (while BYN v3.1 Beta operates on a short-term preloaded Key).  Is this purposeful ??  
• BYE v3.1 RC01 also offers the License Key Backup procedure.  Will this be compatible with our (presumably) already backed-up Production BYE v3.0 Key Store ??
• BYE v3.1 RC01 installs (at least suggests) in its own Directory, so as to not overwrite a working BYE v3.0x installation.  (That's a Good Thing.):
•   Does the RC01 installation also register DLLs and make its own INI and/or add Registry Keys ??  Will the RC01 Uninstaller target these items without affecting BYE v3.0x instances??
•   What is intended for follow-on BYE v3.1 RC0x packages ??  Will they be side-by-side directory trees or overwrite each other ??
•   Could you consider using a Directory Path String which contains no "questionable" characters (such as "(" and ")") so that any testers who run within various OS VMs or Bootcamps can also follow the proffered Directory Path String ??
•   Will each RC0x Installation also need its own copy of VirtualDub.exe and virtualdub.dll ??  Or can they share an instance in a "root" BackyardTEMP directory ??  Or use PATH ??
• BYE v3.1 RC01 installs with the "default" Settings, while many Test Users will have developed "customized" Settings config files (possibly multiple config files depending on Camera1 vs Camera2 usage - or to accommodate Site-by-Site Equipment Profiles).  Is it possible to add a feature (generic enough for "General Upgrade Usage") that is offered in the Installer to "Import"/"Adopt" the existing Config File into the to-be-installed directory ??  (This would seem to be of general use as well as during a RC/Beta effort.)
• Will you be adding a "BackyardEOS V3.1 - Pre-release"-specific Forum (equivalent to the BackyardNIKON Pre-relase forum) ??  Or should we continue to post RC01 as well as V3.0.x Topics to this "BackyardEOS" Forum indiscriminately (one assumes in separate Topics per issue - not as additional Replies to this Release Candidate Announcement Topic) ??

Curious Minds... (and potential Beta Testers)

[admin]

It's great to see that BYE v3.1 has now progressed to the Release Candidate (slash Beta) stage.

 

Perhaps you could lay out for our edification the manner in which you plan this Beta effort to proceed:

• BYE v3.1 RC01 asks for User Licensing Keys (while BYN v3.1 Beta operates on a short-term preloaded Key).  Is this purposeful ??  
• BYE v3.1 RC01 also offers the License Key Backup procedure.  Will this be compatible with our (presumably) already backed-up Production BYE v3.0 Key Store ??
• BYE v3.1 RC01 installs (at least suggests) in its own Directory, so as to not overwrite a working BYE v3.0x installation.  (That's a Good Thing.):
•   Does the RC01 installation also register DLLs and make its own INI and/or add Registry Keys ??  Will the RC01 Uninstaller target these items without affecting BYE v3.0x instances??
•   What is intended for follow-on BYE v3.1 RC0x packages ??  Will they be side-by-side directory trees or overwrite each other ??
•   Could you consider using a Directory Path String which contains no "questionable" characters (such as "(" and ")") so that any testers who run within various OS VMs or Bootcamps can also follow the proffered Directory Path String ??
•   Will each RC0x Installation also need its own copy of VirtualDub.exe and virtualdub.dll ??  Or can they share an instance in a "root" BackyardTEMP directory ??  Or use PATH ??
• BYE v3.1 RC01 installs with the "default" Settings, while many Test Users will have developed "customized" Settings config files (possibly multiple config files depending on Camera1 vs Camera2 usage - or to accommodate Site-by-Site Equipment Profiles).  Is it possible to add a feature (generic enough for "General Upgrade Usage") that is offered in the Installer to "Import"/"Adopt" the existing Config File into the to-be-installed directory ??  (This would seem to be of general use as well as during a RC/Beta effort.)
• Will you be adding a "BackyardEOS V3.1 - Pre-release"-specific Forum (equivalent to the BackyardNIKON Pre-relase forum) ??  Or should we continue to post RC01 as well as V3.0.x Topics to this "BackyardEOS" Forum indiscriminately (one assumes in separate Topics per issue - not as additional Replies to this Release Candidate Announcement Topic) ??

Curious Minds... (and potential Beta Testers)

 

That is too much for me to handle right now <_>

 

BackyardNIKON packs it's own beta key because it is NOT yet released.

 

BackyardEOS RC is only for those who currently have a BYE key, like it always has been.  So you need to use your key.

 

BackyardTEMP is shared amongst all app.

 

Regards,

[admin]

 

That is too much for me to handle right now <_>

 

BackyardNIKON packs it's own beta key because it is NOT yet released.

 

BackyardEOS RC is only for those who currently have a BYE key, like it always has been.  So you need to use your key.

 

BackyardTEMP is shared amongst all app.

 

Regards,

 

I will also add that v3.1 RC01 will NOT override your current v3.0.3  installation so you can still use 3.0.3 even if you install RC01.

 

Yeah, having '(' and ')' in the default install folder name is not ideal, I'll change that next time around.

 

I will not create a per-release forum for BackyardEOS because unlike BackyardNIKON I do not expect the RC period to be long, just a few weeks and off it goes into production.

 

Hope this help,

 

 

[admin]

Guylain,

 

Just opened RC01 and in the PHD dithering settings it is defaulted to "localhost:4300". When tested it failed to connect each time. On looking in my previous version it was set to just "localhost". I amended the setting to just "localhost" and all worked fine.

 

Regards

 

Jim

 

Thanks Jim for reporting this... it was a bug... now fixed

 

The default port is 4300 if not specified as you found out... and as suggested in an earlier post I was not properly parsing the port number.

 

Thank you,

[jimwc6491]

Guylain

 

I down loaded 3.1.0 RC01. download went smooth once I disabled Norton.

I hooked up my camera to take a look at the program. I did not notice a Autofocus button.

is that function working yet? if so what are the steps to make it work. I may not be able to test it real soon as it is monsoon season <_<  I just have to keep an eye on the sky for a clear night.

 

 

[admin]

Guylain

 

I down loaded 3.1.0 RC01. download went smooth once I disabled Norton.

I hooked up my camera to take a look at the program. I did not notice a Autofocus button.

is that function working yet? if so what are the steps to make it work. I may not be able to test it real soon as it is monsoon season <_ just have to keep an eye on the sky for a clear night.>

 

 

No autofocus yet.

[jimwc6491]

Guylain

 

I was out last night with My scope and T3i using the frame and focus mode in 3.1.0 C-01

I noticed that the shutter kept changing back to 2" from bulb when switching from frame and focus to imaging and back to frame and focus. 

 

 

[astroman133]

Jim,

 

My version behaves the same way.  For astroimaging, only rarely would you want the LiveView exposure to be BULB.  Setting the exposure to 2" will give a brighter LiveView display, but I would expect that whatever setting you choose in Frame & Focus would persist if you go to Imaging and then back to F&F. For a bright target, like the moon, 2" is way too bright, and it is inconvenient to have to keep selecting a shorter exposure.

 

 

[admin]

If you uncheck the 'maximum aperture' in setting dialogue this behavior disappear and BYE will leave it alone.

 

Maybe that should be the default behavior? 

 

Regards,

[jimwc6491]

Guylain

 

Thanks ill give that a try

 

 

[dts350z]

I was trying to take some darks for a dark library today and none of the images ended up in correct folder or loaded into the preview/thumbnail area. The images are in the download folder.

 

Only preview images loaded. Image session images went to the download folder.

 

I will send the log file.

[dts350z]

Don't know if this had anything to do with it but I had dithering on and PHD2 wasn't running, so log file complains about that.

 

 

 

[astroman133]

If you set the Frame Type to Dark, in the Capture Plan Center, BYE will not attempt to dither.  I verified this with V3.1 RC01. 

 

Also, if you have the Frame Type incorporated in the file name it will show DARK, instead of LIGHT, in the file name.

[jimwc6491]

Guylain

 

will version 3.1.xx  keep my filenames and settings from 3.0.3 or will I have to input all of them all over again?

If I need to re enter them is there a easy way to copy them like a cut & paste.

 

 

 

[dts350z]

If you set the Frame Type to Dark, in the Capture Plan Center, BYE will not attempt to dither.  I verified this with V3.1 RC01. 

 

Also, if you have the Frame Type incorporated in the file name it will show DARK, instead of LIGHT, in the file name.

 

Well I can't confirm that I did choose darks, because the files did not get renamed but it WAS complaining about PHD. I can try to duplicate.

 

The logs confirmed that something went wrong, so maybe all bets are off in that case?

 

 

 

[admin]

If you set the Frame Type to Dark, in the Capture Plan Center, BYE will not attempt to dither.  I verified this with V3.1 RC01. 

 

Also, if you have the Frame Type incorporated in the file name it will show DARK, instead of LIGHT, in the file name.

 

Well I can't confirm that I did choose darks, because the files did not get renamed but it WAS complaining about PHD. I can try to duplicate.

 

The logs confirmed that something went wrong, so maybe all bets are off in that case?

 

 

 

Currently working on it.  It seems that on some computer the background worker does not start.

 

If it complained PHD was not running that I guarantee you were still on the LIGHT setting

 

In the next RC I will be forcing the background worker to start instead of on-demand.

 

In the meantime you can force the background worker to start by opening the Settings dialog, then close it.  The background worker will auto-start and your images should be copied...if not I need to know immediately so I can fix it ASAP.

 

Regards,

 

 

 

 

[dts350z]

Had the worker not staring problem again. Images weren't loading. Went to settings, applied, saved, now a preview loaded but an image still didn't.

 

Also weather station blank. Suspect that might be a yahoo problem however because I went back to 3.0.3 and it's blank there too.

 

 

 

[admin]

Had the worker not staring problem again. Images weren't loading. Went to settings, applied, saved, now a preview loaded but an image still didn't.

 

Also weather station blank. Suspect that might be a yahoo problem however because I went back to 3.0.3 and it's blank there too.

 

 

 

I should be releasing RC02 later today to tomorrow.

 

Sorry for the inconvenience.

 

 

[admin]

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

 

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

 

Thank you