MT5 : Issues and bugs working with real ticks/custom ticks.

 

Beta build 1958 (and previous from ?).

While using CustomTicksReplace() to import a 10 millions ticks buffer on a custom symbol (empty tick history to start), it takes 90 seconds to execute ! On memory 10 millions ticks is around 600 MB, but they are then compressed somehow to be written in ticks file (database). A database tick being between 6 and 7 bytes, let's say 7 bytes, 10 millions ticks is at worst 70 MB.

Checking my computer's disk, I can see the transfer rate is very low, not even 1 MB/s in average. On a hard disk able to reach 80 MB/s in write mode (checked yesterday with a benchmark software).

I don't know if it has always be like that or if it's something new, but that seems veeeery slow to me, even considering the needed processing.

 
Alain Verleyen:

Beta build 1958 (and previous from ?).

While using CustomTicksReplace() to import a 10 millions ticks buffer on a custom symbol (empty tick history to start), it takes 90 seconds to execute ! On memory 10 millions ticks is around 600 MB, but they are then compressed somehow to be written in ticks file (database). A database tick being between 6 and 7 bytes, let's say 7 bytes, 10 millions ticks is at worst 70 MB.

Checking my computer's disk, I can see the transfer rate is very low, not even 1 MB/s in average. On a hard disk able to reach 80 MB/s in write mode (checked yesterday with a benchmark software).

I don't know if it has always be like that or if it's something new, but that seems veeeery slow to me, even considering the needed processing.

It has always been slow to generate the Custom Symbols, even when it is only with OHLC data instead of tick data.

However, I have no way of knowing if it is slower now (on new builds) compared to before as I have yet to use the newer builds. I am still using the old stable build 1881.

 
Fernando Carreiro:

It has always been slow to generate the Custom Symbols, even when it is only with OHLC data instead of tick data.

However, I have no way of knowing if it is slower now (on new builds) compared to before as I have yet to use the newer builds. I am still using the old stable build 1881.

Thanks for your input.

