| Summary: | Slideshow skips photos | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | bogdan |
| Component: | Plugin-Generic-SlideShow | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bogdan, caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 6.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/2ded8ebed3f3ff9b7832c7652506669193869ab9 | Version Fixed In: | 6.4.0 |
| Sentry Crash Report: | |||
| Attachments: | skip slides digikam log | ||
|
Description
bogdan
2019-10-13 14:54:53 UTC
This is not reproducible here. Please post the output from the console during the slideshow. Maik You answered to quickly to have tried. Have you actually tried? Please let me know how to capture the console output. I suppose that is not starting digikam from coomand line yes just starting digiKam from command line. I also tried with git/master code, and it's not reproducible here. Gilles Caulier I am not at home now, I will do it in a couple of hours Created attachment 123176 [details]
skip slides digikam log
log for digikam while doing a slideshow
The initial scan of the collection will take you 43 seconds during this time the database is partially blocked. This has already been improved in the pre-release version of digiKam 6.4.0. Maybe that's the cause. Are the images numbered continously? Otherwise, I see no error message, the file indexes are all processed. Maik Looking at the counter it seems that it goes through all of them but some are not displayed but instead just the number is listed in the bottom left corner for a fraction of a second. I believe that the size of the images matter. I have Sony a7rIII with 42 MP which roughly converts to over 40 MB of data. I assume that your testing is using much smaller pictures. I don't think that it is related to the initial scan because the skipping happens everywhere during the slideshow. If you look carefully at the log you will discover abnormalities. For example for fileindex 4 and 6 the log is shorter and do not list the filename, whereas for fileindex 5 and 7 the log is much longer and lists the filename including the path of the file I believe there is a possible lock mechanism problem between waiting the display of the previous picture and loading the next picture. This happens everywhere duding the slideshow and not only at the beginning, therefore, is not related to the initial scan, unless the list is build then and some files are not getting the path correctly. Between the file indexes is not always a loading process is not an error. The slideshow does preloading images, so the load process is not synchronous. Maik I understand that, but nevertheless, those pictures at the indices that are not loaded are also not displayed. As I said I don't see 30 to 40% of the images. Perhaps some sort of ensuring that all pictures are loaded should be added to the asynchronous mechanism. In my case, because the files are big, it is possible that the timeouts, or whatever mechanism is in place, are not sufficient to ensure the loading of all the pictures for the slideshow. As more cameras will come out with high resolutions, it is very possible that you will get more bug reports like mine. My conclusion is that the existing asynchronous mechanism is not safe enough to ensure that all the pictures in a collection will be shown. Please investigate for a better locking mechanism, or, if not possible add some synchronicity. In my case I had 146 pictures at around 40 MB each, which will give some guidelines for testing with something similar. Thanks, Bogdan I can now reproduce the problem with HEIC images that take a bit longer to load and a slideshow rate of 1 second. Will be fixed... Maik Maik, yes, HEIF take a while to decompress. This is why i implemented the JPEG preview support in XMP digiKam namespace. Like this HEIF work like TIFF, PNG, or JPEG2000. This require my big patch in Exiv2 from my devel branch, that i backport to master with a PR in github. Gilles Git commit 2ded8ebed3f3ff9b7832c7652506669193869ab9 by Maik Qualmann. Committed on 16/10/2019 at 19:56. Pushed by mqualmann into branch 'master'. fix skip images when the image loading is not ready FIXED-IN: 6.4.0 M +2 -2 NEWS M +16 -1 core/utilities/slideshow/slideosd.cpp M +2 -0 core/utilities/slideshow/slideosd.h M +2 -0 core/utilities/slideshow/slideshow.cpp https://invent.kde.org/kde/digikam/commit/2ded8ebed3f3ff9b7832c7652506669193869ab9 I see that you implemented a polling mechanism. I hope that it works for me too. Is there any build I can download and test? I would rather not build the entire package myself. Perhaps an AppImage? Thanks Bogdan I currently works to AppImage, to solve some lib problems not relevant of this entry. I hope to restore AppImage workflow while this week end. Check file dates later on this repository: https://files.kde.org/digikam/ Best Gilles Caulier Question:
Should line 344 be
if (d->progressBar->value() >= d->settings.delay)
instead of the existing one
if (d->progressBar->value() == d->settings.delay)
?
What if the polling mechanism goes over the settings.delay value and the picture is still not loaded? if is is not == it will go directly to displaying the slide?
The QProgressBar value always remains in the set range of minimum and maximum. Maik Still having issues with the libs dependencies? I don't see a recent appimage in the https://files.kde.org/digikam/ directory. yes APPImage scripts are broken. I'm working on... Gilles Caulier I could finally test it. Slideshow works fine, it does not skip pictures anymore. Thanks thanks for the feedback gilles caulier |