Created attachment 119934 [details] Calculation error after adding time data to next row. I have a spreadsheet with four columns to present start and stop times and fifth column to calculate the hours. All of the columns are formatted in [HH]:MM format and calculated in the fifth column to get the time with formula (=(C9-B9)+(E9-D9)). So this has worked as expected in 4.3.7.2 and earlier versions, but after trying some 4.4 release version earlier and now 5.0.2 it does not work like it should anymore. When I open my file with a 4.4 or later version the file shows ok, but if I add data to new row or edit existing ones the calculations go off on fifth column. Not always on all rows. Rewriting one of the first 4 columns with the same time makes it to calculate that row correctly again. If I have only first two columns filled it seems to directly show the same time on the fifth column as the second column instead of doing the calculation. Attaching a file where the error occurs (managed to recreate the error without the original file, altough in this file the calculations seem to go negative instead).
System is Windows 10 Pro 64 bit, last version tried is the 5.0.2.2 64bit version.
Hi @matti_savolainen, thanks for reporting. Reproducible Win10x64 Version: 4.4.6.2 Build ID: 008d5d0ddffba0b82de2a2c36a65b9cba0a6b328 Version: 5.0.3.1 (x64) Build ID: fd8cfc22f7f58033351fcb8a83b92acbadb0749e Copying row 213 on row 214 shows the problem with OpenCL enable. Disabling OpenCL solves the issue Menu/Tools/Options/LibreOffice/OpenCL Also a hard recalc [Ctrl+Shift+F9] seems to solve the issue. Reducing the Minimum data size for OpenCL use lets verify with only a couple of data lines.
Thanks for the workaround, will disable OpenCL for now.
Duplicate of bug 94924 then ?
I don't if it has some relation, but this one is yet there with: Win10x64 Version: 5.1.0.0.alpha1+ (x64) Build ID: a62bc6a65abb47adb0e4caff7e38823c15b302fc TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-10-24_23:49:43 In which tdf#94924 seems solved.
@mmeeks: This is yet another "calculating wrong with OpenCL" report. Any estimate if, how and in what time frame it can be fixed on your side? As an interim measure I suggest to default the OpenCL option to disabled in all releases.
Sorry, can't reproduce with TDF build of 4.4.7.2 or 5.0.3.2, or with own builds.
Ah, after more careful reading of how the initial comment exactly says the problem appears, I can reproduce it in 4.4.7.2 and 5.0.3.2.
Also reproduced in 5.0.5.2 and 5.0.5.1. But not in the master or 5.1 branches.
Which is a bit surprising as I would have thought that all OpenCL related fixes had gone also into 5.0. But apparently not. Will investigate.
(In reply to Tor Lillqvist from comment #9) > Also reproduced in 5.0.5.2 and 5.0.5.1. I meant 5.0.4.2 and 5.0.5.1. But actually, I need to double-check. Now again I can't reproduce in 5.0.5.1...
Yeah; I would say that this indeed is fixed in 5.0.5.1 at least (and later branches). Matti, can you reproduce in one of those?
Reproduced in 5.0.4.2, but seems to be fixed in 5.0.5.1 RC.
Yes, that is what I see, too. (The only slightly irritating thing is that then I don't understand which commit fixed this. I would have guessed b76c450eb7f6517fae24a0d7ea6431663959adf3 but that commit is in 5.0.4.2, too.)
(In reply to Tor Lillqvist from comment #14) > Yes, that is what I see, too. (The only slightly irritating thing is that > then I don't understand which commit fixed this. I would have guessed > b76c450eb7f6517fae24a0d7ea6431663959adf3 but that commit is in 5.0.4.2, too.) Good thing it is fixed though. I also ran it in the 5.1.0.2 build while at it and it is fixed there aswell.
Ok, did more testing. I have a old version of my workfile. If I open this old version with 5.0.4.2 and edit it with Open CL enabled I can reproduce the bug, but not with the new version of the work file I am using. Both old and new versions of my work file behave properly in 5.0.5.1 RC and 5.1.0.2. There is propably some trash data on the old file since it's over double the size of the new file with the same data.
So based on that previous comment, I would say this can be RESOLVED as FIXED then?
(In reply to Tor Lillqvist from comment #17) > So based on that previous comment, I would say this can be RESOLVED as FIXED > then? Yes, the problem seems to be fixed in 5.0.5 and 5.1. Thanks for taking care of this.