Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Download problems with 500D


strikele

Question

I have been testing my 500D inside as I just changed the power cable and wanted to ensure everything is working properly.  I had had issues with my 500D in November and these seemed to be fixed in version 3.02, but I have not had the clear skies to test out in the field.  Unfortunately today with both ver 3.02 and 3.03, I have run into download times of 3-6 minutes per image, both with 1/10 sec TV images and 45 second Bulb images. I have tried two different camera to computer cables, as well as running each of these cables both directly to the computer and through a powered hub with the same issue in each instance.

 

Using EOS utility, the images show up almost instantaneously.

 

It is possible that I have a setting somewhere set incorrectly since it has been so long since I last used BYE.

 

Have any other 500D users had this issue? 

 

 

 

Link to comment
Share on other sites

  • Answers 12
  • Created
  • Last Reply

12 answers to this question

Recommended Posts

Leslie,

 

Well if the EOS Utility has no trouble downloading the images, then it does not seem to be a cable or hub issue.

 

What takes 3-6 minutes?  From the time the shutter closes on the first image until it opens on the next image? 

 

What does your capture plan look like? 

Do you have a big pause between exposures? 

Does LiveView behave as expected?

When you shoot a Planetary Capture, what frame rate do you get?

Does it matter whether you shoot RAW, JPG, or RAW+JPG?

 

Longer exposures are managed by BYE differently from short exposures, so that was a good test point.

 

Those are all things to try. I hope they shed some light on your issue.

Link to comment
Share on other sites

Rick, thanks for the suggestions.  The time 3-6 minutes is from the time the exposure ended until it shows up on my screen.  In the meantime, the shutter opens on schedule and the next pictures is taken, leaving me with then 2 in the queue. I had 2 images in the capture plan, with a delay of 4 seconds between them. I do not believe that I tried live view as I focused the lens before I started the run.  I was not in the planetary section at all.  The images were all RAW; I didn't try jpg.  I turned off the PhD initialization on start-up as I wasn't connect to a mount and I thought that might make a difference but it did not. 

 

I have sent the logs to Guylain.  Hopefully he will see something in them. 

 

 

 

 

 

 

Leslie,

 

Well if the EOS Utility has no trouble downloading the images, then it does not seem to be a cable or hub issue.

 

What takes 3-6 minutes?  From the time the shutter closes on the first image until it opens on the next image? 

 

What does your capture plan look like? 

Do you have a big pause between exposures? 

Does LiveView behave as expected?

When you shoot a Planetary Capture, what frame rate do you get?

Does it matter whether you shoot RAW, JPG, or RAW+JPG?

 

Longer exposures are managed by BYE differently from short exposures, so that was a good test point.

 

Those are all things to try. I hope they shed some light on your issue.

 

 

 

Link to comment
Share on other sites

Rick, thanks for the suggestions.  The time 3-6 minutes is from the time the exposure ended until it shows up on my screen.  In the meantime, the shutter opens on schedule and the next pictures is taken, leaving me with then 2 in the queue. I had 2 images in the capture plan, with a delay of 4 seconds between them. I do not believe that I tried live view as I focused the lens before I started the run.  I was not in the planetary section at all.  The images were all RAW; I didn't try jpg.  I turned off the PhD initialization on start-up as I wasn't connect to a mount and I thought that might make a difference but it did not. 

 

I have sent the logs to Guylain.  Hopefully he will see something in them.

 

Leslie,

 

I have not had the time to look at your log files yet... but in 3.1 -ALL- background processing will now be ran in a totally separate Windows process and will no longer be suspended because of a bulb exposure < 30 seconds.  All images will be processed immediately from the queue, one by one, in a first-in first-out fashion... with the exception of preview and snap images in live view... those will take priority and will always be processed first.

 

If I can't find the root cause then 3.1 will solve you issues for sure.

 

Guylain 

Link to comment
Share on other sites

So, it does not seem that the download is an issue because the next won't start until the just completed image has been downloaded.

 

I wonder if it makes a difference to check the "Skip EXIF Write" and "Skip EXIF Read" parameters in the Advanced setup screen.  This should speed up the processing at least a little bit.  The drawbacks are that BYE will not read the internal camera temperature and it will not write its own data into the EXIF parameters.

 

I asked about LiveView because if LiveView is behaving and updating normally, then it does not appear that you are having a cable/communication/download problem.

 

 

Link to comment
Share on other sites

So, it does not seem that the download is an issue because the next won't start until the just completed image has been downloaded.

 

I wonder if it makes a difference to check the "Skip EXIF Write" and "Skip EXIF Read" parameters in the Advanced setup screen.  This should speed up the processing at least a little bit.  The drawbacks are that BYE will not read the internal camera temperature and it will not write its own data into the EXIF parameters.

 