This issue is only the first in a series of problems I will report, when working with ticks. Just encounter a new bug right now using CopyTicksRange() (MT5 just crashed silently and the custom symbol just finished with 300 millions ticks, it took 1 hour to import.

I can't use build 1881, as there was an other bug with CopyTicksRange() which forced me to use newer build to move forward on some project (by the way I reported the bug to Metaquotes and they fixed it).

I can't use 1940 as there constant "Access violation issue".

I will do what is possible to have all of these fixed or improved, we will see.

 
Alain Verleyen:

Thanks for your input.

This issue is only the first in a series of problems I will report, when working with ticks. Just encounter a new bug right now using CopyTicksRange() (MT5 just crashed silently and the custom symbol just finished with 300 millions ticks, it took 1 hour to import.

I can't use build 1881, as there was an other bug with CopyTicksRange() which forced me to use newer build to move forward on some project (by the way I reported the bug to Metaquotes and they fixed it).

I can't use 1940 as there constant "Access violation issue".

I will do what is possible to have all of these fixed or improved, we will see.

Can you remind me of what is the bug with CopyTicksRange on build 1881?
 
Fernando Carreiro:
Can you remind me of what is the bug with CopyTicksRange on build 1881?

I don't know if it was reported publicly, it's something I found and reported when the ServiceDesk was still open for bugs.

The problem was when using dates (in milliseconds) "far" in the past (more than 1 year), the function always returned an error (don't remember for sure which one, I think 4407). You can probably check easily.

 
Alain Verleyen:

I don't know if it was reported publicly, it's something I found and reported when the ServiceDesk was still open for bugs.

The problem was when using dates (in milliseconds) "far" in the past (more than 1 year), the function always returned an error (don't remember for sure which one, I think 4407). You can probably check easily.

Thank you!
 

Hi, This is in regard to Metatrader5 build 2136 (plus all earlier versions). 

There is a serious bug in CopyTicksRange() function: https://www.mql5.com/en/docs/series/copyticksrange

Tick history obtained via CopyTicks() or via download from MT5 (CTRL-U) for a specific symbol differs significantly from data obtained via CopyTicksRange()

Not only the volume data differ, but many times also the quote prices! Please see a side by side DIFF analysis below:

As you can see on the right side margin of the editor all differences are marked by red and green bars (they are all over the place).

Another issue that if found in the platform is that not all tick data is available for download. Sometimes the lates 1-2 hours are missing and sometimes an entire day. 

This can see in the CopyTick() function as well as in the Ticks tab of the Symbols dialog (CTRL-U).

Strangely CopyTicsRange() leverages local cache while CopyTicks() always performs a download. This can be seen when calling the two functions a few times. For CopyTicksRange() the first download will take longer while all consecutive calls will be very quick. For CopyTics() all subsequent calls will be slow so local cache is not utilized.

Will this ever be fixed? I sent this bug over a year ago via Service Desk and I still don't have a reply on this.

Documentation on MQL5: Timeseries and Indicators Access / CopyTicksRange
Documentation on MQL5: Timeseries and Indicators Access / CopyTicksRange
  • www.mql5.com
[out] MqlTick static or dynamic array for receiving ticks. If the static array cannot hold all the ticks from the requested time interval, the maximum possible amount of ticks is received. In this case, the function generates the error ERR_HISTORY_SMALL_BUFFER (4407) . ERR_NOT_ENOUGH_MEMORY – insufficient memory for receiving a history from...
 
Artur Zas:

Hi, This is in regard to Metatrader5 build 2136 (plus all earlier versions). 

There is a serious bug in CopyTicksRange() function: https://www.mql5.com/en/docs/series/copyticksrange

Tick history obtained via CopyTicks() or via download from MT5 (CTRL-U) for a specific symbol differs significantly from data obtained via CopyTicksRange()

Not only the volume data differ, but many times also the quote prices! Please see a side by side DIFF analysis below:

As you can see on the right side margin of the editor all differences are marked by red and green bars (they are all over the place).

Another issue that if found in the platform is that not all tick data is available for download. Sometimes the lates 1-2 hours are missing and sometimes an entire day. 

This can see in the CopyTick() function as well as in the Ticks tab of the Symbols dialog (CTRL-U).

Strangely CopyTicsRange() leverages local cache while CopyTicks() always performs a download. This can be seen when calling the two functions a few times. For CopyTicksRange() the first download will take longer while all consecutive calls will be very quick. For CopyTics() all subsequent calls will be slow so local cache is not utilized.

Will this ever be fixed? I sent this bug over a year ago via Service Desk and I still don't have a reply on this.

If your bug report is like this post, it's very unlikely it will ever be fixed.

You show us some different data but that doesn't mean there is a bug. No offense, I am not saying that there is no bug, but the developpers will never trust you without solid proof.

You need to post code and ALL relevant information to reproduce it.

 
Alain Verleyen:

If your bug report is like this post, it's very unlikely it will ever be fixed.

You show us some different data but that doesn't mean there is a bug. No offense, I am not saying that there is no bug, but the developpers will never trust you without solid proof.

You need to post code and ALL relevant information to reproduce it.

I did that over a year ago and got no answer so it seems like I'm just wasting my time.

All that the developers need to do is compare results from the 2 functions or compare results from CopyTicksRange() with the data downloaded from the Symbols window.

Really, that is all it takes.

Anyway, I'll wire some sample code (again) and I'll post it here later this week.

 

I started to write the code but decided to first test the functionality that is already present in MT5. As you can see from the screenshot below the data is out of sync. This is reflected identically in the CopyTicks() and CopyTicksRange() functions. The developers can just use the platform itself to test this:

As you can clearly see in the Market Watch window the time of the last quote is 21:00:24 (Bid = 103825, Ask = 103830, Last = 103885)

The chart reflects the above.

Now, when I request tick data via Symbols dialog, I get the time of the last quote 19:14:00 (Bid = 0, Ask = 0, Last = 0, Volume = 0).

The previous tick is at 18:01:21 (Bid = 103880, Ask = 103885, Last 103885).

The last tick is obviously invalid, but above all where is the tick data from 19:14:00 to 21:00:24?

This should be enough to prove that the tick data functionality is broken in MT5. Can someone from Metaquotes please look into this?

 
Artur Zas:

I started to write the code but decided to first test the functionality that is already present in MT5. As you can see from the screenshot below the data is out of sync. This is reflected identically in the CopyTicks() and CopyTicksRange() functions. The developers can just use the platform itself to test this:

As you can clearly see in the Market Watch window the time of the last quote is 21:00:24 (Bid = 103825, Ask = 103830, Last = 103885)

The chart reflects the above.

Now, when I request tick data via Symbols dialog, I get the time of the last quote 19:14:00 (Bid = 0, Ask = 0, Last = 0, Volume = 0).

The previous tick is at 18:01:21 (Bid = 103880, Ask = 103885, Last 103885).

The last tick is obviously invalid, but above all where is the tick data from 19:14:00 to 21:00:24?

This should be enough to prove that the tick data functionality is broken in MT5. Can someone from Metaquotes please look into this?

I have seen the "zero" tick bug already reported on Russian forum.

Which broker is it ? XP ? Demo or real account ?

Reason: