<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 26 janv. 2022 à 09:30, frederic chaume <<a href="mailto:frederic.chaume@gmail.com">frederic.chaume@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">thanks all for your feedback, so seems straightforward now , good news<br>
<br>
Maik, I have 50 collections because I have 2 collections per year (since <br>
lat 25 years)  , one for the raw and one for the published jpg and I'm <br>
using different backup solutions for each<br>
Now I didn't think about the best strategy, when I start using DK, just <br>
started to create collections per year. What is the best or the most <br>
efficient or more performant ? more smaller collections or less bigger <br>
collections? is there any advice let me know I can think to revise my <br>
strategy<br></blockquote><div><br></div><div>We have never tested digiKam with a lot of collections like you.</div><div><br></div><div>But typically it must be fully transparent. If you don't find any time latency while searching items over all collections, well it's perfect.  <br></div><div><br></div><div>There is no perfect workflow. Each user setup collections as the best personal solution. You can set just one collection with all stored items in a specific album categorized by type of events, not by date, and use the calendar or the timeline tools to do the triaging for you.</div><div><br></div><div>Best</div><div><br></div><div>Gilles Caulier<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
regards<br>
<br>
Frederic<br>
<br>
<br>
Le 25/01/2022 à 22:12, Maik Qualmann a écrit :<br>
> And exactly this work on the database is no longer necessary with a current<br>
> digiKam version, since there is an "update" button in the collection. Why<br>
> frederic has 50 collections is a mystery to me, I wouldn't put each folder<br>
> branch in its own collection, but everyone has to know that for themselves.<br>
><br>
> Maik<br>
><br>
> Am Dienstag, 25. Januar 2022, 20:13:58 CET schrieb Ty Mayn:<br>
>> I am revived user low on the learning curve andbut I can respond to how I<br>
>> repaired a moved collection by going directly into the digikam4 data<br>
>> basefile.  I have no experience in using the migration tool but I did grab<br>
>> a 2 year old collection and  the files for digikam6 installation out of a<br>
>> backup location.  They had been living on an even older workstation hard<br>
>> drive  and I hoped that the collection would just operate by firing up the<br>
>> collection from a backup.   Digikam6 did fine to display the thumbnails for<br>
>> the identical recursive tree of folders and file images... but it could not<br>
>> deliver the full image preview.   I guess it could get to the thumbnails<br>
>> directly through the thumbnail database.<br>
>>        Not understanding the migration tool..I installed DB Browser and<br>
>> studied the database field called AlbumRoots<br>
>>   It has and identifier field and a path that allows the digikam display<br>
>> tools to fetch the proper full image .<br>
>>     If ound that the identifier retained in the digikam4 was pointing to a<br>
>> UUID  for the hard drive in the old workstation<br>
>> I had also moved the identically named folder and file collection under a<br>
>> new top level folder rather than root.<br>
>> The field titled "specificPath" perhaps should be titled "completePath"<br>
>> from root.<br>
>> To be safe I moved my identical folder collection to drive root  (where it<br>
>> had resided on earlier workstation) instead of trying to add the toplevel<br>
>> folder to the specific path<br>
>>        The format for the 2 fields  identifier  and specific path is<br>
>>     volumeid:?uuid=NewHexstring       /identicalFolderCollection<br>
>>    With those 2 fields set digikam happily treated the moved collection as a<br>
>> native home.<br>
>>        My post about this is on the inactive other digikam forum<br>
>> <a href="https://forum.kde.org/viewtopic.php?f=256&t=173758" rel="noreferrer" target="_blank">https://forum.kde.org/viewtopic.php?f=256&t=173758</a><br>
>>      I am a learner non programmer grasping for bits of info and I was<br>
>> relieved to find this direct way of repairing a collection and database<br>
>> which is identically positioned in a folder tree, but moved without advance<br>
>> planning.<br>
>>      I am sure the many helpers on this list  have addressed this structure<br>
>> in past postings,<br>
>>    but the info is buried in the past  until these email threads are<br>
>> gathered into a unified searchable document.<br>
>> Ty<br>
>><br>
>> On Tue, Jan 25, 2022 at 3:42 AM frederic chaume <<a href="mailto:frederic.chaume@gmail.com" target="_blank">frederic.chaume@gmail.com</a>><br>
>><br>
>> wrote:<br>
>>> Hi All<br>
>>><br>
>>> my current Disk is going to be out of sapce and I would like to move all<br>
>>> my collections (~50)  from current Disk to a new one.<br>
>>> Then I would like to know what is the best process to do it.<br>
>>> I see a refresh button for each collection in DK configuration, is it<br>
>>> then enough to choose the new location ? can we do it after having moved<br>
>>> the collections ?<br>
>>><br>
>>> FYI I'm using DK7.5<br>
>>><br>
>>> thanks for advices<br>
>>><br>
>>> frederic<br>
><br>
><br>
><br>
<br>
</blockquote></div></div>