Created attachment 155709 [details] file example to duplicate the issue Steps to duplicate: 1. Open the attached file. 2. Go to Slide Show->Start From First Slide. The slide show will start and will keep looping from first->second->first etc. I would expect that it will keep looping indefinitely. It does work fine in Windows (Win64 and Win32) and Linux 64bit. But with a Linux 32bit build the slide show will stop at a random slide after 10-20min. After it stops if I press the right arrow key the slideshow will start looping again, only to stop randomly again after a while (at which point I can get it going again by pressing the right arrow key). If I have it in multi monitor mode it will stop but all the current time and slideshow time clocks will be correct and keep running in the second monitor, but the slideshow is still stuck. I have tested so far with the libreoffice found in Raspbian Buster (raspberry pi, libreoffice 6.1.5) and in a i386 debian VM with the version if buster-backports (libreoffice 6.3.3.2).
I just duplicated this also in the latest master from anongit.
Also saw these asserts in the log: soffice.bin: gtk3gtkdata.cxx:679: virtual void GtkSalTimer::Start(sal_uInt64): Assertion `nMS <= G_MAXINT' failed. soffice.bin: gtk3gtkdata.cxx:679: virtual void GtkSalTimer::Start(sal_uInt64): Assertion `nMS <= G_MAXINT' failed.
Hi there, I have exact same issue... I reported a bug 131294. Did you find any solution for it? Thanks.
*** Bug 131294 has been marked as a duplicate of this bug. ***
I also ran into this issue while making a Raspberry Pi kiosk type application. I found that it always seemed to stop within 20-30 minutes but the stop time wasn't consistent. A made a workaround where I monitor the slide index and if it doesn't change within a few seconds of when it's supposed to, I manually advance the slide. This works very reliably and the slideshow will continue for over an hour after before freezing again and I thought that seemed suspiciously like a pattern. I started logging the stop times and found that after the first stop, which is seemingly random, it always stops after 71 minutes 34-35 seconds. When converted to seconds it's 4294 seconds. In microseconds that's 4294000000 which is just about the max number you can get from a 32 bit unsigned integer which is 4294967296. It seems that this bug is definitely a result of running on a 32 bit system and the slideshow timer seems to be using a clock that runs independent of libreoffice/impress because it stops at a random time the first time after starting the slideshow. I'm also using Raspian Buster, libreoffice 6.1.5.2
Hi, The only options are to convert libreoffice to PDF and then to Images and use the slideshow from the images. This would be basic function of a PowerPoint program... Unfortunately, the libreoffice (impress) slideshow is getting stuck on Buster 32-bit version after about 20-30 minutes. Libreoffice version 6.1.5.2 Build ID: 1:6.1.5-3+rpi1+deb10u7+rpt1 Running: Linux 5.10.60-v7+ #1449 SMP Wed Aug 25 15:00:01 BST 2021 armv7l GNU/Linux The only way it has worked without any issues is on a 64-bit Buster. Linux 5.10.52-v8+ #1441 SMP PREEMPT Tue Aug 3 18:14:03 BST 2021 aarch64 GNU/Linux. Wondering if there is a way to cross-compile libreoffice and install the 64-bit over to the 32-bit OS? The other way I am running the slideshow is to monitor for cpu % of soffice process and if the cpu has been peaking above 97% or cpu has been tanking below 0.3% for about 2 minutes, that means the slideshow is stuck. And then restart the slideshow. Its pretty antiquated. But no other choice. This has been like this from past 3 years. Hope OpenOffice team will have a fix for this soon. Thanks.
https://gerrit.libreoffice.org/c/core/+/126379
*** Bug 144975 has been marked as a duplicate of this bug. ***
Urja Rannikko committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7fa9b09bc271d91792fe78c5cb03430bf38155a8 tdf#128715 fix tools::Time::GetMonotonicTicks() on 32-bit linux It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Urja Rannikko committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/18407807085e47f56ec972c2e1ce6db9a2375e21 tdf#128715 fix tools::Time::GetMonotonicTicks() on 32-bit linux It will be available in 7.3.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Urja Rannikko committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/e6421938fbab713fff64aef6ff864f68882fb258 tdf#128715 fix tools::Time::GetMonotonicTicks() on 32-bit linux It will be available in 7.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
7.2.4 was a hotfix release, updating target in status-whiteboard