Bug 86321 - EDITING, FORMATTING: diagram didn't automatic update when change variable (steps in comment 28)
Summary: EDITING, FORMATTING: diagram didn't automatic update when change variable (st...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.3 target:7.0.6
Keywords: bibisected, bisected, regression
: 87383 87622 90083 90674 91931 136160 136254 141455 (view as bug list)
Depends on:
Blocks: Chart
  Show dependency treegraph
 
Reported: 2014-11-15 20:41 UTC by VLB
Modified: 2021-06-20 10:11 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments
Issue graphic (1.91 MB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-15 20:58 UTC, VLB
Details
Latest Issue graphic (2.39 MB, application/vnd.oasis.opendocument.spreadsheet)
2015-03-22 14:13 UTC, VLB
Details
Screenshot from rox0_9 after deletion in invoer H19:L19 (48.77 KB, image/jpeg)
2015-03-28 15:38 UTC, Buovjaga
Details
Calc file with simple XY scatter plots that neither update nor rescale. (10.85 MB, application/vnd.oasis.opendocument.spreadsheet)
2020-09-20 12:05 UTC, matthewnote
Details
AppImage bundles can repair "broken" charts on any file? Windows test please. (2.36 MB, application/vnd.oasis.opendocument.spreadsheet)
2020-10-06 08:23 UTC, matthewnote
Details
Screenshot; Comparing unzipped odf content.xml between AppImage5 and LO4 (144.81 KB, image/png)
2020-10-20 15:20 UTC, matthewnote
Details
Compare LO5 modification of Object/content.xml since removed; regression? (66.76 KB, image/png)
2020-10-20 15:52 UTC, matthewnote
Details
Opgeslagen bestand na test door VLB (2.39 MB, application/vnd.oasis.opendocument.spreadsheet)
2021-05-28 08:53 UTC, VLB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description VLB 2014-11-15 20:41:18 UTC
I have more sheets and when i change the variabele then is only the graphic on the first sheet automatic update  and not the adere graphic's on the other sheets.
Comment 1 VLB 2014-11-15 20:58:30 UTC
Created attachment 109539 [details]
Issue graphic
Comment 2 VLB 2014-11-15 21:05:35 UTC
(In reply to vlb from comment #1)
> Created attachment 109539 [details]
> Issue graphic

When it is reproduce:

Look ad graphic's in sheet "invoer" cel A57:S80 and sheet "vb_610a" cel A46:S66
Go to sheet "invoer" cel g19 and when i put 5 in this cel there isn't change the graphic on sheet "vb_610a".
Comment 3 Joel Madero 2014-11-16 20:27:49 UTC
Please provide much clearer reproducible steps (that are enumerated). Example:

1. Do X,
2. Do Y,

Expected result....

With the given information there is not enough information for us to reproduce. Marking as NEEDINFO. Once you clarify please mark as UNCONFIRMED. Thanks
Comment 4 VLB 2014-11-16 22:08:49 UTC
I try to explane the issue:
The issue isn't always present.
Today i try again and it works, but not always.

To reproduce:
1) place value "5" in cel invoer.G19
2) then in graphic M-lijn in cel invoer.L56:s63 you see tree triangels
3) when you delete the value "5" in cel invoer.G19
4) then in graphic M-lijn in cel invoer.L56:s63 you see two triangels (this is correct working)
5) in graphic "momentenlijn" in cel vb_610a.E51:N55 must do the same as in step 3 and 4
6) sometimes the graphic isn't change and see i two trangels, also when i have do step 3
7) When it doesn't work correct and i click on the graphic, than is the graphic change in tree trangels. But when i go out of the graphic i see two triangels in graphic on sheet "vb_610a".
8) When i have change someting in the graphic, then it is mostly action

In a other sheet when i have a graphic Chart type xy (scatter) with the same as step 2 and i have copyd to a other sheet and make for x-as/y-as a range values it make the range as Chart data Table with fixed x/y values in lieu of Data Range.

I hope this helps.
Comment 5 VLB 2014-11-22 13:14:48 UTC
I have test in LO 4.4.0.0 beta 1 and ther is the same issue.
Some graphic are updated when the valeue's are change and some graphics didn't update.
Comment 6 VLB 2014-11-23 10:42:06 UTC
Referring bug 86572 and do hard recalc CTRL+SHIFT+F9 than the graphic is oke.
Comment 7 raal 2014-11-23 11:10:13 UTC
*** Bug 86572 has been marked as a duplicate of this bug. ***
Comment 8 raal 2014-11-23 11:11:44 UTC
Problem with automatic recalculation.
Comment 9 VLB 2014-11-23 11:41:34 UTC
(In reply to raal from comment #7)
> *** Bug 86572 has been marked as a duplicate of this bug. ***

Bug 86572 are the value's not recalculation only in LO4.4.0.0beta1 and are correct calculation in LO 4.3.4.
Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO4.4.0.0beta1.
Comment 10 VLB 2014-11-26 19:06:07 UTC
(In reply to vlb from comment #9)
> (In reply to raal from comment #7)
> > *** Bug 86572 has been marked as a duplicate of this bug. ***
> 
> Bug 86572 are the value's not recalculation only in LO4.4.0.0beta1 and are
> correct calculation in LO 4.3.4.
> Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO4.4.0.0beta1.

I have test in daily build Version: 4.5.0.0.alpha0+
Build ID: 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494, because bug 86615 is solved.

But the bug isn't resolved for this!
Comment 11 VLB 2014-11-30 09:14:24 UTC
(In reply to vlb from comment #6)
> Referring bug 86572 and do hard recalc CTRL+SHIFT+F9 than the graphic is oke.

It didn't work always with hard recalc CTRL+SHIFT+F9, sometimes you must save the file and when you open the file again, the graphic/chart is oke.
Comment 12 Julien Nabet 2014-11-30 15:59:25 UTC
MAB => highest (see https://bugs.freedesktop.org/show_bug.cgi?id=84480)
Comment 13 raal 2014-12-17 17:51:34 UTC
*** Bug 87383 has been marked as a duplicate of this bug. ***
Comment 14 Francisco 2015-03-21 16:12:22 UTC
I have experienced this bug also. As Workaround, I simply move the chart into another position.

Regards
Comment 15 Joel Madero 2015-03-21 16:40:15 UTC
This is not a critical bug - I'm not sure who marked it as such.

Marking as:
Minor - there is a workaround (see last comment). It can slow down professional quality work but will not prevent it. Critical is reserved for major crashes and serious data loss - this is neither.

I'll leave as highest and leave it on MAB list.

Please do not revert my changes. 


What would be nice is for those seeing this issue to test older releases to see if it's a regression. http://downloadarchive.documentfoundation.org/libreoffice/old/

Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a regression (please leave a comment). If it isn't present in 3.3, then start testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where the bug came in.
Comment 16 VLB 2015-03-22 14:13:56 UTC
Created attachment 114246 [details]
Latest Issue graphic

I have test the issue in the version Lo 3.5+3.6+4.0+4.1+4.2 and works the graphic correct.
In LO 4.3.0 is the first version where the issue present.

I have a new attachment where the issue is present.

In the latest attachment you can reproduce the issue:
1) open attachment "Latest Issue graphic"
2) see the graphic in sheet "invoer L58:s64"+"vb_610a A51:p56"+"vb_610b A51:p55"+"eg A51:p55"+"loX0_9 A52:p56"+"roX0_9 A52:p57"
3)delete cell H19:l19
4) The graphic on "rox0_9 A52:p57" isn't update
5) When you double click on the graphic "rox0_9 A52:p57" you can see the correct graphic
6) When you go out the graphic the graphic isn't correct update
Comment 17 VLB 2015-03-22 14:18:38 UTC
I hope the issue can solved.
Comment 18 Joel Madero 2015-03-22 16:04:49 UTC
Woul now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect

If you need help - feel free to jump into the QA Chat: http://webchat.freenode.net/?channels=libreoffice-qa
Comment 19 Matthew Francis 2015-03-27 15:48:43 UTC Comment hidden (obsolete)
Comment 20 Matthew Francis 2015-03-28 02:10:19 UTC
Following the instructions in Comment 16, this works for me again since

    commit 8d509d69b434bd70b61cb6eed8b8dc21707726a3
    Author:     Zolnai Tamás <tamas.zolnai@collabora.com>
    AuthorDate: Mon Aug 11 14:27:16 2014 +0200
    Commit:     Markus Mohrhard <markus.mohrhard@collabora.co.uk>
    CommitDate: Fri Aug 29 17:40:29 2014 +0200
    
        This OpenGL window is useless
    
        Change-Id: Ied9914c9a317dc3945c29b984d2a68957275fc52

After this commit, the indicated chart updates after step 3, with no manual recalculation required. LO 4.4.2.1 also works as expected.
I also tested a build of 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494 as mentioned in comment 10, and the chart updated as expected there too.

@vlb:
- Please check that you are testing with the version you think you are - all other running copies of LibreOffice should be closed first. (The running version can be checked with "Help – About")
- If that doesn't work, please try following the instructions in https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile
- If that still doesn't work, please feel free to reopen this bug, confirming the latest exact version upon which you see an issue, the platform upon which you see it, and the steps followed to reproduce the issue (if the same as in a previous comment, just mentioning the comment number would be sufficient)

As it appears to me to be fixed, I am closing this bug for now.

