Project

General

Profile

Feature #9181

Queueing for exports

Added by Richard Wonka over 7 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Lighttable
Target version:
Start date:
01/11/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When I export images it often happens that one export process is still busy while I have changed parameters and then start another export. (For example when I want different versions of the same image)

This seems to trigger another export running at the same time, which means I have, say four export threads running on two processors.

It would be nice if dt could finish one export job and then go on to the next one, finishing the jobs in sequence instead of in parallel, as this would allow me to start my work on the first product while the others are being exported. I think this may also badly affect memory usage.


Related issues

Related to darktable - Feature #9505: scheduled export queueNew07/11/2013

Associated revisions

Revision 6f2087f2 (diff)
Added by Tobias Ellinghaus almost 4 years ago

Fix #9181: only run one export at a time

History

#1 Updated by Christian iuga almost 7 years ago

I agree with this ticket, for me we should disable parallel export and queueing instend.

Specialy when using opencl, i don't think is working well with parallel export...

Also Using parallel export with CPU can make the OS or/and darktable freeeze or very slow (if it's not crashing due to memory missing or before crash using swap : very slow)

#2 Updated by Tobias Ellinghaus almost 7 years ago

  • % Done changed from 0 to 20
  • Target version set to Future
  • Status changed from New to Triaged

Parallel export has been removed from the GUI quite some time ago in 018e4f154e1d7e9f65e9941183921c5e72cfd87c. It might be that the actual code still exists and works when you set this in the config file manually. That being said, scheduling jobs for later processing might be a design criterion for our new scheduler (maybe using a 3rd list that contains jobs + time and is scanned every now and then).

#3 Updated by Robert Krawitz almost 4 years ago

This would be most useful for my workflow. I build quite a few panoramas, and my workflow is to put the files for each in a separate directory, in which I build the panorama. I also process non-panorama files, which I put in yet another directory. What I want to do is enqueue each set (collection in darktable) as I process it, and have a single queue that does the export of everything (as Hugin does for processing).

#4 Updated by Tobias Ellinghaus almost 4 years ago

  • System set to all
  • Affected Version set to git development version
  • % Done changed from 20 to 50
  • Status changed from Triaged to In Progress

#5 Updated by Tobias Ellinghaus almost 4 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

#6 Updated by Roman Lebedev over 3 years ago

  • Target version changed from Future to 2.2.0

Also available in: Atom PDF

Go to top