Download it now!
Bug 86321 - EDITING, FORMATTING: diagram didn't automatic update when change variable (recalculation not triggered)
Summary: EDITING, FORMATTING: diagram didn't automatic update when change variable (re...
Status: NEW
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:
Keywords: bibisected, regression
: 87383 87622 90083 90674 91931 136160 136254 (view as bug list)
Depends on:
Blocks: Chart
  Show dependency treegraph
 
Reported: 2014-11-15 20:41 UTC by VLB
Modified: 2020-10-29 15:55 UTC (History)
16 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

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
Bibisect results from 43all:
(Just a whisker before 4-3-branch-point...)

ea5723ff672d4a3ffb9ee123a96dda4681703a50 is the first bad commit
commit ea5723ff672d4a3ffb9ee123a96dda4681703a50
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed May 21 08:57:55 2014 +0000

    source-hash-1b8cfd5d1414da9127ff18e4701b40f5bceabb36
    
    commit 1b8cfd5d1414da9127ff18e4701b40f5bceabb36
    Author:     Markus Mohrhard <markus.mohrhard@collabora.co.uk>
    AuthorDate: Tue May 20 23:59:55 2014 +0200
    Commit:     Markus Mohrhard <markus.mohrhard@collabora.co.uk>
    CommitDate: Wed May 21 01:50:44 2014 +0200
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.