I asked about LiveView because if LiveView is behaving and updating normally, then it does not appear that you are having a cable/communication/download problem.

 

 

Rick, I have spent the last couple of days testing various versions of the program and scanning the detailed logs and have not found any solution.  Yes, skipping the EXIF write and read sections does save some time as it seems to take a minute and a half to read the EXIF and another half minute to write the exif. But whatever version I use, with or without EXIF, I am still running into abnormally long download times.  Even restoring the test version that I used to test the 500D before Guylain released 3.02, which gave me in November CR2 load times of 3000-6000 ms per image with minimal delay in reading EXIF, is now giving me CR2 load times of 80,000-106,000 ms. Then the EXIF adds another 2 minutes and then another minute to show up with a name and thumbnail on the screen.  Something has changed somewhere.  If you have any other ideas I might try to pinpoint the problem, I will definitely try them out as I really like BYE. 

 

I used BYE to do alignment last evening and it was very jerky.  I used another capture program to actually capture the images because if it takes 3-4 minutes to download an image in BYE when I am taking 40 2 minute images, I will have a slew of unloaded images at the end of the session, to which I would have to add flats and the other calibration images - an unworkable situation for me. 

 

Guylain has indicated that version 3.1 is the answer so I hope it comes soon.

 

Thank you for all your help.

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Please check to make sure that you don't have the "Long Exposure Noise Reduction" setting ON in your Camera.

 

This "Feature" causes the Camera to take an Equal Duration Dark Exposure for every Light Exposure.  Since the Camera will not fire the Shutter for these "Darks", you might believe that the delay is BYEOS Downloading rather than the Camera still busily exposing the Dark.

 

 

Link to comment
Share on other sites

Rick, I have spent the last couple of days testing various versions of the program and scanning the detailed logs and have not found any solution.  Yes, skipping the EXIF write and read sections does save some time as it seems to take a minute and a half to read the EXIF and another half minute to write the exif. But whatever version I use, with or without EXIF, I am still running into abnormally long download times.  Even restoring the test version that I used to test the 500D before Guylain released 3.02, which gave me in November CR2 load times of 3000-6000 ms per image with minimal delay in reading EXIF, is now giving me CR2 load times of 80,000-106,000 ms. Then the EXIF adds another 2 minutes and then another minute to show up with a name and thumbnail on the screen.  Something has changed somewhere.  If you have any other ideas I might try to pinpoint the problem, I will definitely try them out as I really like BYE. 

 

I used BYE to do alignment last evening and it was very jerky.  I used another capture program to actually capture the images because if it takes 3-4 minutes to download an image in BYE when I am taking 40 2 minute images, I will have a slew of unloaded images at the end of the session, to which I would have to add flats and the other calibration images - an unworkable situation for me. 

 

Guylain has indicated that version 3.1 is the answer so I hope it comes soon.

 

Thank you for all your help.

 

Leslie, I've looked at your log files and the issue is NOT downloading images and not reading/writing exif data.

 

Physical download takes about 10 seconds consistently according to your log files.

Reading/Writing exif date takes about 8 seconds consistently according to your log files.

 

THE ISSUE is actually the Canon SDK is taking waaaayyyyy to long to read the .cr2 and recreate the image.

 

2014-03-31 16:11:51,106 [img_0001.CR2] INFO  - Running (log): EDSDK.EdsGetImage(img_ref, imageSource, bitmapImageType, imageInfo.EffectiveRect, outputSize, stream)

2014-03-31 16:12:56,143 [img_0001.CR2] INFO  - Success: EDSDK.EdsGetImage(img_ref, imageSource, bitmapImageType, imageInfo.EffectiveRect, outputSize, stream)

 

The call to EdsGetImage() is taking over 1 minute and the call to release the image is taking of 15 seconds.

 

This is where the time is spent, it should not take more than 10 seconds, even on a slow computer.

 

THE GOOD NEWS... it's not the camera!

 

THE BAD NEWS... it's the SDK that is crapping on you because the calls to the SDK are taking for ever to return.

 

I see you are running off a 1 CPU laptop... I don't think this is an issue.  BUT, how much memory do you have?  My best guess is that you are running low on memory and that leaves Windows using the swap file (on disk) to use as virtual memory... which would have Windows spend ridiculous amount of time pushing/pulling stuff in/out the the virtual memory swap file.

 

If you monitor MEMORY and DISK activity during that time with task manager... what does it say?  Is the disk activity through the roof?  If yes that would confirm my theory.

 

Does this make sense?

 

Guylain

Link to comment
Share on other sites

 

Leslie, I've looked at your log files and the issue is NOT downloading images and not reading/writing exif data.

 

