excluding files from database?

[Arnd Baecker]

Hi,

is there a way to prevent files from being included in the database?

I would like to add additional information/notes/... within
the image folders (for example like *.txt, *.html, *.gpx,
*.kml, *.pto, ... files).
Presently they get included in the database
and lead to messages like

  Cannot load metadata using Exiv2
  (/home/fotos/Pictures/2007/2007_04_a/tst.gpx: The file contains
  data of an unknown image type)

If there is no way to exclude  files presently, would
something like an additional point

  "Ignore files matching"
  *.gpx, ...

in the MIME Types configururation of digikam be possible?

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

I agree with this logic. Why include all file from HDD is we manage only file types registered into Mime Types setup.

 

Why add a new settings to exclude file types ??? If the database only manage the file registered in mime types setup, it's can be enough...

 

Marcel, what do you think about ? This way ca be done in your new DB consolidation implementation for next 0.10 release ?

 

Gilles

 

2007/4/24, Arnd Baecker <[hidden email]>:

Hi,

is there a way to prevent files from being included in the database?

I would like to add additional information/notes/... within
the image folders (for example like *.txt, *.html, *.gpx,
*.kml, *.pto, ... files).
Presently they get included in the database
and lead to messages like

Cannot load metadata using Exiv2
(/home/fotos/Pictures/2007/2007_04_a/tst.gpx: The file contains
data of an unknown image type)

If there is no way to exclude  files presently, would
something like an additional point

"Ignore files matching"
*.gpx, ...

in the MIME Types configururation of digikam be possible?

Best, Arnd
_______________________________________________
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

[Fabien-5]

Gilles Caulier wrote:
> I agree with this logic. Why include all file from HDD is we manage only
> file types registered into Mime Types setup.
>  
> Why add a new settings to exclude file types ??? If the database only
> manage the file registered in mime types setup, it can be enough...

I agree :)

--
Fabien

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> I agree with this logic. Why include all file from HDD is we manage only
> file types registered into Mime Types setup.
>
> Why add a new settings to exclude file types ??? If the database only
> manage the file registered in mime types setup, it's can be enough...
>
> Marcel, what do you think about ? This way ca be done in your new DB
> consolidation implementation for next 0.10 release ?
>

Yes sure it can be done. I will try to find an elegant solution...

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

On Thu, 26 Apr 2007, Marcel Wiesweg wrote:

> > I agree with this logic. Why include all file from HDD is we manage only
> > file types registered into Mime Types setup.
> >
> > Why add a new settings to exclude file types ??? If the database only
> > manage the file registered in mime types setup, it's can be enough...


Gilles, you are of course absolutely right - a new settings
is not necessary at all!

> > Marcel, what do you think about ? This way ca be done in your new DB
> > consolidation implementation for next 0.10 release ?
> >
>
> Yes sure it can be done. I will try to find an elegant solution...

Just wondering: couldn't one just completely ignore files
whose (lower-case) extension is not included in any of
the listed Mime Types?
This would be possible already now and imply no change
in the database.

Only for files which are already in the database
(and not listed in the Mime Types) it would mean that
they just stay in the database
(which would be no real problem, I think ...)

