@DeamonMV do you know if that happens when viewing a specific report or sparkline ?

same issue for me, my new server use MariaDB last version on Debian Linux Buster with PHP 7.3.4-2

I did some research on this.
The problematic line is
$value = round(($value / $max) * $height);
$value should be fine because its value comes from some lines above: $value = (int)$value;
$height should be fine because it comes from getInnerNormalizedHeight() which does return $this->getInnerHeight() * $this->ratioComputing;, forcing it to be numerical
this leaves us with $max which comes from getMaxValue() with either returns $this->base which we never set or max($this->data);
So the offending value must be the max value $this->data which we set in Piwik\Visualization\Sparkline.

Thus, this warning most likely can be avoided by ensuring we only pass numerical values in the $sparkline->setData($values); call in Piwik\Visualization\Sparkline.

I will do some more research and come back if I can track it down some more.

I added some debug code to my setup:

if (!is_numeric($value)) {
    file_put_contents("debug.log.txt", var_export($value, true) . PHP_EOL, FILE_APPEND);
}

It found these values:

'78 '
'79,5 '
'81,63 '
'80,88 '
'84,05 '
'84,04 '
'81,37 '
'82,16 '
'75,38 '
'79,91 '
'82,33 '
'81,88 '
'83,38 '

The problem with these values is the space character at the end which makes them non-numerical for php.
To resolve the problem a simple trim() should do the trick.

While debugging I also found this code:

$thousandSeparator = Piwik::translate('Intl_NumberSymbolGroup');
$decimalSeparator = Piwik::translate('Intl_NumberSymbolGroup');
$value = str_replace($thousandSeparator, '', $value);
$value = str_replace($decimalSeparator, '.', $value);

Which makes no sense if both times "Intl_NumberSymbolGroup" is used, so I think it should be "Intl_NumberSymbolDecimal" for $decimalSeparator.

After thinking about it, I guess it would be good to fix the cause of the appended space character. I will debug some more, this time with a call trace. Maybe we also should check all values with is_numeric() and throw a more meaningful warning if it fails

My findings after some more debugging:

The problematic values come from "bounce_rate" and "funnel_conversion_rate" (and most likely all other percent values). The strings have the form '16 %', after removing the '%' the space was left at the end. My first pull reuquest added a trim($value) which successfully removed any normal spaces (and tabs). However while debugging I also got strings with "non-breaking" spaces, encoded in ISO/ASCII (hex 0xA0) as well as UTF-8 (hex 0xC2 0xA0).

I will create a new PR to solve this issue as well.

``$validation_code = md5($username . microtime());
I have used '.' but not working. do you have any more solution, please