-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
type-2 block #115
Comments
Just as a question, how did you determine the file format, and what is the meaning of any control bytes that less than 0x3f, i.e. type-0 or something? |
There are no available docs for this format, so at first it was with help of some friend a while back then by trial and error. He had some software already to read this format and gave us some hints. |
Got it. In any case, it seems there is no data that has a type-0 style entry. I screened all of the files on the history server from 2020 onwards (not interested in anything before that). Initially I had a bug which suggested type-0 data (stupid javascript in place array annoyance). From 2015 onwards. All good;
|
Hi,
Your metaquotes history download decoding of type-2 block needs to be fixed, otherwise the data is junk.
The Type-3 block has 5 bytes, which is decoded correctly.
The Type-2 block has 6 bytes, of which the first byte is a minutes offset, and the remaining 5 bytes are the same as the Type-3 block.
To decode, you do the same as you would do for a Type-3 block, but instead of incrementing the minutes by one (or, as you do, msec by 60000), you increment the minutes by the value of the first byte.
I have manually compared this to the data in the history centre to confirm it is correct.
This is the Javascript implementation:
Thank you for your implementation, otherwise I would have been stuck. Standing on the shoulders of others, and all that.
EDIT: after debugging, refactoring and testing, this is the final result if useful for others. Tested on data 2010-2024
The text was updated successfully, but these errors were encountered: