It looks to me like like I am experiencing the same problem described in this post.
However, my circumstances may differ. I have no such problem when using DT V3.8.1, which I’m running on Windows 7. I just installed DT 4.0.1 and that is where it happens. Thankfully, I run DT in a portable fashion. Therefore, my 4.0.1 installation makes no changes to the 3.8.1 installation. This allows me to simply abandon the 4.0.1 installation until it gets replaced with something that works and continue using 3.8.1.
Also, in my workflow the exported files get placed in the same folder as the related raw file and sidecar file. Therefore, I use the folder selection dialogue which, I think, means none of the issues pertaining to file naming apply. However, it does appear as though the export process continues to run indefinitely and the only way I’ve been able to end it is by logging out.
Also, my reading of the referenced post leaves me thinking that NO resolution was reported for the problem. DT version information unknown for that post. Possibly it also applies to DT 4.0.1.
Where are you trying to save things… any issue with permissions… if the syntax is correct I am not aware of any issues. At least I have not had any of that nature running Windows 10 and now 11 for some time??
Well now, my portable method of running DT makes it very easy to take it to a Windows 10 computer and try it there. The export operation, trial using same files as on Windows 7, functioned correctly.
Insofar as my only motive for migrating to the new version was staying up to date it looks like I’m now stuck with DT 3.8.1. In that, I do prefer Windows 7 which in my case is running on a custom made computer that is quite a bit more powerful than my Windows 10 computer. So far no compelling reason for using DT Version 4. Given that the developing operations appear to work fine on Windows 7 I can opt to use it if desired and only need to go to Windows 10 for export capability. Of course with more use there may be more problems of this kind that arise.
I suspect this defect is NOT intended but rather only a consequence of NOT testing on Windows 7.
Yes, but that only means Microsoft no longer provides support. I don’t think Microsoft has ever provided support for Darktable.
Microsoft’s big mistake is thinking that an OS that runs on a phone is also going to be satisfactory for a computer. I only use Windows on a computer. I had to build my own in order to upgrade with parts that still work with Windows 7, which is a much better OS for computers than Microsoft’s newer operating systems.
There are alternatives to Darktable for use on Windows but there is no good alternative to Windows 7. At least for me!
From the link above, “As of January 14, 2020, PCs running Windows 7 no longer receive security updates.” I happen to agree that Win 7 was a better OS than Win 10 or 11, but Windows is the target of choice for hackers and I wouldn’t want to be running a Windows OS that has gone almost three years without security updates unless the machine is airgapped.
Yeah but it means that nobody has been testing darktable on windows 7 for two years. That like four releases. It also means that any fixes for issues on windows 7 will likely be coincidental.
As far as I know when an operating system reach that point, 3rd parties usually do the same (or at least limit the support to the minimum to finally finish with it).
Do not get me wrong, if it gets fixed much better.
Yep. Three years ago at work we were wrapping up Search & Destroy missions on the (hopefully) last Windows 7 workstations on the network. But on a ~1500 node network (part of it acquired intact) with remote locations, vendor-installed / SCADA machines, etc., there were lots of places to hide. Getting rid of Server 2008 wasn’t nearly as “easy”. I retired in May 2021 and I bet there are still some around.
I remember to have heard recent stories about there still being installations of WIndows 3.11 around (and in use, not just as museum pieces). Not networked, thankfully… There are some situations where replacing the OS (or the computer, for that matter) just isn’t in the budget.
E.g. university labs have a tendency to use machines until they fall apart from old age, if the research labs don’t use the machines anymore, student labs are interested. This mostly concerns computers attached to other equipment, preferably through a proprietary interface, which of course isn’t produced anymore. But the other equipment still works perfectly, so the computer will have to manage…
And to be fair, such older equipment can be much more useful for teaching than modern “black box” equipment.
Back probably around 2010 or so a co-worker of mine happened upon a dusty old desktop computer (with maybe a 13" CRT on it) sitting in the corner of an unused office in our accounts receivable department. He noticed it was running and asked what it was. The reply, “Oh that’s VERY important! We get information from our bank on that machine. Without it, we can’t accept any customer payments.” It had a modem, a phone wire and was running DOS 3.3, IIRC… Yikes!! We couldn’t replace it immediately but we did virtualize it (that very day) and get a backup of the VM image… It had been there literally for decades, totally unknown to IT. Ouch.
I think it might be fair to say that when it comes to programmable equipment all of this is the nature of the beast. As it happens I am most grateful that there are programmers interested in developing useful software and sharing it with others. The open source approach is terrific.
Interestingly, I think Darktable is primarily developed for the Linux platform and figuring out how to also run it on Windows might be considered an afterthought. I don’t really know much about how that is done but I imagine the Darktable developers are relying on some other open source software to provide the Windows capability. I do have computers running Linux, which I do like, but they are even older (still only 32 bit). I tried but could NOT install Darktable there.
The thing I’ve come to like a great deal about Windows is it’s ability to run applications in portable fashion (e.g., https://portableapps.com/). As it turns out portability is NOT what I see as the primary benefit. It is rather the the idea of keeping the application software independent from the system it is running on. For example, Windows is notorious for breaking partly because of being “the target of choice” but also because it is constantly being changed for all manner of reasons. When it comes to Windows it is Windows 7 that has also become very stable in this respect. The solution for such breakage is to change to another instance of Windows that isn’t broken. All of my computers (both Linux and Windows based) use something called multiboot for installing several instances of the OS on each computer. Then when the OS breaks you simple reboot a different instance. Figuring out what broke takes time and effort which can be avoided by simply restoring a master copy of the OS which is kept offline and therefore quite difficult for hackers to target. Windows 7 has become very good in this respect because the master copy does NOT need to be updated as often.
While the referenced site provides a multitude of different applications that run on its’ platform there are things, like Darktable, that are missing. Therefore, I’ve developed my own method of installing applications in a portable fashion. My method allows new releases to be installed without changing prior versions. The same can be done on the Portable Apps Platform but requires a little knowledge and customization. Therefore, you always have the option of easily returning to a prior release when the new one is NOT ready (for prime time so to speak).
If Darktable really wants to be available to Windows users I’d, strongly, recommend adapting to the the Portable Apps Platform.
Unfortunately, as best I can tell, the Linux design is antithetical to the notion of portability (i.e., independence from the system used to run the applications).
The community provides the windows and macOS build, the project lists them on github as a convenience to end users. The project itself is really only concerned with releasing the source code. If the community wants portable apps, it is free to do so.
Most Linux distros prefer the shared library method, which is what I think you’re referring to. But there are also appimages and flatpaks and statically compiled binaries. Its just that less linux users prefer those.
I suspect that nobody cares but I thought I should add some more findings regarding this issue. While I haven’t done any more processing with DT 4.0.1 I do now have additional experience with both DT 4.2.1 and 4.4.1.
It presently appears as though the problem continues to exist with DT 4.2.1 but has been solved by DT 4.4.1. This is a minor problem for me because I would still like to use DT 4.2.1 because of modules that have been deprecated in DT 4.4.1.
More significantly I have now determined that the problem, at least in DT 4.2.1, is NOT universal. It only occurs when trying to export files produced by one of my several cameras. The export works just fine on files produced by, at least, 2 of my cameras. The camera that fails is a Canon 5DsR which does have a 50 megapixel sensor and thus does produce images that are quite large.
It might also be worth mentioning that my experience with Darktable is based on the Windows version which I use on Windows 7 computers. In that, I’d now say that this problem has nothing to do with Windows 7.
I’ve known the module is still there because DT 4.4.1 is able to correctly apply a .xmp file created by a prior release. Also, I do use a custom preset but the deprecated module does NOT show up on the list from which I can select the modules to include in the various groups. Sounds like there is something about presets I’m failing to understand. What might that be?