Maybe one could write a simple clean-up script
to remove them from the data-base
(if the above makes sense I could give this a try;
it shouldn't be really difficult ...)

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > Yes sure it can be done. I will try to find an elegant solution...
>
> Just wondering: couldn't one just completely ignore files
> whose (lower-case) extension is not included in any of
> the listed Mime Types?
> This would be possible already now and imply no change
> in the database.
>
> Only for files which are already in the database
> (and not listed in the Mime Types) it would mean that
> they just stay in the database
> (which would be no real problem, I think ...)
>
> Maybe one could write a simple clean-up script
> to remove them from the data-base
> (if the above makes sense I could give this a try;
> it shouldn't be really difficult ...)

In the current situation, any file is inserted in the DB, and only when
reading from the db, files are filtered by filename.
It is of course easy to do the filtering when inserting into the DB. After the
initial scanning at startup, new files will be added and files which do no
longer belong to the mime type list are removed. This also solves the problem
with wrong album high/low/mean dates.

I see one major problem here:
A user might by chance or misunderstanding remove e.g. ".jpg" from the
mimetype list. Suddely all his photos are gone, which is no problem they can
be rescanned. But all tags and ratings are lost!! (unless written to file -
assume it is not).

We need to prevent this.
One possibility is a hardcoded list of image formats that are supported. I
cannot see any indication for removing .jpg from the mime type list.
Hm difficult. A positive list of added formats, a negative list? Or keep it as
it is, develop another approach?

Marcel

>
> Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2007/4/30, Marcel Wiesweg <[hidden email]>:

> > Yes sure it can be done. I will try to find an elegant solution...

>
> Just wondering: couldn't one just completely ignore files
> whose (lower-case) extension is not included in any of
> the listed Mime Types?
> This would be possible already now and imply no change
> in the database.
>
> Only for files which are already in the database
> (and not listed in the Mime Types) it would mean that
> they just stay in the database
> (which would be no real problem, I think ...)
>
> Maybe one could write a simple clean-up script

> to remove them from the data-base
> (if the above makes sense I could give this a try;
> it shouldn't be really difficult ...)

In the current situation, any file is inserted in the DB, and only when
reading from the db, files are filtered by filename.
It is of course easy to do the filtering when inserting into the DB. After the
initial scanning at startup, new files will be added and files which do no
longer belong to the mime type list are removed. This also solves the problem
with wrong album high/low/mean dates.

I see one major problem here:
A user might by chance or misunderstanding remove e.g. ".jpg" from the
mimetype list. Suddely all his photos are gone, which is no problem they can
be rescanned. But all tags and ratings are lost!! (unless written to file -
assume it is not).

We need to prevent this.
One possibility is a hardcoded list of image formats that are supported. I
cannot see any indication for removing .jpg from the mime type list.
Hm difficult. A positive list of added formats, a negative list? Or keep it as
it is, develop another approach?

 

Right Marcel. And this problem is not relevant of JPEG files only. RAW files for example can be tagged intensivly. For example i have an huge tagged collection of MRW files on my main computer...

 

Why not to ping users with a confirm dialog when the users change something in type mime dialog ?

 

About mimie type stuff, i have found a problem with cameragui when a new file typemime is detected, for ex., when you download an unregistered video file type in album collection, the mime type will always set automaticly in _Image_ mime type list. Nothing is ask to user about how to register the new mime type (image, video, audio, or RAW).

 

Gilles

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

On Mon, 30 Apr 2007, Gilles Caulier wrote:

> 2007/4/30, Marcel Wiesweg <[hidden email]>:

[...]

> > In the current situation, any file is inserted in the DB, and only when
> > reading from the db, files are filtered by filename.
> > It is of course easy to do the filtering when inserting into the DB.

Yes, that's what I was thinking of.

> > After the
> > initial scanning at startup, new files will be added and files which do no
> > longer belong to the mime type list are removed.

Removed = removed from the database, right?

> > This also solves the problem
> > with wrong album high/low/mean dates.

Oh, that would be very good, indeed!

> > I see one major problem here:
> > A user might by chance or misunderstanding remove e.g. ".jpg" from the
> > mimetype list. Suddely all his photos are gone, which is no problem they
> > can
> > be rescanned. But all tags and ratings are lost!! (unless written to file
> > -
> > assume it is not).

[...]

> > We need to prevent this.
> > One possibility is a hardcoded list of image formats that are supported. I
> > cannot see any indication for removing .jpg from the mime type list.
> > Hm difficult. A positive list of added formats, a negative list? Or keep
> > it as
> > it is, develop another approach?
>
>
> Right Marcel. And this problem is not relevant of JPEG files only. RAW files
> for example can be tagged intensivly. For example i have an huge tagged
> collection of MRW files on my main computer...
>
> Why not to ping users with a confirm dialog when the users change something
> in type mime dialog ?

That sounds like a good solution!
A very very clear warning, if one of the removed files types
is presently in the database, should do the job.

Best, Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

Hi,

Marcel/Gilles: should I file a B.K.O entry on this before it completely
falls through the cracks?

Best, Arn

On Mon, 30 Apr 2007, Arnd Baecker wrote:

>
>
> On Thu, 26 Apr 2007, Marcel Wiesweg wrote:
>
> > > I agree with this logic. Why include all file from HDD is we manage only
> > > file types registered into Mime Types setup.
> > >
> > > Why add a new settings to exclude file types ??? If the database only
> > > manage the file registered in mime types setup, it's can be enough...
>
>
> Gilles, you are of course absolutely right - a new settings
> is not necessary at all!
>
> > > Marcel, what do you think about ? This way ca be done in your new DB
> > > consolidation implementation for next 0.10 release ?
> > >
> >
> > Yes sure it can be done. I will try to find an elegant solution...
>
> Just wondering: couldn't one just completely ignore files
> whose (lower-case) extension is not included in any of
> the listed Mime Types?
> This would be possible already now and imply no change
> in the database.
>
> Only for files which are already in the database
> (and not listed in the Mime Types) it would mean that
> they just stay in the database
> (which would be no real problem, I think ...)
>
> Maybe one could write a simple clean-up script
> to remove them from the data-base
> (if the above makes sense I could give this a try;
> it shouldn't be really difficult ...)
>
> Best, Arnd
> _______________________________________________
> 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

[Gilles Caulier-4]

Perhaps there is already one...

Gilles

2007/5/11, Arnd Baecker <[hidden email]>:

Hi,

Marcel/Gilles: should I file a B.K.O entry on this before it completely
falls through the cracks?

Best, Arn

On Mon, 30 Apr 2007, Arnd Baecker wrote:

>
>
> On Thu, 26 Apr 2007, Marcel Wiesweg wrote:
>
> > > I agree with this logic. Why include all file from HDD is we manage only
> > > file types registered into Mime Types setup.
> > >
> > > Why add a new settings to exclude file types ??? If the database only
> > > manage the file registered in mime types setup, it's can be enough...
>
>
> Gilles, you are of course absolutely right - a new settings
> is not necessary at all!
>

> > > Marcel, what do you think about ? This way ca be done in your new DB

> > > consolidation implementation for next 0.10 release ?
> > >
> >
> > Yes sure it can be done. I will try to find an elegant solution...
>
> Just wondering: couldn't one just completely ignore files
> whose (lower-case) extension is not included in any of
> the listed Mime Types?
> This would be possible already now and imply no change
> in the database.
>
> Only for files which are already in the database
> (and not listed in the Mime Types) it would mean that
> they just stay in the database
> (which would be no real problem, I think ...)
>
> Maybe one could write a simple clean-up script
> to remove them from the data-base
> (if the above makes sense I could give this a try;
> it shouldn't be really difficult ...)
>
> Best, Arnd
> _______________________________________________
> 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

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel