Errors, bugs, questions - page 2179

[Artyom Trishkin]

Nikolai Semko:

No, it has nothing to do with loading.

If you don't take a zero starting bar, but say 50 bars, then everything is OK. Instantaneous.

And if I take it up to and including 30 bar, it freezes. After that, it doesn't.

IT'S DEFINITELY A BUG!

Try this one:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift(const string symbol_name,const ENUM_TIMEFRAMES timeframe,const datetime time,bool exact=false)
  {
   datetime last_bar;
   if(!SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE,last_bar))
     {
      datetime array[1];
      if(CopyTime(symbol_name,timeframe,0,1,array)==1)
         last_bar=array[0];
      else
         return WRONG_VALUE;
     }
   if(time>last_bar)
      return(0);
   int shift=Bars(symbol_name,timeframe,time,last_bar);
   datetime array[1];
   if(CopyTime(symbol_name,timeframe,time,1,array)==1)
      return(array[0]==time ? shift-1 : exact && time>array[0]+PeriodSeconds(timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE;
  }
//+------------------------------------------------------------------+

[Nikolai Semko]

Artyom Trishkin:

Try this one:

What does iBarShift have to do with anything?

It's about a bug in the standard Bars function

[Artyom Trishkin]

Nikolai Semko:

What does iBarShift have to do with anything?

It's about a bug in the standard Bars function

That function also uses Bars(). You started with the analog of iBarShift()

[Nikolai Semko]

Artyom Trishkin:

That function also uses Bars(). In your case, it all started with iBarShift()'s analog

Yes, of course, using the iBarShift counterpart revealed this problem.

If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,

And this bug happens when you use different TF in CopyTime and Bars functions.

But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.

[Vitaly Muzichenko]

Nikolai Semko:

Yes, of course, using the iBarShift counterpart revealed this problem.

If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,

And this bug happens when you use different TF in CopyTime and Bars functions.

But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.

This is most likely due to history loading

[Kirill Belousov]

Nikolai Semko:

Yes, of course, using the iBarShift counterpart revealed this problem.

If you use iBarShift function given by you, you won't catch this bug, because only one TF is used there,

And this bug happens when you use different TF in CopyTime and Bars functions.

But Bars should work normally for any time. But my example shows that there is a special case, where iBar hangs for tens of seconds. And it has nothing to do with loading history.

I think there is an attempt of cyclic sync in a situation where there are no bars in the requested range - Bars is trying hard to "work normally" and then gives up by a timeout or number of attempts at sync.

You should check the values yourself to avoid calling Bars in such a case.

[Nikolai Semko]

Vitaly Muzichenko:

This is most likely due to history uploading

I disagree. It would not have been downloaded again for 22 seconds. Moreover, I have all the history for all TFs loaded by a special indicator.

If it was a loading, then how can we explain that the first 31 bars need loading and the next ones do not.

[A100]

Nikolai Semko:

If it were a sub-loading, then how do you explain that the first 31 bars need a sub-loading and the subsequent ones do not.

From the documentation: When requesting the number of bars in a given date range, only those bars whose opening time falls within this range are taken into account.

Accordingly, the Bars() prototype returns zero, which is interpreted as no history and ::Bars() in the case of the script, as correctly noted in a previous post, terminates by timeout or by the number of failed attempts.

[Nikolai Semko]

Kirill Belousov:

I think there is an attempt of cyclic synchronization when there are no bars in the requested range - Bars is trying hard to "work normally" and then gives up by timeout or number of synchronization attempts

The reason of such cases is that you should not call Bars in order to check the values yourself.

It is quite possible.
But there are plenty of options.

Bars is a very important function, and it's hard to do without it. To be exact, you can do without it but it will cost you a great deal of resources.

You must make sure that it functions perfectly.

[Nikolai Semko]

A100:

From the documentation: When requesting the number of bars in a given date range, only those bars whose opening times fall within this range are taken into account .

Accordingly, the Bars() prototype returns zero, which is interpreted as a lack of history and the script, as correctly noted in a previous message, terminates by timeout or number of failed attempts.

It is clear that it is zero.

And what - is it OK to take 22 seconds to decide that zero bars in a given time range?

There is an obvious algorithmic bug in the internal implementation of Bars.

We should send a request to Service Desk on this subject - the weekend is ahead and the subject might get lost on Monday.