|
Hey everyone,
I recently have a problem with digikam version 2.5. I have no exact idea when this started because I am using this version for some longer time now. Anyway, the problem is that for some albums suddenly the icon view contains only a subset of the actual images. However, the count in the tree view is correct. It somehow happens only with albums I imported recently and each time I import them again different images are missing. I suspect there is some kind of database corruption involved because in the Images table I could find entries for some of the affected images which did not have an album number assigned. Any idea on how to debug or solve this? I never really had a look at the database code so far. Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hey again,
On 16.04.2012 18:39 schrieb Johannes Wienke: > I recently have a problem with digikam version 2.5. I have no exact idea > when this started because I am using this version for some longer time now. > > Anyway, the problem is that for some albums suddenly the icon view > contains only a subset of the actual images. However, the count in the > tree view is correct. It somehow happens only with albums I imported > recently and each time I import them again different images are missing. > > I suspect there is some kind of database corruption involved because in > the Images table I could find entries for some of the affected images > which did not have an album number assigned. Any idea on how to debug or > solve this? I never really had a look at the database code so far. query the database with the same query digikam uses, all relevant images are returned. So I suspect the database is ok. So the images must be swallowed at some later time. Has anyone got some idea how to find out where they disappear in the long model-view chain? Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
> I tried to debug this further. What I can see is that if I manually > query the database with the same query digikam uses, all relevant images > are returned. So I suspect the database is ok. So the images must be > swallowed at some later time. Has anyone got some idea how to find out > where they disappear in the long model-view chain? The immediate entry point from the ioslave is ImageAlbumModel::slotData() The place where entries are actually added to the model, with beginInsertRows etc., is ImageModel::publiciseInfos(). Filtering is done in ImageFilterModelFilterer::process(), for optimization three different code paths are written out, the relevant line is always package.filterResults[info.id()] = ... (the result is cached) These key points should give a hint where your images are lost. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
On 18.04.2012 21:20 schrieb Marcel Wiesweg:
> >> I tried to debug this further. What I can see is that if I manually >> query the database with the same query digikam uses, all relevant images >> are returned. So I suspect the database is ok. So the images must be >> swallowed at some later time. Has anyone got some idea how to find out >> where they disappear in the long model-view chain? > > The immediate entry point from the ioslave is ImageAlbumModel::slotData() > The place where entries are actually added to the model, with beginInsertRows > etc., is ImageModel::publiciseInfos(). > Filtering is done in ImageFilterModelFilterer::process(), for optimization > three different code paths are written out, the relevant line is always > package.filterResults[info.id()] = ... (the result is cached) > > These key points should give a hint where your images are lost. moment digikam does not compile on my archlinux box because there is a problem with the boost graph library. ;) Is this known? Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Marcel Wiesweg
On 18.04.2012 21:20 schrieb Marcel Wiesweg:
> >> I tried to debug this further. What I can see is that if I manually >> query the database with the same query digikam uses, all relevant images >> are returned. So I suspect the database is ok. So the images must be >> swallowed at some later time. Has anyone got some idea how to find out >> where they disappear in the long model-view chain? > > The immediate entry point from the ioslave is ImageAlbumModel::slotData() > The place where entries are actually added to the model, with beginInsertRows > etc., is ImageModel::publiciseInfos(). > Filtering is done in ImageFilterModelFilterer::process(), for optimization > three different code paths are written out, the relevant line is always > package.filterResults[info.id()] = ... (the result is cached) > > These key points should give a hint where your images are lost modifications directly from their package... Anyway, what happens is that the localVersionFilter rejects most of the images even though I have versioning completely switched off. Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
On 18.04.2012 23:23 schrieb Johannes Wienke:
> On 18.04.2012 21:20 schrieb Marcel Wiesweg: >> >>> I tried to debug this further. What I can see is that if I manually >>> query the database with the same query digikam uses, all relevant images >>> are returned. So I suspect the database is ok. So the images must be >>> swallowed at some later time. Has anyone got some idea how to find out >>> where they disappear in the long model-view chain? >> >> The immediate entry point from the ioslave is ImageAlbumModel::slotData() >> The place where entries are actually added to the model, with beginInsertRows >> etc., is ImageModel::publiciseInfos(). >> Filtering is done in ImageFilterModelFilterer::process(), for optimization >> three different code paths are written out, the relevant line is always >> package.filterResults[info.id()] = ... (the result is cached) >> >> These key points should give a hint where your images are lost > > I could compile trunk. 2.5 did not work even with the archlinux > modifications directly from their package... > > Anyway, what happens is that the localVersionFilter rejects most of the > images even though I have versioning completely switched off. tagId 874 assigned, which is "Original Version". This probably happened because I processed them using the batch queue manager. 1. Is it wanted that this tag is assigned even if versioning is switched off? 2. The localVersionFilter has 874 and 875 in its exclude list. Is this wanted in this case or should the exclude list simply be empty in case versioning is switched off? Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Hey again,
On 18.04.2012 23:44 schrieb Johannes Wienke: > Ok, some further observations. The images which are filtered out have > tagId 874 assigned, which is "Original Version". This probably happened > because I processed them using the batch queue manager. > > 1. Is it wanted that this tag is assigned even if versioning is switched > off? > > 2. The localVersionFilter has 874 and 875 in its exclude list. Is this > wanted in this case or should the exclude list simply be empty in case > versioning is switched off? patch to disable version filtering completely when versioning is switched off. Do you think this is reasonable? Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Why not to attach your patch to bug #298380 ?
Gilles Caulier Le 18 avril 2012 23:58, Johannes Wienke <[hidden email]> a écrit : > Hey again, > > On 18.04.2012 23:44 schrieb Johannes Wienke: >> Ok, some further observations. The images which are filtered out have >> tagId 874 assigned, which is "Original Version". This probably happened >> because I processed them using the batch queue manager. >> >> 1. Is it wanted that this tag is assigned even if versioning is switched >> off? >> >> 2. The localVersionFilter has 874 and 875 in its exclude list. Is this >> wanted in this case or should the exclude list simply be empty in case >> versioning is switched off? > > Last spam for tonigh. ;) Regardless of issue 1 I propose the attached > patch to disable version filtering completely when versioning is > switched off. Do you think this is reasonable? > > Johannes > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Am 19.04.2012 07:22 schrieb Gilles Caulier:
> Why not to attach your patch to bug #298380 ? That bug is about the UI, which is not directly related to the error in the filtering process. Cheers, Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Johannes Wienke
> Last spam for tonigh. ;) Regardless of issue 1 I propose the attached > patch to disable version filtering completely when versioning is > switched off. Do you think this is reasonable? Sounds quite reasonable...push if you like _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
