Created attachment 167943 [details] Books from a school in Africa. The Student Transaction report does not update on a Windows 11 operating system when the Date filter is expanded to include several years or more of transactions. *** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY Transaction report fails to update when I expand the date range to include a large number of transactions STEPS TO REPRODUCE 1. Open the attached came my money.KY file on a Windows 11 operating system. 2. Go to the report section under transaction reports and run the student transaction report. 3. Change the date filter on the report to include all dates and the report does not update. OBSERVED RESULT Report does not generate output or update if the date range is too large. EXPECTED RESULT The report should update to include the date range that is filtered on. SOFTWARE/OS VERSIONS Windows: 11 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION The report does update when I run it on a Lennox machine running Debian.
The content of attachment 167943 [details] has been deleted for the following reason: Removing confidential information
Let me know if you are unable to duplicate the bug without a large transaction set. Thanks. Andy > On Mar 30, 2024, at 3:26 PM, Ben Cooksley <bugzilla_noreply@kde.org> wrote: > > https://bugs.kde.org/show_bug.cgi?id=484759 > > --- Comment #1 from Ben Cooksley <bcooksley@kde.org> --- > The content of attachment 167943 [details] has been deleted for the following reason: > > Removing confidential information > > -- > You are receiving this mail because: > You reported the bug.
It's a matter of waiting :) The data set is large (many transactions) and creating the report over all of them takes a while. I tested against current master version on Windows (but it takes a long time on Linux too). You may take a look at CPU usage when changing the period. ps : hope you don't mind that I requested to remove the file for privacy reasons.
Forgot to change status
Looking at the runtime distribution using hotspot (https://github.com/KDAB/hotspot) I noticed that the time is burned in setHtml() of either QWebEngineView/KWebView (5.1) / QTextBrowser (master). The generated page sizes of the reports are ~380 KB vs. 2.7 MB.
(In reply to Thomas Baumgart from comment #3) > It's a matter of waiting :) The data set is large (many transactions) and > creating the report over all of them takes a while. I tested against current > master version on Windows (but it takes a long time on Linux too). You may > take a look at CPU usage when changing the period. > > ps : hope you don't mind that I requested to remove the file for privacy > reasons. I will try giving it more time. On my Linux machine the report finishes in about 3 seconds, but it is a fast computer. No problem on removing the file. There was nothing in there that anyone could understand..... I'm pretty sure.
I ran the report using all dates on the Lennox machine just to double check the time. It took four seconds. On the windows machine if I open the report with a 1 year date range, it runs in about 4 seconds also, but if I expand the date filter to 4 years and click apply, the machine is busy for 5-10 seconds and then become idle again but the report does not change. The report filter still shows the expanded date range but the report does not update. The system is happy to let me shorten the date range and if short enough, it gives me the update. If I close the report with a large date range in the filter, I get no output, even after waiting for 5 minutes. It will however allow me to shorten the date range from the blank report screen and runs the shortened range in 1 sec. I still think this is a bug.
(In reply to Thomas Baumgart from comment #5) > Looking at the runtime distribution using hotspot > (https://github.com/KDAB/hotspot) I noticed that the time is burned in > setHtml() of either QWebEngineView/KWebView (5.1) / QTextBrowser (master). > The generated page sizes of the reports are ~380 KB vs. 2.7 MB. I don't know what this comments means. Please give me some more explanation. Thanks.
(In reply to Andy from comment #7) > I ran the report using all dates on the Lennox machine just to double check > the time. It took four seconds. On the windows machine if I open the report > with a 1 year date range, it runs in about 4 seconds also, but if I expand > the date filter to 4 years and click apply, the machine is busy for 5-10 > seconds and then become idle again but the report does not change. The > report filter still shows the expanded date range but the report does not > update. The system is happy to let me shorten the date range and if short > enough, it gives me the update. > > If I close the report with a large date range in the filter, I get no > output, even after waiting for 5 minutes. It will however allow me to > shorten the date range from the blank report screen and runs the shortened > range in 1 sec. I still think this is a bug. The last part should say: If I close the report with a large date range in the filter, when I reopen it, I get no output, even after waiting for 5 minutes. It will however allow me to shorten the date range from the blank report screen and runs the shortened range in 1 sec. I still think this is a bug.
It almost sounds as if it has actually completed generating the report, but fails to display the results properly. If it was still working on generating the report, I don't think you would be able to just close the report. That might tie in with Thomas' comment about the time being taken up in the setHtml() function and the html output being much larger on Windows than on Linux. I'm not sure how to test or resolve, but after it produces the blank output, can you export the report as html? Then try opening it in a browser.
(In reply to Jack from comment #10) > It almost sounds as if it has actually completed generating the report, but > fails to display the results properly. If it was still working on > generating the report, I don't think you would be able to just close the > report. That might tie in with Thomas' comment about the time being taken > up in the setHtml() function and the html output being much larger on > Windows than on Linux. I'm not sure how to test or resolve, but after it > produces the blank output, can you export the report as html? Then try > opening it in a browser. You are absolutely right. If I export the report it has been generated it's just not displaying. That's a fix but still seems it would be good to have it display. The html file is indeed over 2MB.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Since there is a workaround, it is not critical, but should we reopen this, changing the subject to reflect that the problem seems to be in the display of the produced html, not in actually producing the html report? Does anyone know/has anyone tested whether the same problem is still present in master branch?
(In reply to Jack from comment #14) > Since there is a workaround, it is not critical, but should we reopen this, > changing the subject to reflect that the problem seems to be in the display > of the produced html, not in actually producing the html report? Does > anyone know/has anyone tested whether the same problem is still present in > master branch? Agreed. The work around is reasonable, but not obvious. Changing the Subject as you suggested is a good idea.
Andy - have you tried using a version from master branch? If the problem is not still present there, we can assume it's been fixed, which would be different from reopening as still present, even if low priority.