-> RESOLVED FIXED
(a specific commit has been identified, and doesn't mention another bug ID to close this bug as a duplicate of)
Comment 21 VLB 2015-03-28 13:15:32 UTC
> @vlb:
> - Please check that you are testing with the version you think you are - all
> other running copies of LibreOffice should be closed first. (The running
> version can be checked with "Help – About")
yes i have test with the latest version LO 4.4.1.2

> - If that doesn't work, please try following the instructions in
> https://wiki.documentfoundation.org/
> UserProfile#Resolving_corruption_in_the_user_profile
I have done but didn't work by the steps comment 16
Comment 22 VLB 2015-03-28 13:38:55 UTC
> After this commit, the indicated chart updates after step 3, with no manual
> recalculation required. LO 4.4.2.1 also works as expected.
> I also tested a build of 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494 as
> mentioned in comment 10, and the chart updated as expected there too.

I have also test in LO 4.4.2.1 Build ID: 93fc8832889bf050a10ec6d0171dae213adc9b55

and here is the same problem, by do the steps in comment 16!
Comment 23 Matthew Francis 2015-03-28 13:43:45 UTC Comment hidden (obsolete)
Comment 24 VLB 2015-03-28 13:47:35 UTC
(In reply to Matthew Francis from comment #23)
> @vlb: Could you let us know what platform (OS) and version you're using
> Thanks

I use windows 7 Professional servivce pack 1 64-bits i7 and 4GB RAM
Comment 25 Cor Nouws 2015-03-28 14:03:54 UTC
(In reply to vlb from comment #22)

> I have also test in LO 4.4.2.1 Build ID:
> 93fc8832889bf050a10ec6d0171dae213adc9b55
> 
> and here is the same problem, by do the steps in comment 16!

Hi Frank,

I confirm the behavior that you mention.

1. Double click the diagram on "rox0_9 A52:p57" 
   It is still the same.
2. Leave the diagram and delete cell H19:l19
   The diagram is still the same
3. Now again double click the diagram on "rox0_9 A52:p57" 
   It changes
4. Leave the diagram
   It returns to the previous state.

However, may be me, I fail to see the logic of the diagram, having the data ranges
   $roX0_9.$U$9:$V$18;$roX0_9.$CS$3:$CS$153
(you may mail me and explain in Dutch what is going on, if you prefer.)

thanks,
Cor
Comment 26 Cor Nouws 2015-03-28 14:04:51 UTC
(In reply to Cor Nouws from comment #25)

> I confirm the behavior that you mention.

   on Ubuntu 32 bits

> 2. Leave the diagram and delete cell H19:l19

   on sheet *invoer*
Comment 27 Buovjaga 2015-03-28 15:38:27 UTC
Created attachment 114419 [details]
Screenshot from rox0_9 after deletion in invoer H19:L19

1) Went to sheet invoer
2) Deleted contents of H19:L19
3) Went to rox0_9 and took this screenshot

Decide for yourself. At least the chart was updated immediately after deletion of data without me doing any double-clicking.

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 28 Matthew Francis 2015-03-28 16:21:25 UTC
OK, so I see what I did wrong before. The already fixed bug I mentioned in comment 20 was for the chart in the "invoer" sheet, which works in 4.4 already

The issue I now see was meant is for the "roX0_9" chart, and is reproduced as follows:
1. Open attachment 114246 [details]
2. Go to sheet "roX0_9"
3. Go to sheet "invoer"
4. Delete H19:L19
5. Go back to sheet "rox0_9"

The diagram at A52:57 has not updated, but shows the updated values when edited.
Note that the bug does not reproduce if step 2 is skipped.
Comment 29 Matthew Francis 2015-03-28 16:26:04 UTC
The remaining issue also appears to have been fixed, in the below commit:

commit dc28e90d200a839d4017d548217ee5ce8a23f848
Author: Noel Grandin <noel@peralex.com>
Date:   Thu Dec 25 15:17:55 2014 +0200

    fdo#84938: convert IMPORT_ constants to 'enum class'
    
    Change-Id: Idaa8f07c62b3ba93c27ca5fe286720254baac10d


From examination of its content, it's clear why this may be the case. However, this commit also possibly didn't intend to fix anything - it looks like it was supposed to be just a refactoring.

Assigning to markus.mohrhard@googlemail.com by his request for further investigation as to whether this fix is correct.
Comment 30 Cor Nouws 2015-03-28 19:54:15 UTC
(In reply to Beluga from comment #27)

> Decide for yourself. At least the chart was updated immediately after
> deletion of data without me doing any double-clicking.


The chart on "rox0_9 A58:p62" , but not the one on "rox0_9 A52:p57"
Comment 31 Matthew Francis 2015-04-03 04:32:31 UTC
*** Bug 90083 has been marked as a duplicate of this bug. ***
Comment 32 Matthew Francis 2015-04-23 09:33:44 UTC
*** Bug 90674 has been marked as a duplicate of this bug. ***
Comment 33 Matthew Francis 2015-04-23 11:56:53 UTC
*** Bug 87622 has been marked as a duplicate of this bug. ***
Comment 34 tommy27 2015-06-27 06:11:44 UTC
please give an update of the current bug status with latest 4.4.x or master builds.

if issue is definitively gone let's finallly close this.

if some problem persists I suggest to close this report anyway since it's getting hard to follow it (many comments and many different steps to reproduce) and start again from scratch with a new clean bug report
Comment 35 VLB 2015-06-29 18:40:04 UTC
(In reply to tommy27 from comment #34)
> please give an update of the current bug status with latest 4.4.x or master
> builds.
I have take the steps in comment 25 with attachment "Latest Issue graphic" with LO 4.4.4.2 and the graphic didn't correct update.
When i use LO 5.0.0.2 for the attachment is the graphic correct update, but when i use a other sheet the graphic didn't update. It isn't a constant issue and make it diffecult.


> if some problem persists I suggest to close this report anyway since it's
> getting hard to follow it (many comments and many different steps to
> reproduce) and start again from scratch with a new clean bug report

Because the update graphic isn't constant it's defficult make a good example.
I hope it is solve the issue here.
Comment 36 Matthew Francis 2015-08-14 02:45:14 UTC
*** Bug 91931 has been marked as a duplicate of this bug. ***
Comment 37 Robinson Tryon (qubit) 2015-12-13 11:11:02 UTC Comment hidden (obsolete)
Comment 38 Xisco Faulí 2017-09-11 08:59:29 UTC
Dear developer,
This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 39 Mike Kaganski 2017-11-07 10:42:35 UTC
A patch proposed for bug 31231 (https://gerrit.libreoffice.org/44396) will revert the change that was reported to fix things here (in comment 29).
Comment 40 Eike Rathke 2017-11-14 17:27:18 UTC
This doesn't even seem to be a Calc problem, one can as well directly modify the values in the chart's (Object 15) data range $roX0_9.$U$9:$U$18 (i.e. set U13:U18 to 8 which is the same value as when deleting invoer.H19:L19, or any other value fwiw) and the chart does not update. BUT, double clicking it reveals the updated chart according to the values. Leaving the chart again displays the old values. Also modifying the data ranges for data series 'Column V' doesn't change that. Something seems to be broken with the chart view representation (old replacement/preview view used?).
Comment 41 VLB 2017-12-20 13:06:20 UTC
I have test with the latest version LO 6.0.0.0beta 2 and it is still present.
Comment 42 VLB 2018-05-30 20:13:45 UTC
I have test in Versie: 6.0.4.2 (x64)and is still present.
Comment 43 matthewnote 2018-10-31 17:25:35 UTC
Charts not updating (x, y scatter plots) is still present in Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1.  Usually, when a column is recalculated there's a leap in processor use (CPU 100% for three seconds) as the graphic engine presents the fresh image of charts concerned.  

When the chart appears to be "broken", the data column modifies, yet not the charts and the CPU remains at idle.  For 100 x,y scatter plots here, after an hour of data work, about half the charts are inert, not moving - and you don't know which except by inspecting all of them. 

Clicking on one of the charts then dragging it a few pixels - only that chart updates (comment 14) so it takes an hour's work for one digit change.  If the user zooms by menu or Ctrl+mousewheel out then back in, the whole screen including all charts visible update to the new values. It's a faster workaround and may help learn what the bug is?  

For each data change it's necessary to zoomin/zoomout again.  Very surprised to see this marked as importance  "minor".  Closing and reloading Calc in safe mode brings all charts back to life (autoupdating) yet it's impractical to do that thirty or fifty times a day.  I've tried every safe mode too.

I volunteer for user debug work using this system if it helps.
Comment 44 VLB 2019-10-22 17:40:28 UTC
The bug is in LO Versie: 6.3.2.2 (x64)still present.
Comment 45 matthewnote 2020-09-20 12:05:29 UTC
Created attachment 165696 [details]
Calc file with simple XY scatter plots that neither update nor rescale.
Comment 46 matthewnote 2020-09-20 12:08:47 UTC
This Bug is still present in
LO Calc 6.3.4
LO Calc 6.3.5.2
(using OS Ubuntu 18.04 LTS)
LO Calc 7.0.1.2
(also on Ubuntu 18.04 LTS)
All safe modes tried.  LO reinstalls also.

For Joel.   This is proving very difficult to provide a "method" to create a broken X,Y scatter diagram.  In four years I've not yet been able to cause it deliberately step by step. So I contribute a sample file with broken graphics (an early learning file not intended for presentation). 

General situation description.  Inserting an X,Y scatter chart, the plotting updates for a few days work and follows new results in it's Data Range cells, then abruptly stops updating.  Sometimes it's a graph done at the start, sometimes it's only a copy, sometimes it's both, then half of all graphs stop updating.  Sometimes reopening the file gives the user one more operation, you can watch the result of a number change on the plot, yet only once. The workload to continue using the file is huge.  

Here there are now three or four hundred files (Cancer data) based on about five general structures and (as of January 2017 to September 2020), regrettably, only one has all graphics following data input changes.

Calc 7.0.1.2. I was able to use a file more than twice. Testing Calc 7.0.1.2 with another near identical file (recently modified using 6.3.5.2) of the same size too, that second file opens and none of the X,Y scatter plots update, none at all.  Never seen that before either (all plots broken after File>Open).  (Usually some plots keep updating occasionally then break and never repair.)

This is else than "minor";   the workload is crushing.  Reason. Unfortunately a bug report moderator considers that autoscale on the Y axis doesn't need to function correctly for X,Y scatter (although users are desperate to have it function the same as autoscale X axis and write macros to try to do what the moderator refuses).  When the data preparation for a graphic changes from y values to LN(y) values (for example), you not only have half or more than half the plots don't update at all  -  If you double click on any, the new presentation will jump and show the Y values squashed at the top.   If you go back to click a cell on the sheet (for example to change a 1.0 to a 1.1) all the plots go off again to the old values.  Moving or rescaling all the plots to cause one update to be shown once - well, I spent about two months of the twelve in 2019 only doing that, sometimes collapsing with exhaustion. 

Why is autoscaling for technical users important?  The sample file has very many plots.  The actual Cancer data work chooses to make only a few plotters to minimise the processing load.  On it's sheet, that plotter fetches or reads the data from columns.  Those columns are indirect adressing so that the user selects the data sheet name for X axis and another data sheet name for Y axis.  That way, there can be fourty simple sheets of numbers and only one X,Y plotter is needed. 

Note: One screenshot or copy of one plot for a slide presentation using histogram style autoscaling or forcing a manual Y axis scale may be the intention of some Calc users or administration staff.  It's unusable for investigation work.  

For Xisco Pauli.  Please assign this subject to someone "technical" rather than "presentation". Personally I only ask Calc to use +, -, *, /, LN() and EXP() then plot.  I can exhaust myself yet feel unable to share any of the four years work.  I stay with LibreOffice with some sort of confidence that it will work out.  (As a Raytheon real-time software testing engineer you learn to share Bug information without worry and never ever put down the user point of view as trivial or minor.  That attitude is absent, so, well, without effort to not do it either) :).

Therefore I add a sample file.  Although it were best to prepare a smaller file, I've tried trimming and deleting sheets with new problems every occasion. 

LO 7.0,1.2 purged, LO 6.3.5.2 default for Ubuntu 18.04 installed.
Opening sample "BMI BM BMH switch expt10.ods" displays sheet "TheSWITCHexpanded".
X,Y scatter (reading columns P,M,D) is on the area C283 to P342.
Cell L259 multiplies x values for that scatter diagram (default value is 17).
Step one.  Click on L259, enter 25.
Result.  The graph below fails to update.
Expected result.  The plot moves red and violet points to the new x positions.
Step two. Clickandhold on the frame of the graph, dragging it one or two pixels.  Release the mouse button.
Result.  The graph updates to the new data.
Step three.  Double click the plot itself and change Y axis scaling to autoscale.
Result.  The y axis scale changes to 0 <-> 45 with all data squashed in the top third.
Expected result.  y axis autoscale perform precisely the same as x.  This is very important for technical use of any data.  x values same as y values should always produce a linear trend line to an origin of (x,y) where x and y are identical too.
Step four.  Click again once on any cell to quit the graphic.
Step five.  Double click the plot and change Y axis scaling to manual 15 <-> 45.
Result.  The plot adopts the new scale.
Step six.  Click on any cell to quit the graphic.
Result.  The plot displays Y axis scaling on 25 <-> 45, ignoring the user entries.
Expected result.  The manual scale 15 <-> 45.
Step seven. Clickandhold on the frame of the graph, dragging it one or two pixels. Release mouse button.
Result.  The plot updates to the user requirement (but only once).
Expected result.  Plot updates to any of it's Data Range cell changes always.

My thanks.  Calc 6.x.x.x and 7.0.1.2 plots are astounding quality.  I use 4K monitors; the antialising is brilliant and the scatter plots with trend lines surpass all other software used here (Paraview, Scilabs equivalent Matlab).  Ubuntu 18.04 is rock solid (thanks to choosing Gnome) and Calc 7 is marvellous.  If someone wishes to see a Cancer data analysis user file with the indirect addressing and all X,Y scatter plots (suddenly) working (to have a look at a technical/scientific use of Calc - where it can go), I have one file that works.   It's 102 MB, uses external links to files of 30 MB more and runs quite comfortably on a Kaby Lake 3.6Ghz 16GB desktop.  Calc is very impressive software.  Sometimes I just sit and think about the talent.  Thankyou.
Comment 47 Lars Jødal 2020-09-21 05:53:24 UTC
Importance: I agree that trustworthy updating of plots is important, especially if you work with many plots. A few years ago, I used LO for my Ph.D. project, and it was huge problem to me that plots very often did not update - I did not know which plots I could trust, and there were a lot of them, so a workaround of moving all plot a few pixels each was very unattractive. (But yes, I kept using LO, and I am still a user.)

Pinning it down: Like matthewnote writes, it is not an issue that is easy to pin down. I have mostly experienced it with many plots, something many users are not going to do.

Status of the bug? I just tested matthewnote's sample file, attachment 165696 [details], using LO 7.0.1.2 on Win10. Interestingly, the plot does seem to update immediately (well, within a second), while I can confirm that the Y axis seem to prefer to start from 0 when autoscaling. However, matthewnote includes 7.0.1.2 among the tested versions that still has the bug. Can others reproduce the non-updata part of the bug with the 7.0.x line of LO? See description in comment 46.

(If one day only the autoscaling problem is left, it is probably better to open a new bug about that problem, which should be much more simple to describe.)

Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: threaded
Comment 48 matthewnote 2020-09-23 10:42:29 UTC
This problem is also consulted on "Ask LibreOffice" since Calc 4.4.3 2015.
https://ask.libreoffice.org/en/question/53027/chart-does-not-update-when-cell-content-change/

Alex Kemp closed it as "not relevant or outdated".  No idea why.  So the users go away from LibreOffice or a few come here.

This Bug and Bugs #136254 #136160.

Update.  The sample file from me has received further testing.
1.  Someone else's PC with Apache OpenOffice 4.1.1 (2014) on Puppy Linux.
Result.  Chart fails to update when a cell value is changed.

2.  Apache OpenOffice 4.1.7 (2019) on Puppy Linux.
Result.  Chart fails to update.

3.  LibreOffice Calc 6.4.5.2 on Ubuntu Fossa 20.04 (Linux 5.4).
Result.  Chart fails to update.

4.  Calc 7.0.1.2 package 1:7.0.1-0ubuntu1_oibaf~f installed by automatic upgrade on same Ubuntu Fossa 20.04.
Result.   Chart started working!  File saved.

5.  Opened the saved file from Fossa PC on a different PC.
Calc 6.3.5.2 (1:6.3.5~rc2-0ubuntu0.18.04.1~lo1) on Ubuntu 18.04 (Linux 4.15)
Result.  The new sample file seen to work once on Fossa - not working here.

6.  Update computer to Calc 7.0.1.2 (package 1:7.0.1_rc2-0ubuntu0.18.04.1)
Result.  The new sample file that works on Fossa - works here too.  Chart updates.

7.  The original broken file (attached to this Bug report) opened on the Ubuntu 18.04 computer as at test 6 using Calc 7.0.1.2.
Result.  The old sample file (broken) now works.  Chart update.

Implications.  It seems possible to find a system configuration that will load a file with broken charts causing them to "work".   That saved, the "possibly repaired" file can be used on the computer with all-loads-fail (including safe modes) and it works there.   Then, very surprising, the computer with all-loads-fail can open it's own original (broken) file and use it.  Can computer B teach computer A how to load charts correctly?

8.  This implication was tested using a much larger file (102 MB).
Result.  On the Ubuntu 18.04 and Fossa 20.04 computer with 7.0.1.2, none of the 24 charts update with data changes;   none at all.

9.  With that large file, one of all the paralysed charts was copied and pasted on the same sheet side by side.   The twin autoupdates with cell value changes.
It's original remains "off".

Further testing.  At some stage I have to get back to Cancer or leave LibreOffice.  What I will do is attempt to recreate the whole 102MB file.
Some users report that they "feel" reconstructing a file helps clean out "something".  By opening a new sheet and building it up using "Insert Sheet from File" they find the result is small than the original source.  It's a laborious sheet by sheet procedure with new problems, including the insertion causing External Links even though the Ext Links is deselected.  Yet it's possible to get through with checking every single cell (or by search) and editting out false linking.  I did this routine this year once with one file and it seemed to help yet I couldn't finish the job;  large file saving caused Calc 6.3.4 crash (linux disk cache going up gradually to 5.5G then Calc crash at 5.6G every time).  Also copying one near empty sheet required 8 to 9 minutes.

With LO7.0.1.2 copying a sheet of only numbers is done in five seconds and saving a large file works every time (so far since one month).  Great!  So I'll stick with it, contribute some more and hope Xisco is being informed.
Comment 49 Buovjaga 2020-09-23 12:09:29 UTC
(In reply to Matthew Francis from comment #28)
> OK, so I see what I did wrong before. The already fixed bug I mentioned in
> comment 20 was for the chart in the "invoer" sheet, which works in 4.4
> already
> 
> The issue I now see was meant is for the "roX0_9" chart, and is reproduced
> as follows:
> 1. Open attachment 114246 [details]
> 2. Go to sheet "roX0_9"
> 3. Go to sheet "invoer"
> 4. Delete H19:L19
> 5. Go back to sheet "rox0_9"
> 
> The diagram at A52:57 has not updated, but shows the updated values when
> edited.
> Note that the bug does not reproduce if step 2 is skipped.

I still reproduce this problem.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: f08ddf3d3df0ef12fef36e96ffe6f5b9a7fda9e3
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 21 September 2020
Comment 50 matthewnote 2020-09-27 15:30:42 UTC
More history about this "data value changes, charts not".  Calc 4.1.3.2.

Apache OpenOffice has the same problem since 2014 and still does (June 2020).

The earliest/last known version of LibreOffice Calc that would open a broken Apache .ods and show the charts updating consistently (by comparison and file rescue attempts) was reported to be Calc 4.1.3.2.

https://forum-test.openoffice.org/en/forum/viewtopic.php?t=71092&p=370292

Users try out OpenOffice then leave, going back to Excel due to this.
Will attempt to find out if Apache Bug report exists.  This topic is more than MAB or a "slight loss in productivity".  The charts create well, present well, yet unless they update, it's unrealistic for a project that will be shared and a huge shock for a user who invests heavily before finding this out.
Comment 51 matthewnote 2020-09-30 07:15:15 UTC Comment hidden (obsolete)
Comment 52 VLB 2020-09-30 07:42:44 UTC
> 
> Users try out OpenOffice then leave, going back to Excel due to this.
> Will attempt to find out if Apache Bug report exists.  This topic is more
> than MAB or a "slight loss in productivity".  The charts create well,
> present well, yet unless they update, it's unrealistic for a project that
> will be shared and a huge shock for a user who invests heavily before
> finding this out.

As a user of LO I can confirm this and it is essential that this works well!
In my work as a constructor, misinterpretations are regularly done, because the graph gives wrong information after updating the values.
This can lead to serious construction errors with the consequences!
I would really appreciate it if this important issue can be resolved.
Comment 53 Lars Jødal 2020-09-30 09:48:12 UTC
I have changed the "Severity" field from "minor" to "normal". 

It is definitely more than just a minor nuisance, and those of us experiencing the bug may consider it major, but it seems that we are only a minority of users experiencing (or noticing?) the bug, so I kept at "normal".

In any case, let's remember that LO is a project mostly performed by volunteers, and however a given bug is flagged, it is only fixed if somebody does fix it. With Bugzilla we have a flexible system for reporting bugs and providing examples. (If there is something similar for commercial systems like MS Office, I am not aware of it.) As I saw regarding some other bug that was very annoying to a user, a user has the following options after reporting a bug:

1. Fix it yourself. After all, the code is freely available, and volunteers fixing bugs are how most bugs are fixed. https://www.libreoffice.org/community/developers/

2. Convince someone to fix it. Works best if you happen to know a programmer who is already doing work on LO.

3. Pay somebody to fix it. If you or your company have the money for it, there are professional developers that fix LO bugs, incorporating the fix into the mainline so everybody can benefit from the fix. https://www.libreoffice.org/get-help/professional-support/

4. Wait.

As for myself, I am not into the LO code, knows nobody personally who is, and do not have the money for hiring somebody to do the job. So I attempt to make good bug reports with easy-to-reproduce examples (when possible), and then settle for option 4. It can be annoying when the bug or enhancement request is important to me, but that is my option. And it does not stop me from being thankful that LO is there at all - in some cases with better features than MSO, in other cases with not quite as good features, but in all cases free to use if I want it.
Comment 54 Buovjaga 2020-09-30 10:54:51 UTC
(In reply to Lars Jødal from comment #53)
> As for myself, I am not into the LO code, knows nobody personally who is,
> and do not have the money for hiring somebody to do the job. So I attempt to
> make good bug reports with easy-to-reproduce examples (when possible), and
> then settle for option 4.

Remember that you don't have to limit yourself to creating reports, you can also analyse the reports of others, which can be very valuable: https://wiki.documentfoundation.org/QA/GetInvolved#Quick_start_guide_for_beginners

I'm not going to debate the severity, but we define even minor as making it "substantially harder to make high quality work or require users to not use some features": https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Comment 55 matthewnote 2020-09-30 14:56:48 UTC
(In reply to Lars Jødal from comment #47)
> Importance: I agree that trustworthy updating of plots is important,
> especially if you work with many plots. A few years ago, I used LO for my
> Ph.D. project, and it was huge problem to me that plots very often did not
> update - I did not know which plots I could trust, and there were a lot of
> them, so a workaround of moving all plot a few pixels each was very
> unattractive. (But yes, I kept using LO, and I am still a user.)
> 
> Pinning it down: Like matthewnote writes, it is not an issue that is easy to
> pin down. I have mostly experienced it with many plots, something many users
> are not going to do.
> 
> Status of the bug? I just tested matthewnote's sample file, attachment
> 165696 [details], using LO 7.0.1.2 on Win10. Interestingly, the plot does
> seem to update immediately (well, within a second), while I can confirm that
> the Y axis seem to prefer to start from 0 when autoscaling. However,
> matthewnote includes 7.0.1.2 among the tested versions that still has the
> bug. Can others reproduce the non-updata part of the bug with the 7.0.x line
> of LO? See description in comment 46.
> 
> (If one day only the autoscaling problem is left, it is probably better to
> open a new bug about that problem, which should be much more simple to
> describe.)
> 
> Version: 7.0.1.2 (x64)
> Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
> CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL:
> win
> Locale: da-DK (da_DK); UI: da-DK
> Calc: threaded

Thankyou Lars for your observations.  This week I'm putting off returning to Cancer research (unpaid, as it often is) and investigating this Bug.  I may have a clue after unzipping the files and inspecting Object folders.  There is a difference and somewhere, Calc versions may decompress/infer objects differently when opening.  When saving, there are new additional folders which I find in "working spreadsheets" (!) and find also a different META-INF/manifest.xml manifest:version.  (version 1.3 rather than 1.2).  No idea yet how a Calc version did that, yet willing to learn.

Would you have a moment to open again my attachment http://bugs.documentfoundation.org/attachment.cgi?id=165696
check it's still working with you, save it with a new name using your Windows Build and send it to me by email?

I've two Linux workstations here, no Windows.
Are you still on precisely the same LO Calc Version and Build?  It may be one of the few that gets this right.

By the way, I did consider virus (really!) and had the sample file scanned by 15 different virus scanners.  All well there.

Hopefully yours
Matthew
Comment 56 Lars Jødal 2020-10-01 05:39:44 UTC
Interesting. I tested attachment 165696 [details] on two different installations (on two different computers, both running Win10), running the current "still" and "fresh" versions of LO. More details below, but the result was that update did NOT work on LO 6.4.6.2, while update DID work on LO 7.0.1.2.

Test file: matthewnote's attachment 165696 [details]

Doing what: Cell L259 on sheet "The SWITCHexpanded" contains the number 17. Changing 17 to 25 should give a visible change to the XY plot covering about C283 to P341 (based on description in comment 46).

Results with LO 6.4.6.2: Changing 17 -> 25 gives no visible effect. CTRL-SHIFT-F9 does not change that. Double-clicking on the diagram does give the effect (points move to a different configuration), but it is reversed when focus leaves the diagram. Conclusion: Update does NOT work.

Version: 6.4.6.2 (x64)
Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
Locale: da-DK (da_DK); UI-Language: en-GB
Calc: threaded

Results with LO 7.0.1.2: Changing 17 -> 25 changes the plot within a fraction of a second. Conclusion: Update DOES work.

Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: threaded

@matthewnote: I will email you a saved version of the file. Have you tried a user profile reset?
Comment 57 matthewnote 2020-10-01 07:05:01 UTC
(In reply to Lars Jødal from comment #56)
> Interesting. I tested attachment 165696 [details] on two different
> installations (on two different computers, both running Win10), running the
> current "still" and "fresh" versions of LO. More details below, but the
> result was that update did NOT work on LO 6.4.6.2, while update DID work on
> LO 7.0.1.2.
> 
> Test file: matthewnote's attachment 165696 [details]
> 
> Doing what: Cell L259 on sheet "The SWITCHexpanded" contains the number 17.
> Changing 17 to 25 should give a visible change to the XY plot covering about
> C283 to P341 (based on description in comment 46).
> 
> Results with LO 6.4.6.2: Changing 17 -> 25 gives no visible effect.
> CTRL-SHIFT-F9 does not change that. Double-clicking on the diagram does give
> the effect (points move to a different configuration), but it is reversed
> when focus leaves the diagram. Conclusion: Update does NOT work.
> 
> Version: 6.4.6.2 (x64)
> Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
> CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
> Locale: da-DK (da_DK); UI-Language: en-GB
> Calc: threaded
> 
> Results with LO 7.0.1.2: Changing 17 -> 25 changes the plot within a
> fraction of a second. Conclusion: Update DOES work.
> 
> Version: 7.0.1.2 (x64)
> Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
> CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL:
> win
> Locale: da-DK (da_DK); UI: da-DK
> Calc: threaded
> 
> @matthewnote: I will email you a saved version of the file. Have you tried a
> user profile reset?

Thankyou Lars

Yes, I've been doing all Safe Modes.   Specifically, only one file here (of about three hundred) updates charts and I'm unable to cause any of them to break (for the moment, yet only for that file).  How did that happen?  I was creating spreadsheets with versions up to 6.4.5.2 (the Ubuntu 18.04 Bionic Beaver tested companion LibreOffice versions upgrade about every three months that they recommend as "conservative").   All work had broken charts after a day or a week.  So I tried out reconstructing a large file by starting a new ODF and  sheet by sheet "Insert sheet from file" (from faulty file to fresh start).  A type of "importing" to build up a new one.   Still unsuccessful.  A message circulated on the web that a Ubuntu 18.04 conservative user could ppa install LO 7.0.1.2 and purge it out to the default "official" LO 6 if necessary (go-back possible).   Nothing to lose so I did that.  The install overwrites a lot yet completed just fine.

First try with the fresh file under reconstruction using LO 7.0.1.2 and all charts worked.  All of them.  Amazing. My first and only ever.  So, I tried to rescue another key file of the project here the same way, identical procedure - and none of the charts worked, none at all.  All safe modes explored.  

To test the possibility "Upgrading to LO 7 gives you one shot with one file to cause one repair" I purged LO 7, restarted Linux with 6.4.5.2;  then restart again, then re-do the ppa LO 7.  Same message "Welcome to LO 7 - did you know etcetera" apparently with a fresh user profile.   However it didn't cause the second file to repair and run correctly.   There's a possibility that if I wipe the workstation disk or attempt a dual boot to a separate partition and go up through the procedure again, perhaps I can get "one more success" for one more file.  However, for the moment I'm exploring files by unzipping them and reading their .xml

I have found one significant difference with the only stable-always-working-charts-update file.  Unzipping the .ods, reveals that it has a folder that my other files lack.  \ObjectReplacements.  In that folder there is a binary file for each and every chart object listed in the manifest (META-INF/manifest.xml).  The binaries (that apparently came from nowhere) are Type STL 3D model (binary) (model/x.stl-binary) according to Linux.  Never heard of it.  The total folder content is 124 MB (the contents of that folder unzipped) which is very light.  Once the file is opened (takes 7 GB of RAM) I don't see a significant increase in use of memory.

The manifest.xml of the fully working file also has a difference.  It points to that extra folder ;
full-path="ObjectReplacements/Object n" manifest:media-type="application/x-openoffice-gdimetafile;windows_formatname=&quot;GDIMetaFile&quot;"
None of the broken files have that xml manifest entry.

None of the broken files have that folder.  Most of them are listing
manifest:manifest xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0" manifest:version="1.2" xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0">
 <manifest:file-entry manifest:full-path="/" manifest:version="1.2" manifest:media-type="application/vnd.oasis.opendocument.spreadsheet"/>

yet a few broken files state they're configured for manifest:version="1.3" (the latest).  The only fully working file uses "1.3" also.

So I continue to search to learn about ObjectReplacements Chart binaries and how they got there.  I've read other users gave up trying to find out more about that subject.  Perhaps a programmer knows immediately what that's all about.

Tomorrow I'll be inspecting the file you returned to me having passed it through a Windows build.  (I'm going to a hospital today).

Matthew
Comment 58 matthewnote 2020-10-01 07:48:10 UTC
Additional note/reminder for others reading this thread.
My sample file is only done on Ubuntu LO 6.   I don't have a Windows workstation here.  LibreOffice is chosen for the project because the medical data is coming in from all over the world, from some very remote regions.  Isolated groups of up to 100 000 people is (in this subject) the most valuable and it's extremely accurate.  They can be seriously ill and it gets reported precisely.  However, for many, access to information technology is only for a few administrators, beyond the reach of nurses and clinical staff with near no budget for that.  Pen and paper only.  With LibreOffice, if they have access at home, the intention is to provide three levels of spreadsheet complexity/capability and they can see it for themselves.  It's an ideal scenario for open source software - once I can share it.
Comment 59 matthewnote 2020-10-03 13:17:42 UTC
Testing attachment 165696 [details] not working LO 6.4.6.2

I attempted a manual modification of my attachment .ods to cause Calc to generate ObjectReplacements folder and object binaries.  The idea was to cause it to be the same as the unique unusual very large file here which always works (unbreakable so far and has the unique ObjectReplacements folder).

1.  Unzipped 165696 .ods
2.  Edited META-INF manifest.xml
3.  Added line full-path for each and every Object (example 462) known also in the manifest.xml

<manifest:file-entry manifest:full-path="ObjectReplacements/Object 462" manifest:media-type="application/x-openoffice-gdimetafile;windows_formatname=&quot;GDIMetaFile&quot;"/>

4.  Added manually new empty folder ObjectReplacements (ready for Calc to insert binaries or due to Bug odd behaviour perhaps cause/Enable cache/Table redraw triggering).  Don't know so try it out . . . .
5.  Zipped everything up using zip -r ../test.ods mimetype *
6.  Unzip again to check the full list and again the manifest.  All OK there.
7.  Run test.ods on LO7.0.1.2 on Fossa 20.04.  Charts update (!).  So a repair may have occurred.  
8.  However, saving a copy as "tested on LO7.ods", unzip it, the manual changes have been eliminated/deleted.  The folder has gone and the manifest entry also.  It will take a while to learn if the 165696 file is now unbreakable.  Usually a few edits, copies, new sheets or copy a chart will break other charts.

9.  Run test.ods (reconstructed file with manual mods) on LO7.0.1.2 on Bionic Beaver 18.04.  Results as for steps 7 and 8. Charts now work.  Manual modifications also eliminated after saving.

Next I'll test VLB's file and test.ods on LO6.4.5.2.  (I purge the repository ppa of LO7 to do that.  Ubuntu 18.04 goes back to default companion package 6.x.x.x.

Anyone know why one use of LO7.0.1.2 will create ObjectReplacements and another use will delete the folder?

More later. . . .
Comment 60 matthewnote 2020-10-03 13:46:01 UTC
After a purge of ppa LO7.0.1.2, Ubuntu BBeaver 18.04 offered LO6.3.5.2, so installed that.

Results.
Testing attachment 165696 [details] the chart fails to update (as before).
Testing the test.ods (same as 165696 but with manually edited manifest.xml and manually added ObjectReplacements folder) chart fails to update.

Saved the test.ods as a copy using LO6.3.5.2 then unzip to find out changes.  The software run removed/cleaned the manual entries from manifest.xml and ignored/deleted the manually added ObjectReplacements folder.

Provisional conclusion:  
1.  A User is unable to provoke the generation of ObjectReplacements.  
2.  Use of LO7.0.1.2 sometimes will cause the attachment file Chart to update and sometimes not.  
3.  The LO7.0.1.2 first upgrade/install on Ubuntu 18.04 caused a freak incident that repaired a very large file, only once (which uniquely has a software generated ObjectReplacements folder). It also broke a partly working very large file such that no Charts update; none at all (without generating the mystery ObjectReplacements folder either in that case).
4. Unfortunately, LO7.0.1.2 works only sporadically as a repair tool.

more testing on VLB's file to be done.
Comment 61 matthewnote 2020-10-03 15:42:03 UTC
VLB's file attachment 114246 [details] tested using method at comment #28

The file meta.xml shows generator as
LibreOffice/4.4.1.2$Windows_x86 LibreOffice_project/45e2de17089c24a1fa810c8f975a7171ba4cd432

Tested on Calc 7.0.1.2 on Fossa 20.04.  Chart fails to update.
Tested on Calc 6.3.5.2 on Ubuntu Bionic Beaver 18.04.  Chart fails to update.

Unzipped the .ods.  VLB's file does have an ObjectReplacements folder and
manifest.xml entries showing full-path to that folder for each and every Object.
Comment 62 matthewnote 2020-10-06 08:23:54 UTC
Created attachment 166115 [details]
AppImage bundles can repair "broken" charts on any file? Windows test please.

(In reply to Eike Rathke from comment #40)
> This doesn't even seem to be a Calc problem, one can as well directly modify
> the values in the chart's (Object 15) data range $roX0_9.$U$9:$U$18 (i.e.
> set U13:U18 to 8 which is the same value as when deleting invoer.H19:L19, or
> any other value fwiw) and the chart does not update. BUT, double clicking it
> reveals the updated chart according to the values. Leaving the chart again
> displays the old values. Also modifying the data ranges for data series
> 'Column V' doesn't change that. Something seems to be broken with the chart
> view representation (old replacement/preview view used?).

Tested VLB's attachment sample here on two Linux PCs.
File repair accomplished on Linux machines.

1.  Download AppImage from Antonio's library of old versions:
https://libreoffice.soluzioniopen.com/old/LibreOffice-5.3.6-x86_64.AppImage

2.  Make the file executable.  Run the AppImage on either Ubuntu 18.04 or 20.04.
Tools>Options>Load/Save>General> switch off autorecovery saving, check ODF format set to 1.2 (Extended).

3.  Open attachment 109539 [details] or attachment 114246 [details] or my sample attachment 165696 [details].

4.  All Charts update with any user operation (here).

5.  Save the resulting file to a new file name (necessary before step 6).

6.  Files now load, charts now update (all samples) on Installed Calc versions
LO6.3.5.2 on Ubuntu 18.04.  LO7.0.1.2 on Ubuntu 20.04.
    Repaired files now load, charts update on AppImage version LO5.3.6.1 and AppImage version LO6.5.3.2 and AppImage version (fresh) LO7.0.1.2.


7.  For Users reading this Bug, the AppImage project produces "boxed" full LibreOffice versions without installing anything.  This is similar to .sfs "boxed" full versions available to Linux Puppy users.  (I don't know if Windows has or will have an equivalent).   So, for Windows OS users, you'll need to find a friend or a Linux partition to use AppImages as repair tool.

8.  For Developers.
a.  Antonio's AppImage 4.1.0.4 failed to start on either Linux 18.04 or 20.04.
b.  AppImage 6.3.5.2 ran on both Linux yet failed to cause chart updates.
c.  AppImage 6.3.5.2 opens all, charts updates if they've been save at least once using AppImage 5.3.6.1.
d.  AppImage 5.3.6.1 (the successful Repair Tool) failed to run on Fossa 20.04 at the first try, yet double-clicking it later and again later (the third occasion), the application launched (very strange!).  It seems only Antonio's 7.0.1.2 "fresh" has a Fossa Ubuntu 20.04 flavour.  Not sure why the AppImage 5.3.6.1 had difficulty attracting software interrupt attention.  Another clue?

Would ladies, gentlemen please test the "seems repaired" VLB sample on Windows and report result?  Attached with this message.  Method is at comment 28.

[By the way, the Repair Method using AppImage works also for my upload and this morning I tried it out on the very large (102MB) Diabetes file study here with 42 charts.  Half of the charts were "broken" and now . . . . . . all are working!  I'm very happy this morning).
Comment 63 matthewnote 2020-10-06 12:38:36 UTC
Pardon.  To clarify.  The VLB file that seems "repaired" is attachment 166115 [details].
It now works here (chart updates) on fully installed Linux LibreOffice versions.
Requesting test on a Windows system and other Linux versions.

For VLB. For Lars. If you have a new current project with "broken" charts using a more recent version of Calc I offer to attempt to repair them for you.  Just send them to me by email or any google drive you can give access.  This computer handles files up to 102MB without difficulty (about 9GB in RAM).  Well, just an offer if it helps you out.
Comment 64 VLB 2020-10-06 17:21:57 UTC
> Would ladies, gentlemen please test the "seems repaired" VLB sample on
> Windows and report result?  Attached with this message.  Method is at
> comment 28.
> 

I have test attachment 166115 [details] in wi10 LO  7.0.1.1 (x64).

All graphs work, except for the graph on the 1st sheet "invoer". This chart will not be updated.

I have download the file AppImage. I also tried to use the file in Ubuntu, but my knowledge in Ubuntu is limited.
How do I make the file executable?
Comment 65 matthewnote 2020-10-06 18:18:42 UTC
(In reply to VLB from comment #64)
> > Would ladies, gentlemen please test the "seems repaired" VLB sample on
> > Windows and report result?  Attached with this message.  Method is at
> > comment 28.
> > 
> 
> I have test attachment 166115 [details] in wi10 LO  7.0.1.1 (x64).
> 
> All graphs work, except for the graph on the 1st sheet "invoer". This chart
> will not be updated.
> 
> I have download the file AppImage. I also tried to use the file in Ubuntu,
> but my knowledge in Ubuntu is limited.
> How do I make the file executable?

With Ubuntu here, mouse- cursor over the file symbol or name.  Click mouse (right button), "Properties" "permissions".  At lowest box of the dialogue "Make file executable".  Close dialogue box.  Doubleclick the file.  Works for you?

With all the project here, there's a user impression that all or any LibreOffice full install may start correctly then later charts stop updating (sometimes whole sheets of charts).  Thank you for your test 7.0.1.1 ( an installed version).  

I will be using only AppImage for a few days or weeks with several files to learn if it's more "stable", temporary fix or a permanent repair (only for continuous AppImage use in future).

For a few more days now I'm working through the .xml  (including content.xml) files of your LiggerV26 to find if there's an obvious difference.  I've found some differences already.  For a developer who looks at this, VLB's file has the chart (not updating) Object number 15.  AppImage keeps the same object numbers; cleans up (removes) some ObjectReplacements; sets additional loext values in content.xml etcetera.  I'll report later if something seems pertinent about that.
Comment 66 matthewnote 2020-10-07 06:30:39 UTC
(In reply to VLB from comment #64)
> 
> I have test attachment 166115 [details] in wi10 LO  7.0.1.1 (x64).
> 
> All graphs work, except for the graph on the 1st sheet "invoer". This chart
> will not be updated.

Good morning.  Checking again here, all charts function with AppImage.  With 7.0.1.1 on Windows, which of the four charts is the only one to fail to update on "invoer"?  The chart covering cell A58, M58, M66 or M74?
Comment 67 VLB 2020-10-07 06:53:07 UTC
(In reply to matthewnote from comment #66)
> (In reply to VLB from comment #64)
> > 
> > I have test attachment 166115 [details] in wi10 LO  7.0.1.1 (x64).
> > 
> > All graphs work, except for the graph on the 1st sheet "invoer". This chart
> > will not be updated.
> 
> Good morning.  Checking again here, all charts function with AppImage.  With
> 7.0.1.1 on Windows, which of the four charts is the only one to fail to
> update on "invoer"?  The chart covering cell A58, M58, M66 or M74?

The test was in LO 7.0.1.2 (x64) and not 7.0.1.1

I tested again this morning and amazingly all graphs are now being updated (including the graphs on the 1st sheet).
Yesterday it was all 4 graphs on the 1st page that were not updated.
Comment 68 matthewnote 2020-10-07 10:31:39 UTC
Thankyou VLB

For developers.

Overall impression.

1.  Any installed/integrated version of LibreOffice Calc on Windows or Linux can cause Charts to fail to update, begin again to update, then it's a different chart that fails, then it is many.  The situation changes with every load/save or edit/save.  VLB's attachment is rare because the fault stays the same. (This was tested also on Xenial Puppy Linux using either Apache or LibreOffice:  same problem).

2.  An appropriate AppImage executable (that matches the original file that stimulates errors in the installed verions) will immediately work with all charts updating on all sheets.  This is the effect I have tested here on Ubuntu 20.04
, Ubuntu 18.04.  It also works/charts update using a Xenial Puppy Linux LibreOffice 6 .sfs standalone.  The User can make progress with his/her project.

3.  Saving a file using AppImage can repair it.  That saved file can work immediately in installed LibreOffice versions on Linux or Windows (or maybe not).  It takes a lot more testing to learn if that will break it again later.

4.  AppImage treatment can
   a.  delete some ObjectReplacement files (about half disappear, if any).
   b.  insert new lines into Object\ content.xml, such as
       loext:min-decimal-places="0"
       loext:try-staggering-first="true"
       oext:try-staggering-first="false"
       

Please guide me what work to do about .xml compare that might help you.  I use https://prettydiff.com.
Comment 69 matthewnote 2020-10-08 10:46:30 UTC
*** Bug 136254 has been marked as a duplicate of this bug. ***
Comment 70 Lars Jødal 2020-10-08 13:45:52 UTC
(In reply to Matthew Francis from comment #28)
> OK, so I see what I did wrong before. The already fixed bug I mentioned in
> comment 20 was for the chart in the "invoer" sheet, which works in 4.4
> already
> 
> The issue I now see was meant is for the "roX0_9" chart, and is reproduced
> as follows:
> 1. Open attachment 114246 [details]
> 2. Go to sheet "roX0_9"
> 3. Go to sheet "invoer"
> 4. Delete H19:L19
> 5. Go back to sheet "rox0_9"
> 
> The diagram at A52:57 has not updated, but shows the updated values when
> edited.
> Note that the bug does not reproduce if step 2 is skipped.

Just tested with LO 7.0.2.2 on Win10. (Macros disabled.) The bug is still present: 
After deletion of the cells in step 4, the chart in sheet "roX0_9" us unchanged. Double-clicking on the chart makes the change come through (less points in the plot, lines reflecting the points that are now present). When the chart misses focus, e.g. clicking outside the chart, it reverts back.

User profile reset: Yes, just before the test.

OpenGL: Bug is present both with and without OpenGL.

Conclusion: The bug is still present in LO 7.0.2.2, it is still expressed on Windows (not only Linux), and the above example is file of reasonable size (2.4 MB) and easy-to-reproduce instructions.

Further considerations:
Comment #19 indicates a commit that introduced at least some variant of the bug, although comment #20 indicates that a later commit appeared to fix the bug. Given that we still struggle with these problems, perhaps the commit solved part of the problem. Definitely, the problems is not fully gone, as demonstrated by a number of comments, this one included.

Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: threaded
Comment 71 SRS 2020-10-08 15:21:20 UTC
I was able to reproduce as described in comment 70.  I've repeated the description below and inserted some notes as to exactly what I did:
1. Open attachment 114246 [details]
{note -- I just clicked on the attachment number and downloaded the file}
{note -- when I saw the pop-up about macros being enabled, I disabled them.}
> 2. Go to sheet "roX0_9"
> 3. Go to sheet "invoer"
> 4. Delete H19:L19
{note -- here I got an error because I was in read-only mode, so I went into edit mode.}
> 5. Go back to sheet "rox0_9"
{At this point, I saw the bug in all its glory, as described in comment 70.}

Here's all the information that might be relevant about my environment:
Hardware: Dell Inspiron 620 with 8GB memory, 64-bit
OS: Win7 home premium, SP 1
LibreOffice information:
Version: 7.0.1.2 (x64)
Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 72 SRS 2020-10-08 15:35:01 UTC
I have just reproduced the bug a second time as described in my previous comment #71.
I have another computer with Ubuntu installed.  If I have time, I will try to reproduce it there.
Comment 73 matthewnote 2020-10-08 15:52:00 UTC
*** Bug 136160 has been marked as a duplicate of this bug. ***
Comment 74 SRS 2020-10-08 16:57:46 UTC
Was able to duplicate it a third time under Lubuntu (Ubuntu with a different desktop, whose name I forget).
It is on an Ultrabook with a Core i3 processor
Ubuntu is 20.04
Comment 75 VLB 2020-10-10 13:04:28 UTC
Here is a small update, thanks to the efforts of Matthew!

I had my 3 private sheets saved by Matthew in Appimage and tested them in LO 7.0.1.2 and worked well, with all graphs processed properly.

Then I opened several files (which had been processed with Appimage and then I came to an important signal that the graphs were no longer processed properly.

An important thing had emerged which may have to do with memory and that the graphs are therefore no longer displayed properly.
It would be greatly appreciated if this new finding clarifies the problem definition and if a solution can be sought.
Comment 76 VLB 2020-10-12 17:22:37 UTC
The issue may have been brought closer to a solution in comment 75 by the observations. If more information is needed for the solution, we will gladly inform you.

There is also an additional observation and is the following:
1) Save the files with graphics in a * .xlsx file.
2) In this file type the graphs are displayed correctly after data is changed, compared to * .ods file.
3) The disadvantage of this is that the files are 3 times as large.
4) Certain sheets are not yet properly converted to * .xslx, so it cannot be used for all sheets.
Comment 77 matthewnote 2020-10-12 17:56:51 UTC
(In reply to Buovjaga from comment #49)
> (In reply to Matthew Francis from comment #28)
> > OK, so I see what I did wrong before. The already fixed bug I mentioned in
> > comment 20 was for the chart in the "invoer" sheet, which works in 4.4
> > already
> > 
> > The issue I now see was meant is for the "roX0_9" chart, and is reproduced
> > as follows:
> > 1. Open attachment 114246 [details]
> > 2. Go to sheet "roX0_9"
> > 3. Go to sheet "invoer"
> > 4. Delete H19:L19
> > 5. Go back to sheet "rox0_9"
> > 
> > The diagram at A52:57 has not updated, but shows the updated values when
> > edited.
> > Note that the bug does not reproduce if step 2 is skipped.
> 
> I still reproduce this problem.
> 
> Arch Linux 64-bit
> Version: 7.1.0.0.alpha0+
> Build ID: f08ddf3d3df0ef12fef36e96ffe6f5b9a7fda9e3
> CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 21 September 2020

USER WORKAROUND - QUIT ODF FORMAT - WORK IN XLSX UNTIL BUG FIXED
Please add your vast experience, overview and opinion for Users.

We (LibreOffice and Apache communities) have a fundamental problem.
Education is precisely where LibreOffice can be the best:  yet students (including Lars, up to PhD level) need to show a graph that shows the data.

I can (am able) to learn Python, having learnt Machine Code (bit manipulation), Assembler (extreme efficiency), Fortran 4 (precise compiler), Coral 66, SciLabs 2012 (Equivalent MatLab) yet my experience is with Realtime processing (Raytheon) and no time at all for a new adventure with ODF.  Yet I am investigating six files here with differences in .xml.

The workaround suggested below is completely ignorant of the multiple limitations of working with LibreOffice in xlsx format - yet it seems to work.

USER POTENTIAL WORKAROUND while waiting for Bug Fix with more symptoms for developer info (Step 7-12).

Charts not updating can be made to update by
1.   Click and Drag the chart area a few pixels.
If there are many charts depending on one Series update, User must check all charts on all sheets.

Charts not updating sometimes can be made to update by
2.   File>Save Restart LibreOffice File>Recent Documents>Open
This rarely works, can take a lot of time and every number change requires reload.
3.   Zoom in/zoom out the sheet view has be known to cause chart update (but very rare).
4.   Using AppImage 5.3.6.1 is tested to open faulty files and show charts updating immediately.  However, it’s usual that the new *.ods file will fail to update later after more edits.   AppImage 5.3.6.1 as a regular rescue tool every hour or every day is only available for Linux.   The new *.ods file can be shared.  Yet opening several files (rescued with AppImage) at the same time will cause different chart failures.  A method is needed for Windows OS.

NEW FINDING.  Charts not updating will always be made to update by saving in xlsx format.

5.   The User has a new decision to make.   Using LibreOffice every day in xlsx format depends on Charts with Data Series formats that transfer well (triangles, squares, diamonds), simple colours.  The User learns to avoid Functions that are special to LibreOffice yet impossible to translate for Excel.  This is difficult (for advanced users).   This method is described below for Users to test (a clue for developers also).

6.   Users don’t know if this Bug Report will ever be assigned.  If you are a Student, Teacher or using the spreadsheet to mostly calculate (with simple graphics) it can be an option to change format now. If the Bug receives attention in future, then it will be possible to save again in ODF format and elaborate/clean the cell functions from that new LO version.    Of course, for engineers, scientists, students and teachers it is basic that the plot shows the same numbers as the cell.  The Bug causes much doubt, mistrust and stress.  An occasional review of the xlsx file progress is, perhaps, less painful.

Testing the file suitability with this method.
7.  IF the spreadsheet file is mostly technical or mathematical, this Workaround may be suitable.  If the spreadsheet has scatter charts with the series formatted in special colours and symbols for presentation, it will need some work or can be done later (after BugFix) with ODF advantages.  If the file uses Indirect Adressing or Functions the new file need be checked thoroughly.

8.  The Workaround (for a file with ordinary charts) is to change to Excel 2007-365 XLSX format until the ODF Bug is fixed.

9.  When the charts fail to update or when testing to do it deliberately,
File>Save As> (bottom right filetype) select xlsx Excel 2007-365.  
A new name is useful like "abcde XLSX.xlsx" to make it obvious when using a File Manager.  LibreOffice will ask are you sure? A warning will appear that some details or calculations may be lost.  User can check that later.

10.   Click to confirm save Excel xlsx 2007-365.
The charts on the sheet being viewed at this time will all update correctly while you watch.  Magic!

Note: At the top of the LibreOffice calc (the black title bar) the file name has changed to abcde.xlsx.  (LibreOffice is still running in it's own display system and other graphics may fail to update).  LibreOffice is showing you a display equivalent of the xlsx, not yet the true xlsx effect.

11.   Save/Close all other .ods files.  Close LibreOffice.    Restart LibreOffice.

12.  File>Open only the xlsx file.   All Charts are now updating.
This conversion/rescue can be done for more *.ods files.  Restart LibreOffice for each file (only one conversion at a time).  

Note: It is also now possible to start LibreOffice and open all the new xlsx files at the same time.  All Charts update everywhere on all sheets of all files (according to the tests done on two computers here.  Please comment if you find problems in future).

13.   Inspect the new xlsx presentation for symbol, colour changes, Indirect Address failures (if the ods file uses it), Chart scales etc.   Minor differences are that xlsx shows # for calculations that cannot be completed (source data off or inhibited) where the ODF (*.ods) showed #VALUE!

14.   It is possible to continue the project for the User always in Excel format.  LibreOffice does this very well!   When the Bug is fixed, then Save as>abcde.ods> (confirm) ODF version is new choice.

15.   Unfortunately, editing the files in future will cause new Chart failures (cause unknown, not yet identified).  This Bug 86321 is still possible when editing.  However, save/reopen in xlsx seems always to work and is quick (on Windows also).  Please test for yourself.

DISADVANTAGES.   
16.   When the User inspects the new xlsx charts, some lines are changed from dashed to continuous.  If the user changes those line again, the Chart will fail to update.  File>Save  File>Open xlsx needed again.

17.  If the User has created the ODF project with many different formats for scatter plot Data Series, those colours and symbols are changed to simple blue squares.

18.  The xlsx file can be nearly twice the size in MBytes.    For example 9.9 MB in ODF became 21 MB in xlsx.  Yet a different very large file (101.7MB) was precisely the same size ODF/xlsx.

LIMITATIONS OF THE USER WROKAROUND  
19.   Users estimate that an xlsx file can be shared with colleagues using Excel.   It is necessary, before sending a file to check how it presents on a working Windows/Office system.  It will be very different again!  The workaround concerns using xlsx format to develope the user project until this Bug is Fixed.

20.  attachment  114246 [details]  is an example of a file that is suitable for xlsx conversion and development.  attachment  165696 [details] is an example of a file that is unsuitable (due to extensive use of LibreOffice tools that are excellent yet not translated into xlsx formats).

[Example:  With my  four year project, it is too late to work every day now in xlsx format (even if LibreOffice does it very well).  My designs were all based on analysis by x,y scatter and ODF functions].

Summary
21.   File save/close/open again sometimes works with *.ods.  Mostly it does not solve the problem.

Testing here  save/open of *.xlsx always repairs chart update.!  This is the unique advantage.

Workaround tested on:

Version: 7.0.1.2
Build ID: 00(Build:2)
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Ubuntu package version: 1:7.0.1-0ubuntu1_oibaf~f
Calc: threaded

Version: 7.1.0.0.alpha0+
Build ID: 8eff280bc08ec3d7b2312ae4ee48df4d7328b7de
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-07_08:11:21
Calc: threaded

Version: 6.3.5.2
Build ID: 1:6.3.5~rc2-0ubuntu0.18.04.1~lo1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Versie: 6.4.6.2 (Dutch language)
Build ID: 1:6.4.6-0ubuntu0.20.04.1
CPU-threads: 2; Besturingssysteem: Linux 5.4; UI-render: standaard; VCL: 
gtk3;
Locale: nl-NL (nl_NL.UTF-8); UI-taal: nl-NL
Calc: threaded

Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 16; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; 
VCL: win
Locale: nl-NL (nl_NL); GI: nl-NL
Calc: threaded

WORKAROUND FAILURE 
The last Chart on VLB's attachment last sheet in xlsx format - the data triangles disappear - only the line is seen).  Full details Xenial Puppy Linux with LibreOffice 6.1.0.3 in *sfs executable form.
Version: 6.1.0.3
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded

This failure may be most pertinent for SFS reading this comment.
Experience with Lubuntu (KDE) here is that there are multiple crashes running LibreOffice which are resolved since Ubuntu moved to Gnome.  A Lubuntu PC here was crashing ten times per day (set LibreOffice autorecovery on!).  When wiped and replaced with full Ubuntu Bionic Beaver 18.04 - several months with no crashes at all. In fact, I now switch off LibreOffice autorecovery when I use 6.3.5.2 or 7.0.1.2.  The Linux is rock solid.
Comment 78 matthewnote 2020-10-20 15:20:39 UTC
Created attachment 166553 [details]
Screenshot; Comparing unzipped odf content.xml between AppImage5 and LO4

More about the Bug - using QXmlEdit to compare the ODF content.xml after saves.

Calc 4.  The screenshot (right hand side in red) shows that the Calc 4 used to save attachment 109539 [details] writes content.xml using draw:object
<table:table-row><table:table-cell><draw:frame><draw:object> Attributes:
draw:notify-on-update-of-ranges=roX09 . . . . . .

Calc 5.1.6.2 all versions up to 5.4.7 changes the strategy.   The screenshot (left hand side in green) shows that Calc 5 opens the version 4 file, reads that Object 17, updates the Chart correctly when data series cell values change.  Saving the file, Calc 5 deletes the original Attribute (gone), then adds a completely new element in content.xml one level up at draw:frame
<table:table-row><table:table-cell><draw:frame><loext:p> Attributes:
draw:notify-on-update-of-ranges=roX09 . . . . . .

[Note: Calc 5 then adds another completely new attribute into Object 17/content.xml
<style:style><style:chart:properties>Attributes:
loext:try-staggering-first="true" ]

Calc 6 and 7.  These versions remove the Calc 5 strategy and go back to the same xml organisation as for version 4.   This is deliberate or a regression?

Further evidence.
Calc 5 is therefore very useful for repairing a file or User work.  Every time the file is saved and reopened, it's repaired.  However, Calc 5 still has this Bug.   Example of the User dilemma when creating a project:  

Step 1.  Open attachment 109539 [details] using Calc 5.  Click to view sheet roX0_9
Step 2.  Click to view sheet invoer
Step 3.  Delete cell contents of invoer H19:L19.  
Result, all charts update on all sheets (including roX0_9)

Step 4.  Leftclick to view sheet vb_610a
Step 5.  Rightclick "Insert Sheet", "After current sheet" "Name" any.  OK
Step 6.  View again invoer and replace H19:L19 (values 5 4 3 3 3)
Result, charts on invoer are showing triangle points with eight x-axis values, some are three values.  Three Charts are showing both old and new values (both eight points and three points are superposed).

Step 7.  View again vb_610a.  Result, none of the charts on that sheet update.
Step 8.  On vb_610a click and drag a chart Area a few pixels.  Chart updates.
Step 9.  View sheet vb_610b, charts are correct.
Step 10. View sheet eg, charts are correct, however the top chart frame is squashed, causing the triangle symbols to be short.
Step 11. Click and drag top chart area and move it a few pixels.  Draw is good.
Step 12. View sheet loX0_9, charts are already updated correctly.
Step 13. View sheet roX0_9, charts are not updated.  Clickdrag chart areas.
Result, charts now update.

Step 14. File>Save then File>Close then File>Open
Result, all charts on all sheets are updated (in correct draw state).
Step 15. Change any value of the Data Series for any chart
Result, all charts on all sheets update correctly.

LibreOffice Calc 4,5,6,7 all seem to have this Bug.
Only Calc 5 will save the User work and reopen it with all Charts working.
However, using Calc 5 to edit or add sheets causes new failures to update and those frozen Charts can be anywhere on any sheet.

I've tested with seven LibreOffice versions and the adoption of the LO4 save content.xml structure came back with precisely LO 6.0.0.  Therefore, File>Save File>Close then File>Open repair is no longer available for users who have upgraded.  I've seen LO6.3.5.2 refresh a sheet once, but usually the charts on other sheets are failing to update.

I hope the xml compare information is useful.  Not sure if I can do more about this.  For my project, I may remove Calc 6.3.5.2 and install 5.4.7.  It's risky because I see a lot of bugs have been fixed, including problems with Indirect Addressing (that my work uses as a basis for it's design).  Well, I'll contribute more if I can figure out how the summary in RAM of the sheet/chart situation is corrupted.

Just a reminder:  Once and only once, upgrading from Calc 6.3.5.2 to Calc 7 and opening the "worst" file first;  it repaired all Charts and generated Object Replacements for all and the file is still working.  Removing Calc 7 and reinstalling 6.3.5.2 then doing the upgrade process again did not repair any file.  The second "installation 7.0" skipped some procedures of dependencies in Ubuntu 18.04, finding them already new, but I don't have a record of precisely which ones.  It will be difficult to examine that particular ODF file because it is 102MB compressed already.  Not many xml editors or compare tools can cope with the unzipped content.
Comment 79 matthewnote 2020-10-20 15:52:28 UTC
Created attachment 166554 [details]
Compare LO5 modification of Object/content.xml since removed; regression?

Additional xml compare report for Object/content.xml as described previous comment.  LibreOffice Calc 5 adds a new line for each and every Object
"try-staggering-first".
Comment 80 matthewnote 2020-10-25 07:30:57 UTC
To clarify.  There are two bugs implied.

First Bug.  During work on a project, Calc versions 4,5,6,7 use a "register" (of some sort) that follows the situation of which Objects are on which Sheet.  That has redraw functions (of which three are changes in Object position, changes in scales used and changes in Data Series).  The start situation is loaded from /Object*/content.xml and the main ODF content.xml.  When the user inserts a new sheet or copies an existing sheet, the "register" becomes out of date or scrambled/corrupted).  When the user views other sheets, various chart Objects respond to position redraw criteria but not the scale nor Data Series. Some charts show x-axis now stretched to accomodate two different sets of Data Series superposed although apparently only one y-axis series is plotted.  The x-axis stretch is very variable and implies the redraw is attempting to mix data that is actually for a different Object on a different Sheet.  [Note: the chart Data Series readout for the user is unchanged, the original intended].

If the user copies a chart (makes a twin), the "register" functions, puts the new Object into memory appropriately and that twin does update. 

Second Bug.  When the user saves the file, Calc 4,6,7 save a faulty "register".  On re-opening the file any or many charts fail to update (not always true and not always the same charts).

Saving with all Calc versions 5.*.*.* does something more thorough before writing.  The register is "revised" or "cleaned up" in some way before writing.  Some charts visible to the user are still frozen yet closing/re-opening the file finds the new content.xml and object/content.xml compatible, correct and all charts working.  With further Calc 5 user activity, the first Bug will, again, cause new freezes of charts.

Saving with format .xlsx causes a similar "revise" or "clean up" as Calc 5 with an additional final "redraw" of objects that had changes during the user session.  Therefore, unlike Calc 5, the user sees the presentations jump to the correct data values.

First and second Bug together.  If the user opens two or three .ods at the same time and does edits, the "register"  (apparently, it seems) becomes corrupted across any or many sheets on any of the open files.  Then it's necessary to File_Save with Calc 5 (then reopen each) or File_Save as .xlsx for all open files.
Comment 81 Buovjaga 2020-10-25 09:36:13 UTC
(In reply to matthewnote from comment #80)
> To clarify.  There are two bugs implied.

Then it would be nice to create a separate report for the other bug, especially in this case where we have reached 80 comments on this original one.
Comment 82 VLB 2020-10-25 15:06:17 UTC
> Second Bug.  When the user saves the file, Calc 4,6,7 save a faulty
> "register".  On re-opening the file any or many charts fail to update (not
> always true and not always the same charts).
See new report bug 137735.
Comment 83 Lars Jødal 2020-10-29 14:13:59 UTC
(In reply to matthewnote from comment #79)
> Created attachment 166554 [details]
> Compare LO5 modification of Object/content.xml since removed; regression?
> 
> Additional xml compare report for Object/content.xml as described previous
> comment.  LibreOffice Calc 5 adds a new line for each and every Object
> "try-staggering-first".

So LO 5.x worked ok, which could mean that the original bug was solved but then some new bug caused a regression with the same or similar behaviour. Likely some optimization of diagram updating that "optimized" recalculation too much.

I have performed the test from comment #28 with a few 5.x versions, and can confirm that diagram update DOES work for that file. The regression is present by 6.0.0.0.beta1, while 6.0.0.0.alpha1 does update the diagram.

First question: Does the test from comment #28 test for "First bug" from comment #80, or for "Second bug" (now split out as bug 137735)?

Second question: What will constitute a simple test example for the other bug (whether "first" or "second") not tested for by the procedure in comment #28?

(This thread is becoming quite scary just by its size. While details can reveal new findings, I think that at the present stage we are more in need of simple test cases with simple descriptions.)
Comment 84 VLB 2020-10-29 14:36:20 UTC
> First question: Does the test from comment #28 test for "First bug" from
> comment #80, or for "Second bug" (now split out as bug 137735)?
This test comment #28 is for the 2nd bug 137735. 


> Second question: What will constitute a simple test example for the other
> bug (whether "first" or "second") not tested for by the procedure in comment
> #28?
If the 2e bug 137735 is solved, the problem is that when opening multiple sheets with multiple graphs, randomly determined graphs no longer work. This is bug 86321.
The thought is that this is due to caching or something similar.
Comment 85 VLB 2020-10-29 15:06:28 UTC
> (This thread is becoming quite scary just by its size. While details can
> reveal new findings, I think that at the present stage we are more in need
> of simple test cases with simple descriptions.)

For this bug 86321 it can be reproduced with the following steps:

1) Installeer LO 5.4.7
2) Open attachment 114246 [details]
3) Save the file in other/different name 5 sheets or more
4) Open all files
5) Delete cell H19:L19 in all files and save all files
6) Enter the following value in all cell ïnvoer" H19:L19 in all files/sheets, number "8"
7) Look at the different graphs on the following sheets "invoer A52:P57" + "vb_610a A52:p57" + "vb_610b A52:p57" + "eg A52:p57" + "loX0_9 A52:p57" + "rox0_9 A52:p57"
8) Not all graphs have been updated.
Comment 86 matthewnote 2020-10-29 15:41:26 UTC
(In reply to Lars Jødal from comment #83)
> (In reply to matthewnote from comment #79)

> This thread is becoming quite scary just by its size. While details can
> reveal new findings, I think that at the present stage we are more in need
> of simple test cases with simple descriptions.)

Bug 137735 proposes the precise method at comment 78 so that readers know how to corrupt the loading of any file, even if it works once before and how to restore the file.

The Bug also details all results for all calc 5 versions.  It also gives a user workaround in Windows versions.  Calc 5.4.7.2 still has this bug here  (due to many types of edits) but Save-Close-Open restores it every time.

I try to brief.  Testing or (we hope) beta testing a bugfix can be done by e-mail - no need to post here.  However, until someone skilled volunteers to assign it to themselves  (with a contact address) I think the only option is to place all the facts to encourage him or her to start/attempt.
Comment 87 VLB 2020-10-29 15:55:38 UTC
bug 86321 does update by LO 4.2.8.2, but no longer with LO 4.3.0.1.
Comment 88 Blair Mault 2021-02-12 11:46:15 UTC
(In reply to Joel Madero from comment #15)
> This is not a critical bug - I'm not sure who marked it as such.
> 
> Marking as:
> Minor - there is a workaround (see last comment). It can slow down
> professional quality work but will not prevent it. Critical is reserved for
> major crashes and serious data loss - this is neither.
> 
> I'll leave as highest and leave it on MAB list.
> 
> Please do not revert my changes. 
> 
> 
> What would be nice is for those seeing this issue to test older releases to
> see if it's a regression.
> http://downloadarchive.documentfoundation.org/libreoffice/old/
> https://bestfreehdporn.pro/category/anal-porn-paysites/
> 
> Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a
> regression (please leave a comment). If it isn't present in 3.3, then start
> testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where
> the bug came in.

fixed?
Comment 89 snowboard975 2021-04-05 12:40:31 UTC
I can reproduce the bug on Libreoffice of below version.

Version: 7.0.5.2 (x64)
Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

 
(In reply to Blair Mault from comment #88)
> (In reply to Joel Madero from comment #15)
> > This is not a critical bug - I'm not sure who marked it as such.
> > 
> > Marking as:
> > Minor - there is a workaround (see last comment). It can slow down
> > professional quality work but will not prevent it. Critical is reserved for
> > major crashes and serious data loss - this is neither.
> > 
> > I'll leave as highest and leave it on MAB list.
> > 
> > Please do not revert my changes. 
> > 
> > 
> > What would be nice is for those seeing this issue to test older releases to
> > see if it's a regression.
> > http://downloadarchive.documentfoundation.org/libreoffice/old/
> > https://bestfreehdporn.pro/category/anal-porn-paysites/
> > 
> > Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a
> > regression (please leave a comment). If it isn't present in 3.3, then start
> > testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where
> > the bug came in.
> 
> fixed?
Comment 90 Xisco Faulí 2021-04-07 07:05:26 UTC
*** Bug 141455 has been marked as a duplicate of this bug. ***
Comment 91 Dimitris Kallipolitis 2021-04-19 08:29:26 UTC
I have found a solution to this problem:
Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine (OLE_Objects) to e.g. 40 (default value 20). This value should be greater than your maximum number of charts in any spreadsheet that you use. A lower value causes some charts not to be updated when spreadsheet data is updated. It's a cache issue.

Verified with:
Version: 7.1.2.2 / LibreOffice Community
Build ID: 10(Build:2)
OS: Linux 5.8; UI render: default; VCL: gtk3
Ubuntu package version: 1:7.1.2~rc2-0ubuntu0.20.04.1~lo3
Calc: threaded
Comment 92 Lars Jødal 2021-04-19 14:24:26 UTC
(In reply to Dimitris Kallipolitis from comment #91)
> I have found a solution to this problem:
> Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search
> for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine
> (OLE_Objects) to e.g. 40 (default value 20). This value should be greater
> than your maximum number of charts in any spreadsheet that you use. A lower
> value causes some charts not to be updated when spreadsheet data is updated.
> It's a cache issue.

Sounds like information that may be very helpful:
a) As a way to circumvent the issue for the individual aware that this bug exists.
b) For narrowing down the bug in the code.

It does not stop this from being a bug of importance (IMHO), and I am among those who still hope it will be fixed one day and who will be thankful when it happens.
Comment 93 VLB 2021-04-19 17:21:36 UTC
(In reply to Dimitris Kallipolitis from comment #91)
> I have found a solution to this problem:
> Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search
> for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine
> (OLE_Objects) to e.g. 40 (default value 20). This value should be greater
> than your maximum number of charts in any spreadsheet that you use. A lower
> value causes some charts not to be updated when spreadsheet data is updated.
> It's a cache issue.
> 
> Verified with:
> Version: 7.1.2.2 / LibreOffice Community
> Build ID: 10(Build:2)
> OS: Linux 5.8; UI render: default; VCL: gtk3
> Ubuntu package version: 1:7.1.2~rc2-0ubuntu0.20.04.1~lo3
> Calc: threaded

Thanks for the feedback on the issue!

I have adjusted the value as indicated to a value of 90 (in connection with a sheet with 88 graphs) and tested it. I can conclude that this solves the problem for 1 sheet. Only I also have more of these shets open with miscellaneous adjustments (so maybe more than 4 * 88 graphs) and then notice that they are no longer updated. Can this value be increased indefinitely, without causing problems elsewhere?
It would also be great if this problem could be solved in the source code, as already indicated in comment 92.

Version: 7.1.2.2 (x64) / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: CL
Comment 94 Xisco Faulí 2021-04-19 19:16:18 UTC
I've just bisected this again.
Regression introduced by

author	Armin Le Grand <alg@apache.org>	2014-02-18 21:18:13 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2014-02-19 20:29:12 +0000
commit db1d2af02861b49e4f53d726d59cd71c20cee9b1 (patch)
tree a4edfc1235314f5e3d03c45a52863a052ad19286
parent 2237604b6b1d08439ac37f096a787c449a046b5f (diff)
Resolves: #i123539# some optimizations for 3D chart...

Bisected with: bibisect-43max

I might have a solution for this...
Comment 95 Commit Notification 2021-04-20 07:32:08 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b

tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 96 Xisco Faulí 2021-04-20 07:34:03 UTC
Hi,
My patch in comment 95 fixes the steps in comment 28. For other issues, please, fill a new report. Closing as RESOLVED FIXED
Comment 97 Xisco Faulí 2021-04-20 07:42:49 UTC
The issue is easily reproduced with attachment 111198 [details] from bug 87622. My patch also fixed the problem in that file
Comment 98 VLB 2021-04-20 07:47:47 UTC
(In reply to Commit Notification from comment #95)
> Xisco Fauli committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b
> 
> tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."
> 
> It will be available in 7.2.0.
> 
> The patch should be included in the daily builds available at
> https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> https://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

Thank you very much for resolving the issue!
Is it possible that it will also be pushed to LO version 7.1.3?
Comment 99 Xisco Faulí 2021-04-20 07:57:49 UTC
(In reply to VLB from comment #98)
> (In reply to Commit Notification from comment #95)
> > Xisco Fauli committed a patch related to this issue.
> > It has been pushed to "master":
> > 
> > https://git.libreoffice.org/core/commit/
> > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b
> > 
> > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."
> > 
> > It will be available in 7.2.0.
> > 
> > The patch should be included in the daily builds available at
> > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> > information about daily builds can be found at:
> > https://wiki.documentfoundation.org/Testing_Daily_Builds
> > 
> > Affected users are encouraged to test the fix and report feedback.
> 
> Thank you very much for resolving the issue!
> Is it possible that it will also be pushed to LO version 7.1.3?

yep, https://gerrit.libreoffice.org/c/core/+/114277
Comment 100 Commit Notification 2021-04-20 08:55:58 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/3fe117cb0f319fbb84073d75ad5e2d676b587866

tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."

It will be available in 7.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 101 Commit Notification 2021-04-21 09:07:13 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/99679f4dbfae6eb51a9a76b1cebd87e3d38b0c9c

tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."

It will be available in 7.0.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 102 VLB 2021-04-21 12:07:48 UTC
(In reply to Xisco Faulí from comment #99)
> (In reply to VLB from comment #98)
> > (In reply to Commit Notification from comment #95)
> > > Xisco Fauli committed a patch related to this issue.
> > > It has been pushed to "master":
> > > 
> > > https://git.libreoffice.org/core/commit/
> > > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b
> > > 
> > > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."
> > > 
> > > It will be available in 7.2.0.
> > > 
> > > The patch should be included in the daily builds available at
> > > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> > > information about daily builds can be found at:
> > > https://wiki.documentfoundation.org/Testing_Daily_Builds
> > > 
> > > Affected users are encouraged to test the fix and report feedback.
> > 
> > Thank you very much for resolving the issue!
> > Is it possible that it will also be pushed to LO version 7.1.3?
> 
> yep, https://gerrit.libreoffice.org/c/core/+/114277

(In reply to Commit Notification from comment #95)
> Xisco Fauli committed a patch related to this issue.
> It has been pushed to "master":
> 
> https://git.libreoffice.org/core/commit/
> eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b
> 
> tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."
> 
> It will be available in 7.2.0.
> 
> The patch should be included in the daily builds available at
> https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> https://wiki.documentfoundation.org/Testing_Daily_Builds
> 
> Affected users are encouraged to test the fix and report feedback.

I have test in 7.2.0 and it fix for 1 sheet with 88 graphs! Thanks.
I created a new issue when opening multiple sheets at the same time, see issue 141799
Here F9 must be used to update the graphs.
Comment 103 Xisco Faulí 2021-04-21 13:21:48 UTC
HI VLB,
thanks for checking. Let's close it as VERIFIED
Comment 104 Lars Jødal 2021-04-21 13:40:32 UTC
Thanks for patching this long-standing issue. I have also tested with 7.2.0, and now sets status to "VERIFIED FIXED".
Comment 105 VLB 2021-04-22 07:23:02 UTC
(In reply to Xisco Faulí from comment #96)
> Hi,
> My patch in comment 95 fixes the steps in comment 28. For other issues,
> please, fill a new report. Closing as RESOLVED FIXED

It is also possible to look at bug 141799 as it is very related to this fixed bug.
Comment 106 matthewnote 2021-04-25 07:11:43 UTC
Hi all.  Thankyou very much Dimitris and Xisco, all at QA and VLB for tenacity!
Tested another attachment file already here on this Bug Report.

1.  Opened attachment 165696 [details] using 7.1.4.0.0+ on Ubuntu 18.0.4.2
2.  Sheet "TheSWITCHexpanded" shows.   Test is done at L259 with chart at C283.
3.  Change L259 from value 17 to value 25.  Enter.
4.  Chart X293 clears all plots (correct). Chart C283 does not update (incorrect).
5.  Expected result; chart C283 plots move due to L259 value change.  

However using 7.1.4.0.0 on Ubuntu there are improvements and quick workarounds.
If a file behaves like that test file, Users reading here may try the following.

6.  The following actions all do cause Chart C283 to update once . . . .
    a.  Move cell selection using keyboard < v ^ > to any cell with text or data.
 or b.  Click on any cell with text or data. 
 or c.  Click on the Ubuntu desktop 
 or d.  Click on any other open application window.
 or e.  Click on a menu (example Tools, Automatic Spell Checking)
 or f.  Click on a row number or column letter (any row or column that has values)
 or g.  Scroll the sheet to push out the chart then scroll back into view.
but h.  Clicking any empty cell on the sheet. . . .Chart C283 does not update.   
and i.  The above methods cause the Chart at C283 to only update once.

7.  The following action causes C283 to update automatically (dynamically)
    a.  Double-click the Chart C283 area.  (Single click is insufficient)
    b.  Chart C283 is fully active for the User session (but not at next load).  
    c.  File>Save then >Open does not fully reactivate the chart (no repair).

Testing another very large research file (100MB opens to 6GB), not attached here.
It is a Diabetes research file saved but with no charts working at all.
8.  7.1.4.0.0 opens that very large file with all charts working :)

Testing Dimitris' Options> OLE parameter solution (I change default 20 to 500)
using the Ubuntu 18.04.2 LTS standard Calc bundle 7.0.4.2
9.  All files here (and the attachment on this thread) all charts all work.

I add this comment to help new visitors (USERS) with similar problems reading for the first time here.
The new commit is a huge improvement.  Abandoned or lost work can be resumed.
For comments about file backwards compatibility problems (like mine) Bug 137735
If you notice different workarounds (or using Windows) please see    Bug 141799

Personally, I can now upgrade all my work from the Calc 5.4.7.2 workaround to any Libreoffice 7 version (using Dimitris' parameter change - 20 to 500 works so far)
and ask my collaborators to do the same on their PC.                 Comment 91
Comment 107 matthewnote 2021-04-25 07:19:58 UTC
Excuse me.  The Version below used is (I presume) including the commit.
PC used for testing for comment 106 is without OpenCL capability.
[For new readers wondering why OpenCL is off, when starting Calc, the application may blink a few times before showing;  it's testing if the Ubuntu+graphics chipset can work reliably with OpenCL.  If not, Calc continues without it].

Version: 7.1.4.0.0+ / LibreOffice Community
Build ID: 99ca6b660fd911e9e60b63ae286c588aedfb01d0
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-21_07:55:21
Calc: threaded

I've also tested much with Ubuntu 20.04 and the latest Dev/Calc 7.2.0.0 alpha;  remarks on Bug report 141799 (to compare with Windows effects which are different).
Comment 108 Commit Notification 2021-04-28 15:45:45 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-1-3":

https://git.libreoffice.org/core/commit/fdb0b1d3f94d3233d984f2f51ddd7e425e885acb

tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."

It will be available in 7.1.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 109 matthewnote 2021-04-29 14:39:15 UTC
Test results using attachment 165696 [details] all successful
Test results with 100MB file (opens to 6G across two 4K monitors) all successful

UBUNTU 18.04 LTS - Chart updates
Version: 7.1.4.0.0+ / LibreOffice Community
Build ID: e5b8477a1270a8b572b3815cfb318110eb19d0f2
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-28_11:37:37
Calc: threaded

UBUNTU 20.04 LTS - Chart updates
Version: 7.1.4.0.0+ / LibreOffice Community
Build ID: e5b8477a1270a8b572b3815cfb318110eb19d0f2
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-28_11:37:37
Calc: threaded

WINDOWS 10 PRO - Chart updates
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: f616d96bd8ce8986e4cc204953db0467e6060b5c
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Unexpected result - 7.1.3.1 was already on windows 10 PC 21/04/2021 so
I tested it without yet updating beyond this build ID (without further commit)
WINDOWS 10 PRO - Chart updates
Version: 7.1.3.1 (x64) / LibreOffice Community
Build ID: fa76d07d7006a0e2866c3247cef2d5eb55ae8369
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 110 matthewnote 2021-04-29 15:34:48 UTC
More test results using attachment 165696 [details] - Chart updates
Test results with 100MB file (opens to 6GB across two 4K monitors) all successful

UBUNTU 20.04.2 LTS Gnome 3.36.8
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 1325d8161a74a3cedc169952eca10f4343e700c4
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-04-28_00:26:19
Calc: threaded
Comment 111 Commit Notification 2021-05-06 13:54:55 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-7-0-6":

https://git.libreoffice.org/core/commit/aef624769c2d7f401fd94864ba9824345e926a71

tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..."

It will be available in 7.0.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 112 matthewnote 2021-05-09 08:54:29 UTC
Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from VLB)

Step 1.  Deleting values in H19:L19, 
         All the charts update - is the expected result
        (there are fewer valid x scatter coordinates)
Step 2.  Click back using toolbar Undo: Delete
         All the charts update - is the expected result
        (there are all the x valid scatter coordinates)

However, the trend lines on the charts are not restored to original state.
Saving the file (different name), then open, the trend lines are in error.

Step 3.  Modify value I19 from 4 to 8, the trend lines are redrawn.
Step 4.  Click back using toolbar Undo: Input
         All the charts update - is the expected result
         The trend lines are now again at the file original start shapes.

I see there's a macro in the file and I don't know enough about how the file works to comment further. So I'll investigate trend line behaviour with other files.  Summary:  with attachment 114246 [details] deleting values;  the trend lines do not follow.  Changing a value;  the trend lines do follow and Undo functions also. In all tests the x,y scatter plots remove and move (but I think only VLB can confirm it's precisely as expected).

Version: 7.0.6.2 (x64)
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 113 VLB 2021-05-09 10:16:21 UTC
(In reply to matthewnote from comment #112)
> Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from
> VLB)
> 
> Step 1.  Deleting values in H19:L19, 
>          All the charts update - is the expected result
>         (there are fewer valid x scatter coordinates)
> Step 2.  Click back using toolbar Undo: Delete
>          All the charts update - is the expected result
>         (there are all the x valid scatter coordinates)
> 
> However, the trend lines on the charts are not restored to original state.
> Saving the file (different name), then open, the trend lines are in error.
> 
> Step 3.  Modify value I19 from 4 to 8, the trend lines are redrawn.
> Step 4.  Click back using toolbar Undo: Input
>          All the charts update - is the expected result
>          The trend lines are now again at the file original start shapes.
> 
> I see there's a macro in the file and I don't know enough about how the file
> works to comment further. So I'll investigate trend line behaviour with
> other files.  Summary:  with attachment 114246 [details] deleting values; 
> the trend lines do not follow.  Changing a value;  the trend lines do follow
> and Undo functions also. In all tests the x,y scatter plots remove and move
> (but I think only VLB can confirm it's precisely as expected).
> 
> Version: 7.0.6.2 (x64)
> Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
> CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL:
> win
> Locale: en-US (en_US); UI: en-US
> Calc: CL

I can also see the behavior in LO 7.06 + 7.1.3 + 7.2
The behavior shouldn't happen and has nothing to do with the macro.
Comment 114 matthewnote 2021-05-09 11:47:45 UTC
(In reply to VLB from comment #113)
> (In reply to matthewnote from comment #112)
> > Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from
> > VLB)
> > 
> > Step 1.  Deleting values in H19:L19, 
> >          All the charts update - is the expected result
> >         (there are fewer valid x scatter coordinates)
> > Step 2.  Click back using toolbar Undo: Delete
> >          All the charts update - is the expected result
> >         (there are all the x valid scatter coordinates)
> > 
> > However, the trend lines on the charts are not restored to original state.
> > Saving the file (different name), then open, the trend lines are in error.

> 
> I can also see the behavior in LO 7.06 + 7.1.3 + 7.2
> The behavior shouldn't happen and has nothing to do with the macro.

Thankyou.  
Well, (if it helps QA user testing?), I compare attachment 114246 [details] with Calc 7.1.3.2 on a dual-boot machine.  
On Windows, the trend lines become disorganised when a value is deleted.  
On Ubuntu 20.04 (identical Calc Build ID) the trend lines function with the expected result.  On Ubuntu, after deleting or changing first sheet values in H19:L19, click Undo: delete. Those trend lines are moved and restored and saved correctly.

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
    compared with
Version: 7.1.3.2 / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Note:  Opening a very large file here, the Windows setup takes 3 mins 30 seconds (uses 6GB) then displays.  The Ubuntu setup takes 2 mins 12 seconds (really very fast!) :)
Comment 115 matthewnote 2021-05-09 14:34:12 UTC
(In reply to VLB from comment #113)
> (In reply to matthewnote from comment #112)
> > Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from
> > VLB)
> > 
> > Step 1.  Deleting values in H19:L19, 
> >          All the charts update - is the expected result
> >         (there are fewer valid x scatter coordinates)
> > Step 2.  Click back using toolbar Undo: Delete
> >          All the charts update - is the expected result
> >         (there are all the x valid scatter coordinates)
> > 
> > However, the trend lines on the charts are not restored to original state.
> > Saving the file (different name), then open, the trend lines are in error.
> > 
> > Step 3.  Modify value I19 from 4 to 8, the trend lines are redrawn.
> > Step 4.  Click back using toolbar Undo: Input
> >          All the charts update - is the expected result
> >          The trend lines are now again at the file original start shapes.

> 
> I can also see the behavior in LO 7.06 + 7.1.3 + 7.2
> The behavior shouldn't happen and has nothing to do with the macro.

I find, here, that in Windows with Calc 7.1.3.2 the lines are correct with
Tools>Options>OpenCL> deselect "Allow" (uncheck) Apply>Restart Now Open>Liggerv2.6.  In other words charts work here with Windows OpenCL OFF.

For QA.  

1.  It seems use of OpenCL(+Windows) is in error by introducing problem cells.
If I uninstall Libreoffice (entirely) from Windows 10 Pro then install 7.1.3.2,
then Help, Restart in Safe Mode, Reset to factory settings, Reset entire user profile, Apply Changes and Restart then OpenCL is enabled on this PC.

2.  Open attachment 114246 [details].  Message appears "You are running...for first time"
3.  roX0_9 is the open sheet.  Go to invoer and delete H19:L19 (now empty).
4.  Click back arrow Undo:delete.  H19:L19 are now with values again. 
5.  On sheet roX0_9 last chart lines are in error.  Cells DT52:DT153 are wrong.
6.  Actual result;  DT88 is showing a value of 59.441.
7.  Expected result; DT88=DQ84 which is value = 0.1512.
8.  Close file.  Reopen file.  Repeat steps 3 to 7; the error is the same.

9.  However, Close File, Close Calc, Restart Calc, Open attachment.
10. Repeat steps 3 to 5.  On sheet roX0_9 the DT column values are now correct.
11. On sheet invoer, the line for data range DT column is now wrong but it's DT column values (also on invoer) are correctly calculated and displayed.

Observations.

Use of CL with Windows on this PC is associated with cell values being wrong.  Starting 7.1.3.2 twice then open the same file causes differently wrong than the first fresh install.  Cell values become correct (although the file hasn't changed at all) with trend lines now in error (because the system has lost track of the full data range to be drawn).

Data>Calculate>Recalculate does not update the DT52:DT153 values at step 5.
Recalculate_Hard does cause the DT52:DT153 range to update.

Option OpenCL OFF causes correct presentation of all charts and their data.

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 116 matthewnote 2021-05-11 05:56:36 UTC
Referring to new observation of cell value errors Comment 112 Comment 114 and Comment 115 I suggest moving those reports to Bugs about autocalculate instead.

The Chart update is (in fact) working and shows calculation bugs.  Bug 125320 Bug 125052 or Bug 128329 expressed in new Calc 7 versions also.

With Windows + OpenCL allowed, Reset User Profile, Open attachment 114246 [details], delete H19:L19 then Undo: delete, there are errors in Sheet roX0_9 column DT (cell=other cell not being calculated).

OpenCL creates .BIN files in LibreOffice or LibreOfficeDev >4>cache and
OpenCL updates registrymodifications.xcu with many new rows

At next Open attachment, the same procedure, delete H19:L19 then Undo: delete, Sheet roX0_9 is now calculated correctly, yet now there are errors in Sheet invoer (it's own column DT).  The Chart at invoer M62 is updating it's trend line correctly, revealing incorrect calculation in the data range column DT.

The User Profile updates coincides with the autocalculation (A=B) interruption and causes a new one on a different sheet (still opening the same file without editing the file, without saving the file).  Maybe more than just a coincidence.

This gives an impression of "sporadic fail".   Because this is now reproduceable (with VLB's file) and with a User Profile reset manipulation and with OpenCL on/off reproduce and with Hard recalculate evidence. . . . . 

I suggest moving the report at comments 112, 114 and 115 to Bug 125320.
User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo.
It may not be the only one but I think it's best written there.

Would Buovjaga or Xisco agree or guide me please?
Would VLB please consider permission that I copy his test file to Bug 125320?
I intend to use it there and probably make a small screenshot video (asked for by Telesto, QA).
Comment 117 VLB 2021-05-11 06:05:37 UTC
> Would VLB please consider permission that I copy his test file to Bug 125320?
> I intend to use it there and probably make a small screenshot video (asked
> for by Telesto, QA).

Of course I agree
Comment 118 Buovjaga 2021-05-11 07:02:35 UTC
(In reply to matthewnote from comment #116)
> I suggest moving the report at comments 112, 114 and 115 to Bug 125320.
> User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo.
> It may not be the only one but I think it's best written there.
> 
> Would Buovjaga or Xisco agree or guide me please?
> Would VLB please consider permission that I copy his test file to Bug 125320?
> I intend to use it there and probably make a small screenshot video (asked
> for by Telesto, QA).

If you think you have confirmation, then sure, set it to NEW.
Comment 119 Lars Jødal 2021-05-11 07:29:24 UTC
(In reply to matthewnote from comment #116)
> I suggest moving the report at comments 112, 114 and 115 to Bug 125320.
> User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo.
> It may not be the only one but I think it's best written there.
> 
> Would Buovjaga or Xisco agree or guide me please?
> Would VLB please consider permission that I copy his test file to Bug 125320?
> I intend to use it there and probably make a small screenshot video (asked
> for by Telesto, QA).

I took a brief look at bug 125320. The description and discussion there is already somewhat long and complicated. @matthewnote: If I understand correctly, that you can add a concise description of the bug and how to replicate it, along with a not-too-large test file - then how about creating a new bug and closing bug 125320 as a duplicate of the new bug report?

Just an idea. The intention is of course to make a clean and accessible bug report, while keeping the track from bug 125320. But if important information will be lost (well, obscured) by that approach, then go on with the original bug.
Comment 120 matthewnote 2021-05-11 07:36:31 UTC
Thankyou.

For VLB, one last question here for you.  Does Windows Calc7 Option OpenCL "disabled" (OFF) work for you with this file?   It does on my PC, yet the topic depends on the computer hardware and drivers (I use Shuttle PCs with Intel).

I'm hoping to work out one more thing (why OpenCL) before moving the Feedback Report.


With OpenCL allowed,(ON), using Tools, Detective, trace precedents I studied the variable results on the invoer sheet Chart M66.  

In the steps described, after first start Calc, first load file, when delete H19:L19, invoer column DT calculates -27 for all cells DT52:DT157 but the chart displays a "sawtooth".  At Undo: delete it's the reverse. . .column DT calculates a "sawtooth" but the chart displays the old values before the undo (mostly -27).  In other words, the chart is updating but one action "late".

If it's useful for you to see when the autocalculate block is occurring, at the first start of Calc, first load of file, first Undo: delete, using Data>Calculate>Recalculate_Hard the column EB cells (example EB58); =IF(EXACT(EA58,$X$68)=TRUE(),TRUE(),"")  now update from WAAR to empty "".

At that moment Chart M66 can/does adopt the values of the "sawtooth" in column DT.  However, even if I delete all the column EB (save new file) and start again, the link between DT calculated and chart not-yet is still occurring. So EB column changes are interesting coincidence (visual) but the chart seems not to depend on that column.  

I find bug reports and histories of bugs in Calc concerning Grouped Formulae and Software Interpreter and OpenCL.  (Skia seems to work! :)

@VLB  I hope that helps (to know about visual column cell clues while engineering) and that Calc7 OpenCL disabled works for you for this particular file (does it?).

I promise I will soon cease posting on this thread ! : )
I (personally) am a very happy engineer now the charts update.  Great!
Comment 121 VLB 2021-05-11 08:29:09 UTC
(In reply to matthewnote from comment #120)

I don't quite understand what is not going well, but I have the impression that it works for me with Wi 10 pro.
However, I can find that recalculating column EB, that it does not recalculate at fresh start of file in some situation and that this column is recalculated only when saving and reopening. This mainly happens when I change cell E12 to value "C18" after starting file.

With this I can recognize bug 125320.
Comment 122 b. 2021-05-14 16:51:12 UTC
(In reply to matthewnote from comment #120)

hello matthew, 

as you are / had been struggeling with 'problems on load' tdf#140722 might be interesting, reproducible fail on load,
Comment 123 matthewnote 2021-05-28 06:50:53 UTC
> However, I can find that recalculating column EB, that it does not
> recalculate at fresh start of file in some situation and that this column is
> recalculated only when saving and reopening. This mainly happens when I
> change cell E12 to value "C18" after starting file.
> 
> With this I can recognize bug 125320.

Well; I think I've found the problem and the consequences (Charts are mixed up, showing data that's not in any column on any sheet) and why.

I will write a bug report (if someone can please reproduce?), yet one item at a time.  I'm sorry to use the word important in these steps.  They're simple, but something very complex is occurring.  You may not see the same effect because it all depends on version, windows, OpenCL and file history (user profile);  so for anyone testing, it's very helpful if you describe what is different.  It doesn't "have to" be the same effect.  The steps are simple and only one (!) user action. I'm asking because I may be able to make a much bigger contribution about something else.

Can you please use these steps?
Step 1.  Close actual work with Libreoffice (Writer or Calc)or restart computer.
Step 2.  (Important to follow) Start Calc but do not open any other file.
Step 3.  Open only the attachment, only file Ligger V2.6 attachment 114246 [details]
Step 4.  Go to sheet invoer.
Step 5.  Use mouse to Select H19 to L19. Those cells now highlighted.
Step 6.  Use keyboard (important) delete key to empty those cell values.
Step 7.  Observe column EB; most cells EB50 to EB148 change to WAAR.
Step 8.  Observe chart at M66; the traces change to sawtooth.
Step 8.  Use mouse (important) toolbar "back arrow" to "Undo:delete".
Step 9.  Observe column EB; the cells do not go back to original state.
Step 10. Observe chart at M66; one line (for DT data) does not go back.

[At this stage, something complex is occurring in the memory;  please don't touch any cell or chart or data range;  please just observe and compare to help me help you].

Step 11. Close Libreoffice (close the program) and do not save the file.
Step 12. Start Libreoffice and open only the attachment, only file Ligger V2.6
Step 13. Go to cell AM38.  Function is ==IF((L_7>0),Mh/Mh_freq,"")
Step 14. Change the function to =IF((L_7>0),Mh/Mh_freq,""), remove double==
Step 15. Immediately save the file as "Ligger V2.6 test repair by VLB.ods"
Step 16. Close Libreoffice (close the program)
Step 17. Start Libreoffice and open the new test repair file.
Step 18. Please test using Step 4 to Step 10.

[At this stage, on this computer here, column EB and the chart M66 and all data on every sheet respond correctly about all functions :).  It would be great if you could use the file intensely.  Also, please let me know if E12 action is still a problem or resolved for you.  I can do more.

Step 19. (Important). Click Calc>Help>About>Version information button.  Please right-click paste on your response here (or in email).  Please attach here or email the "test repair by VLB" file from your PC.  What you see or don't see (in columns and charts) depends on that information.

@Buovjaga
I write here about this rather than on the other Bug report because it concerns VLB's file.  I hope someone reproduces this! Then I'll create a new Bug report.

On this PC here, running Calc 7.2 on Windows 10 Pro, the == is tolerated (no Err:509 message)then code mixes up everything with big consequences.  I will describe all effects but it includes charts showing data before the column (which is fun but very difficult to notice - I can notice because I use two 4K monitors).  soffice then writes a ghost bug into the User Profile (I watch it using Windows security auditer).  Then OpenCL mixes it all up again at next Calc start.  In my report I hope to be precise including the User profile damage detail, line by line.  Safe mode, factory settings gives yet another mix (doesn't make it worse, doesn't help the user, just different again).

It's easy to suggest "include a new syntax check for == and show code 509, commit, bugfix, finished".  I'll start the new bug report (after someone reproduces).  I've seventy simplified versions of VLB's file, also to find out if it's Ooo or Calc 4 and so forth.  

Yet, it's a lot more useful to find out all the possible causes of sporadic fails and hard recalculate. Perhaps I can contribute on that story (it's possible).  But I do need a "reproduce" windows 10, OpenCL allowed (from someone else).

@Buovjaga
The technique I used to find the == syntax in AM38 was by inspecting every single cell in VLB's file.  Really.  Detective has it's limitations but helped a lot.  I started on the last sheet (eliminating dependents for everything but one trend line).   The precedent tracing was a colossal workload. Then I put everything on one sheet (which was extraodinarily difficult, yet entirely logical).  Nothing in the file broke; I saw some odd behaviour when removing redundant named expressions but still couldn't actually break the file.  Great work Frank!  I don't know why I'm laughing now!  Because Calc doesn't know to criticise == it just seemed likely that I was searching for something that I didn't know either.  Well, the work exonerates Group Formulae (for this case) and a hundred other calc features - so no regrets!  AM38 doesn't actually have any dependents. == probably caused by keyboard bounce (I use only logitech products).  == (and other strangers) might be introduced by software, but checking 300 000 cells, I didn't see evidence of keyboard firmware or language problems.  VLB uses greek and dutch (I think) but it all works.  I don't know of any other choice than cell by cell check when the problem is unknown (to the software also).  I divided up the task (of course);  point is . . to learn from this . .is there any particular technique or tool that a User might consider, that you prefer for this type of investigation?

For 125320 , I've prepared Virtual Studio and debug to learn how that helps.
Comment 124 matthewnote 2021-05-28 07:00:50 UTC
I'm using this version and using == as a deliberate infection to diagnose further.  Thinking positive!

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 1675a68526c43c6c6e4dc850ee911f0c1de75c88
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 125 VLB 2021-05-28 08:53:59 UTC
Created attachment 172401 [details]
Opgeslagen bestand na test door VLB

Behoort bij comment 125.
Comment 126 VLB 2021-05-28 08:56:20 UTC
> Can you please use these steps?
> Step 1.  Close actual work with Libreoffice (Writer or Calc)or restart
> computer.
> Step 2.  (Important to follow) Start Calc but do not open any other file.
> Step 3.  Open only the attachment, only file Ligger V2.6 attachment 114246 [details]
> [details]
> Step 4.  Go to sheet invoer.
> Step 5.  Use mouse to Select H19 to L19. Those cells now highlighted.
> Step 6.  Use keyboard (important) delete key to empty those cell values.
> Step 7.  Observe column EB; most cells EB50 to EB148 change to WAAR.
> Step 8.  Observe chart at M66; the traces change to sawtooth.
> Step 8.  Use mouse (important) toolbar "back arrow" to "Undo:delete".
> Step 9.  Observe column EB; the cells do not go back to original state.
> Step 10. Observe chart at M66; one line (for DT data) does not go back.
> 
> [At this stage, something complex is occurring in the memory;  please don't
> touch any cell or chart or data range;  please just observe and compare to
> help me help you].
> 
> Step 11. Close Libreoffice (close the program) and do not save the file.
> Step 12. Start Libreoffice and open only the attachment, only file Ligger
> V2.6
> Step 13. Go to cell AM38.  Function is ==IF((L_7>0),Mh/Mh_freq,"")
> Step 14. Change the function to =IF((L_7>0),Mh/Mh_freq,""), remove double==
> Step 15. Immediately save the file as "Ligger V2.6 test repair by VLB.ods"
> Step 16. Close Libreoffice (close the program)
> Step 17. Start Libreoffice and open the new test repair file.
> Step 18. Please test using Step 4 to Step 10.
> 
> [At this stage, on this computer here, column EB and the chart M66 and all
> data on every sheet respond correctly about all functions :).  It would be
> great if you could use the file intensely.  Also, please let me know if E12
> action is still a problem or resolved for you.  I can do more.
> 
> Step 19. (Important). Click Calc>Help>About>Version information button. 
> Please right-click paste on your response here (or in email).  Please attach
> here or email the "test repair by VLB" file from your PC.  What you see or
> don't see (in columns and charts) depends on that information.
> 

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: CL

I have gone through the steps and can indicate my findings:
In steps 8 and 9, the value will go back in column EB for me.
At step 10 I see 1 line that does not go back in a sawtooth.
After performing step 18, the graph in step 10 is displayed correctly.
I added the saved file as an attechment.
Comment 127 Lars Jødal 2021-05-28 09:37:10 UTC
Using LO v. 7.1.3.2, i.e. current fresh version, on Win10, OpenCL active:

(In reply to VLB from comment #126, who uses steps from matthewnote comment 123)
> > Can you please use these steps?
> > Step 1.  Close actual work with Libreoffice (Writer or Calc)or restart
> > computer.
> > Step 2.  (Important to follow) Start Calc but do not open any other file.
> > Step 3.  Open only the attachment, only file Ligger V2.6 attachment 114246 [details]
> > [details]
> > Step 4.  Go to sheet invoer.
> > Step 5.  Use mouse to Select H19 to L19. Those cells now highlighted.
> > Step 6.  Use keyboard (important) delete key to empty those cell values.
> > Step 7.  Observe column EB; most cells EB50 to EB148 change to WAAR.
> > Step 8.  Observe chart at M66; the traces change to sawtooth.
> > Step 8.  Use mouse (important) toolbar "back arrow" to "Undo:delete".
> > Step 9.  Observe column EB; the cells do not go back to original state.
> > Step 10. Observe chart at M66; one line (for DT data) does not go back.

Upon opening: I reject macros.
Checking the column EB before doing anything: A few cells show WAAR. After the deletion: most cells show WAAR, as described in step 7.

On step 9: I can confirm that after undo from menu, column EB has not changed back to how it was.
On step 10: I can confirm that in the cart at M66, one curve (representing data from the DT column) is partly flat and near the horizontal axis, rather than being sawtooth, and this curve represents data from the DT column.

In short, I can confirm the strange behaviour reported in steps 9 and 10.

> > [At this stage, something complex is occurring in the memory;  please don't
> > touch any cell or chart or data range;  please just observe and compare to
> > help me help you].
> > 
> > Step 11. Close Libreoffice (close the program) and do not save the file.
> > Step 12. Start Libreoffice and open only the attachment, only file Ligger
> > V2.6
> > Step 13. Go to cell AM38.  Function is ==IF((L_7>0),Mh/Mh_freq,"")
> > Step 14. Change the function to =IF((L_7>0),Mh/Mh_freq,""), remove double==
> > Step 15. Immediately save the file as "Ligger V2.6 test repair by VLB.ods"
> > Step 16. Close Libreoffice (close the program)
> > Step 17. Start Libreoffice and open the new test repair file.
> > Step 18. Please test using Step 4 to Step 10.

After the repair (double== to single= in cell AM38 of "invoer" sheet, save, close LO, and then steps 4-10 on the repaired file), undo appears to work fully. 
I.e., I can confirm that the double== made LO have strangely.

Version information:

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: CL

No user profile reset.
OpenCL active.

Bonus information: If I de-activate OpenCL (and start with the original file, of course), then I cannot reproduce. Re-activating OpenCL, I can again reproduce. This confirms the part of comment 123 that ties the behaviour to OpenCL.
Comment 128 matthewnote 2021-05-29 11:33:07 UTC
Thankyou.

Generated new Bug 142556, set to NEW.
I'm not sure about priorities for "User hell" so accepted the default.
Comment 129 matthewnote 2021-06-16 09:38:53 UTC
(In reply to Xisco Faulí from comment #96)
> Hi,
> My patch in comment 95 fixes the steps in comment 28. For other issues,
> please, fill a new report. Closing as RESOLVED FIXED

Hi
After testing with my contributed attachment, I returned to test VLB's attachment some more.  Use of undo:delete caused data range errors yet charts mostly followed (including plotting those errors)

Yet now I analysed that a chart also fails to update in one circumstance.  It's a mix of symptoms yet I hope the work offers a vital clue (maybe).

Created Bug 142891