Description: If you look at the chart titled "7-day average of %positive"at the bottom right of the sheet named "Graphs" you will notice that the graph shows values approximately equal from about date 8-06 to 8-25. This is incorrect! To figure out what had gone wrong, I double-clicked on the chart to edit the ranges. Lo and behold, the chart changed and displayed the correct data! Then when I clicked somewhere else to get out of edit-mode, it went back to displaying the wrong data. This happens consistently and repeatedly. I finally fixed the problem by cutting and pasting the chart somewhere else, deleting the original chart, and moving the new version back to where the original chart was. The data for the chart is on sheet "covidtracking.com data", the third sheet. The way I got into this mess was this: 1) I mucked up the data for 08-06 (more or less) to 08-25. At that point the chart was consistent and displayed exactly what it shows now. 2) Then I corrected the data by dragging a formula down from about B300 to populate the rest of the column. 3) At this point, I noticed that the chart hadn't changed, even though the data had. 4) I double-clicked on the chart to edit it, and the chart changed to display the correct data. But as I said above, when I left edit-mode the chart somehow remembered the old, bogus data and displayed that. Steps to Reproduce: 1.Just take my error.xlsx file and double-click on the "7-day average of %positive" chart, the last one on the sheet named "graphs". 2.Then click somewhere else. Actual Results: The chart goes back and forth from displaying the correct data (when in edit-mode) and displaying the incorrect data (when not in edit-mode) Expected Results: See above; the chart went back-and-forth between displaying the wrong data and displaying the correct data. Reproducible: Always User Profile Reset: No Additional Info: It should have displayed the correct data consistently in the chart. Info from "About LibreOffice": Version: 6.3.6.2 (x64) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Created attachment 164729 [details] File to use to create the bug according to my recipe.
I have discovered that when I save and re-open the file the bug goes away, so my original description of how to recreate the bug doesn't work. I tried to add a new description, but I can't find it. So here is the new, valid recipe for how to recreate the bug starting with the file I have attached: In the file I have attached, edit cell B285 in sheet "covidtracking.com data" to say =3. Click on that cell, then click on the lower-right corner, and drag it down the column to B377. The data as displayed in the chart should now display 300% for all dates. Next, click on cell B284, click on its lower-right corner, and drag it down to cell B377 . Look at the chart, and it will still show a horizontal line at 300% for all dates. But if you double-click on the chart to edit it, it now displays the updated correct data from the B column. It's as if the chart somehow remembers the old, obsolete data.
This problem is recurrent since 2014 and it's often that using the file on someone else's computer with another Calc version shows the graphic working. This frustrates bug reporting on this topic. Bug #136254 Bug #86321 Copying the chart to the same sheet then deleting the original can also produce a new working chart for the user in difficulty. Resetting user profile has (for the moment) never yet resolved a broken chart. Some users find that just saving the file with a different name then reopening will cause it to function for a few more days (then, after a while working with the calculations in the cells or copying an entire sheet; the chart's broken again). Some users start a new spreadsheet and fill it by "Insert sheet from file" taking one sheet at a time from the file with the problem. They report that this seems to generate a "clean" version without remaining records of previous work that conflict. It's very difficult to reproduce consistently and usually a sample file will work elsewhere. Thankyou for the sample files. Tested here with Calc 6.3.5.2 on Ubuntu 18.04 LTS - graphic updates. Fault state not reproduced. Calc 7.0.1.2 on Ubuntu 18.04 LTS - graphic updates. Fault state not reproduced. As above, this is a typical result. SRS, do you have a moment to copy and paste the "broken" chart on your sheet using your system to see if you can cause one chart "broken", it's twin "working"?
Thanks for looking at this, Matthew. I wanted to see if I could do as you asked, creating a file with a working chart and a non-working chart from the same data. But I wasn't able to recreate the bug at all! My error.xlsx file didn't exhibit the problem. I realized I had upgraded from 6.3.6.2 to 6.4.6.2, so I downgraded back to 6.3.6.2. The problem still didn't appear! For what it's worth, when I first saw the problem, back in August, I tried copying the chart. The copied chart worked correctly and I even deleted the original and replaced it with the copied chart; there was no problem at that point. Also, saving and re-opening the file made the problem go away. I am now going to upgrade to v7 and check out the problem. If I see it again, I'll do some tests and update the bug. Maybe there is some random state introduced whenever I install LibreOffice that controls whether this bug happens?
(In reply to SRS from comment #4) > Thanks for looking at this, Matthew. I wanted to see if I could do as you > asked, creating a file with a working chart and a non-working chart from the > same data. But I wasn't able to recreate the bug at all! My error.xlsx > file didn't exhibit the problem. > I realized I had upgraded from 6.3.6.2 to 6.4.6.2, so I downgraded back to > 6.3.6.2. The problem still didn't appear! > For what it's worth, when I first saw the problem, back in August, I tried > copying the chart. The copied chart worked correctly and I even deleted the > original and replaced it with the copied chart; there was no problem at that > point. Also, saving and re-opening the file made the problem go away. > I am now going to upgrade to v7 and check out the problem. If I see it > again, I'll do some tests and update the bug. > Maybe there is some random state introduced whenever I install LibreOffice > that controls whether this bug happens? Hello SRS Thankyou for looking again. Bug Report 86321 has followed this problem since 2014. Changing versions or modifying files (edit, copy sheet, save and so forth) can break something that was working before. Very difficult to pin down. However we have contributed two obviously/consistently damaged .ods files on that Bug Report. The long term problem is how to share the report with colleagues or even students? The new chief of development marketing of LibreOffice comments that the category "minor" yet still "Most Annoying Bug" includes the problem of loss of reputation (LibreOffice) or inability to share files (Users). So we will hope to make progress by boosting the priority to "Normal" and contribute/wait. This problem nearly always comes back. AppImage versions of Calc can immediately (mostly) open and save suspect files with everything working. However, that rescue and repair tool is a "runs in a box, nothing installs" package for Linux. To my knowledge, there's no equivalent super-app like that for Windows. Would you mind looking once at that Bug 86321 (needs 15 minutes to read all of it) and contribute there if/when you see problems in future? All on the same page, as it were. For the moment we are a Steel Construction Engineer, a Doctorate of Nuclear Medecine and I (Signal Processing Engineer analysing Cancer Diabetes data). 136254 was also started but the contributor hasn't yet responded. OK with you then that I change the status here to "duplicate of 86321"? Note: bugzilla then marks it as "resolved-duplicate" too (which it isn't). Just closing this thread (still visible and readable) here will redirect other Users to look at the full history (with developers' reactions or none) and concentrate the reporting that is seen by all. Up to you.
Reproduceable – yet not always. Reproduced once only – precisely as described, graph showing incorrect plots starting near 8. graph failing to update with covidtracking data series. 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 Not reproduced 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 Not reproduced 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 Not reproduced AppImage Version: 5.3.6.1 Build ID: 686f202eff87ef707079aeb7f485847613344eb7 CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk2; Layout Engine: new; Locale: en-US (en_US.UTF-8); Calc: group Not reproduced two weeks later 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
"OK with you then that I change the status here to "duplicate of 86321"? Yes, that is OK.
*** This bug has been marked as a duplicate of bug 86321 ***