Yes, they will be the same. The zip files are raw data. Zorro does the cleaning internally when it loads the prices.

Some files in the zip have a length of 0 bytes - they replace some early years when price data was really bad. Those files should not be deleted.

Thanks jcl.

Re. 0 byte files, what about other assets? Did the bad data affect them as well?

I.e., before downloading history for other assets, are there years for which 0 byte files should always be created to avoid downloading bad data for those other assets?

I stand corrected -- it worked! I tried simplifying the Download.c script to just a few key lines and made sure the asset didn't already exist in the history folder.

One thing that may have been the issue before (not sure) is that I may have tried over a weekend. Could be that the feed was down?



Btw, how much is "too much" in the gap. In other words, at what point should I be worried about a gap in prices?

I'll proceed now to download all the rest of the assets and advise if any abnormal issues.

THANKS

I've just encountered an abnormality with downloading M1 data through the FXCM real account feed:

I've been slowly-but-surely downloading M1 data for all the exotics, and I have not yet taken a closer look at them (ie, plot price curve is one thing I plan to do)... but sometimes it's obvious something is wrong by just looking at the filesize.

Overnight I downloaded another handful of pairs from 2002-2013 and I noticed two irregular-looking years for GBP/CHF. So what I did is I moved ALL those files for this pair to a subfolder and then restarted Zorro and requested loadHistory for only one of the bad years.

The result is that it now downloaded a seemingly-full dataset. This brings up several concerns:
Did the FXCM feed malfunction during the download process?
or did Zorro hiccup and cause this issue?

Here is the info I looked at:
(first run):
GBPCHF_2007.bar
739 KB
31496 min

(second run):
GBPCHF_2007.bar
8226 KB
350970 min

Note that the surrounding years (2002-2013) for this pair looked normal filesize, with the exception of 1 other abnormal year (2011).

EDIT: in re-attempting the (obviously wrong) years, I did get a more-normal looking file size for both years.

Yes, this is either a malfunction of the FXCM server, or a temporary online connection problem. If a file is obviously too short, download it again later. If it's then still too short, replace it by a 0 file.