Physical download takes about 10 seconds consistently according to your log files.

Reading/Writing exif date takes about 8 seconds consistently according to your log files.

 

THE ISSUE is actually the Canon SDK is taking waaaayyyyy to long to read the .cr2 and recreate the image.

 

2014-03-31 16:11:51,106 [img_0001.CR2] INFO - Running (log): EDSDK.EdsGetImage(img_ref, imageSource, bitmapImageType, imageInfo.EffectiveRect, outputSize, stream) 2014-03-31 16:12:56,143 [img_0001.CR2] INFO - Success: EDSDK.EdsGetImage(img_ref, imageSource, bitmapImageType, imageInfo.EffectiveRect, outputSize, stream)

 

The call to EdsGetImage() is taking over 1 minute and the call to release the image is taking of 15 seconds.

 

This is where the time is spent, it should not take more than 10 seconds, even on a slow computer.

 

THE GOOD NEWS... it's not the camera!

 

THE BAD NEWS... it's the SDK that is crapping on you because the calls to the SDK are taking for ever to return.

 

I see you are running off a 1 CPU laptop... I don't think this is an issue.  BUT, how much memory do you have?  My best guess is that you are running low on memory and that leaves Windows using the swap file (on disk) to use as virtual memory... which would have Windows spend ridiculous amount of time pushing/pulling stuff in/out the the virtual memory swap file.

 

If you monitor MEMORY and DISK activity during that time with task manager... what does it say?  Is the disk activity through the roof?  If yes that would confirm my theory.

 

Does this make sense?

 

Guylain

 

Guylain, actually that makes a lot of sense. I have been thinking of adding RAM for a while (I have 2 GB now and my machine can take 4 GB). But what I don't understand is why EOS Utility would still work fine and why the available memory would be so much less now than in November.  But there have been Windows updates since then so who knows?

 

I will run a test today monitoring the memory and disk usage and confirm.

 

Thank you so much.  I was really out of ideas to try here.

 

 

Link to comment
Share on other sites

Update:  the issue with my 500D was indeed associated with my computer but not the memory or disk usage.  Rather, the updated version of my (now former) anti-virus AVG 2014 (in case anyone else is using this and having problems) was taking from 88-95% of my CPU cycles. I have replaced it with another anti-virus and all is working quite correctly - no issues with delays in seeing the downloaded images show up.  The only little thing that is happening for some reason is that the detailed log preference in the advanced settings is not saving a log, even after restart, so I cannot check on the details.

 

I am very happy to say the least.  Thanks to all for your help!

Link to comment
Share on other sites

Update:  the issue with my 500D was indeed associated with my computer but not the memory or disk usage.  Rather, the updated version of my (now former) anti-virus AVG 2014 (in case anyone else is using this and having problems) was taking from 88-95% of my CPU cycles. I have replaced it with another anti-virus and all is working quite correctly - no issues with delays in seeing the downloaded images show up.  The only little thing that is happening for some reason is that the detailed log preference in the advanced settings is not saving a log, even after restart, so I cannot check on the details.

 

I am very happy to say the least.  Thanks to all for your help!

 

Leslie,

 

Actually now that you say this... you are the second one in 2 months that traces computer issues to AVG <_>

 

FYI, I have been using the built-in Microsoft Windows Defender for 3 years now and I have NEVER, EVER had any issues with it.  It is quite good actually... and it is free.

 

Regards,

 

Guylain

 

 

Link to comment
Share on other sites

There are a number of Apps which can lead to very Heavy Background CPU Usage:

1) Virus Scanners

2) Image Cataloging Apps - cataloging "image files" triggered by .CR2 downloads

3) RealPlay - cataloging "media files" triggered by .CR2 downloads

4) Windows Media Player - cataloging "image files" triggered by file creation in "watched" libraries

 

The usual solution is to either configure these Apps to NOT perform these background scans, or to Exclude the parent Directories of those where your BYEOS Images are downloaded.

 

(RealPlay is my main nemesis - I do use the App for other purposes but it doesn't expose any configuration that allows me to successfully exclude certain directories.  Instead, I need to use TaskManager to Terminate the "rogue" realplay.exe processes when they get "annoying".)

 

One could consider running without Virus Scanner protection during the AP Imaging Sessions - IF one is not connected to the Internet via LAN or Wi-Fi while out in the field / observatory.  Most Anti-Virus Apps are set to start upon Boot, and/or can be disabled for selected amounts of time.  Either of these would allow you to Image uninterrupted, but have AV Protection after Shutting Down at end of the Imaging Session and rebooting in the AM.

 

But please disable your AV Protection at your Own Risk, as I'm not advocating running any Laptop without reasonable protection.  (Nor, I'm sure, would Guylain...)

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use