Hi Jack,
I drift slightly off topic and you can either ignore my post if it is
unhelpful, but please don't abuse me for getting off topic. I do a lot of
photo restoration with dust, scratches and other marks. DT is great for a
couple of spots from a dirty image sensor or some specialised restoration
issues, but the better FOSS program for removing dust as you describe is
GIMP. Your system will have no issues then and you can spot at F1 racing
speed. I hope this tip is helpful. Good luck.
On Sat, 22 Oct 2022 at 04:38, Jack Bowling <jbi...@shaw.ca> wrote:
> There is one gotcha I found recently. I was developing some film when it
> slipped out of my hand and hit the floor. Even with a re-wash, the film
> ended up with many dust spots and crap I had to spot out with the
> retouch module. Then I found that the systemd-oomd module on my Ubuntu
> box is way too sensitive, such that if you cleaned up spots too fast, it
> would kill darktable unmercifully. I have a Ryzen 3900X (12 cores, 24
> threads) with 64G of ram so it is not a weak box. Thus, I found that the
> only way to ensure that dt would not crash and lose all the retouch work
> was to: 1) spot more slowly; 2) "save" my work more frequently by
> compressing the history stack; and 3) masking the systemd-oomd module
> entirely to get it out of the way (I don't miss it).
>
> Of course, the lesson here is to be more careful in the darkroom and
> better procedures have been adopted.
>
> Jack
>
> On 2022-10-21 05:28, Michael Staats wrote:
> > On 21/10/2022 10:27, Paul Marfell wrote:
> >> I don't want my system slowed down just because there might sometime be
> >> a crash but it would seem sensible to set a flag in the dB when dt
> >> starts and unset it when it shuts down normally. If the flag is set when
> >> dt starts then it can run some checks or just warn the user.
> >>
> >> Paul
> >
> > This "slowdown" would be absolutely neglegible, compared to the risk of
> > having never ending DB transactions (until you termintate dt gracefully).
> > But we already learned that this is not the case. dt commits the db
> > transactions if you move to the next picture. This is absolutely
> > resonable. Everything else would be asking for trouble.
> > Even an fsync() might make sense, after the commit.
> >
> > This limits the loss of information to one picture max, be it in the DB
> > or in the xmp. Unless your "crash" breaks your file system, then you are
> > lost. So just avoid crashes.
> >
> > Best regards,
> > Michael
> >
> > --
> > Michael Staats
> > michael.sta...@gmx.de
> >
> >
> ____________________________________________________________________________
>
> >
> > darktable user mailing list
> > to unsubscribe send a mail to
> > darktable-user+unsubscr...@lists.darktable.org
> >
>
> ____________________________________________________________________________
> darktable user mailing list
> to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>
>
--
Terry Pinfold
Photography & Imaging Tutor
Hobart, Tasmania, Australia
Ph 0408 699053
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
