These AI report are a hell.
Formulate your point in one sentence, nobody will read all that AI slop.
Additionally coding question require you provide code about it.
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Hello,
Please route this question to anyone familiar with the MT5 terminal/history API. We need the documented platform contract for broker-server M1 history, specifically build 6230, including any version or effective-date limitations.
The observed environment is FTMO-Demo, US100.cash, BID chart. Broker-specific historical source/specification/session questions are being requested separately from FTMO.
Where is M1 volume authoritative?
Is MqlRates.tick_volume supplied as a broker-server bar field, reconstructed by the client terminal from ticks, or dependent on the history database/data path?
Does the terminal apply a deterministic construction law when receiving/downloading M1 history?
Please distinguish:
a currently forming native bar;
downloaded completed M1 bars;
what is platform-defined;
what is broker-controlled.
If reconstructible from ticks, what counts?
What constitutes one tick/event:
Bid-only change;
Ask-only change;
Last-only change;
volume-only change?
Can updates sharing the same time_msc count separately?
Do MqlTick.flags affect inclusion?
Is a one-to-one relationship with CopyTicksRange(COPY_TICKS_ALL) guaranteed for the same minute/frontier?
Please state any documented filtering, aggregation or revision limitations, including whether same-millisecond order/multiplicity is stable across repeated requests, synchronization and reloads.
We are not treating OnTick callback count as tick count.
Observed flag 0x400
What is the authoritative meaning/status of bit 1024 / 0x400 in MqlTick.flags for build 6230?
Is it:
publicly defined;
reserved/internal;
broker-defined;
otherwise unspecified?
Does it have any defined role in tick-volume construction?
The observed full flags value is 1030 / 0x406. We have not assigned a meaning to the residual bit.
Limits of historical evidence
What can the terminal/API actually prove about downloaded history concerning:
original broker-side source;
replacement/backfill;
effective historical symbol specifications;
original session rules?
Are any metadata/API guarantees available, or must these facts be established by the broker?
Please identify relevant platform-version limitations rather than treating current terminal properties as proof of historical settings.
For context, two prospective native captures showed exact BID OHLC agreement in comparable samples, while bar tick volume exceeded three preregistered archive counts by +9 in one window and +3 in the other.
We do not infer:
an MT5 bug;
missing upstream data;
atomic API observation;
any fixed-offset correction.
These were not Strategy Tester observations.
Please provide documentation or a scoped technical statement, and explicitly identify what is not guaranteed or unavailable.
We are not asking for trading advice, EA validation, or another routine capture.
Thank you.
Technical evidence excerpt:
Environment: MT5 build 6230, FTMO-Demo, US100.cash, BID chart.
Capture 1:
Comparable BID OHLC: exact in 7/7 comparable samples
Native bar tick volume vs preregistered archive count: +9
Final native volume / full-minute raw rows: 205 / 196
Capture 2:
Comparable BID OHLC: exact in 8/8 comparable samples
Native bar tick volume vs preregistered archive count: +3
Final native volume / full-minute raw rows: 398 / 395
In both captures:
Ask-only discriminant: 0
Same-millisecond discriminant: 0
Nonzero raw-volume discriminant: 0
Residual unknown tick flag bit observed: 0x400 / 1024
In the second capture, full flags value was 1030 / 0x406 on all 395 rows
No fixed-offset model is assumed or authorized. These observations are not classified as a bug or proof of missing data.
Evidence SHA-256:
Capture 1: F62B8D9580BC2E402797AA7A1EC0ADBBC2FE956429E62AED6775450B5861EF8C
Capture 2: C3F934265CB02FE40E21007016716DBAA2A9DDF4D47CC7276C3DA9B94CA89C4F
Verifier: 20334BC3ED09C3F5571351D5627351E12AA463D021CB24B9AEEA5DC73022E34E