XnView Software

XnView MP 0.96.4 64bits
Windows 7 Pro 64bits

I use Descript.ion files a lot for tagging because old as it is, it's still a viable means to use that tagging info across different programs (I even have an old ACDsee 3.1 in use for exactly that reason)

When using the search function to select a batch of files in different subdirectories and trying to batch-change their comment(s) (write all, only in the descript.ion files, not embedded), the search result shows the comments/ annotations correctly changed, but if you do the same search again, some of the files will show up with the old comments/ annotations.

It seems to depend on the specific subdirectory the files are located, as some directories seem to be updated correctly, others are not.

every single subdirectory in question has a descript.ion file and every file in there has an entry in the descript.ion with an "old" comment/ annotation.
none of the descript.ion files have hidden, system or read-only attributes set.

if I manually enter the problematic subdirectories, batch-changing the comments/ annotations works correctly and sticks, the issue only seems to come up when trying to do so from a result window of a search (didn't try it with quick search) - the problematic directories are always the same ones and no path exceeds any size restriction (i.e. length of the path including the filename of the descript.ion file is well within the limits of what windows 7 permits).

So far I have use only XnView Classic and I only tried out XnView MP for a couple of days now, so I can't tell if that's an old issue or one of the current release.

And btw: thank you for the excellent work - so far I have only found a very few minor possible improvements in XnView MP which would belong in different channel.

Edit for additional info: a lot of the original Descript.ion files have been created by ACDsee, which means that with ACDsee being notoriously bad at housekeeping these files, it's possible there are entries in the Descript.ion files referencing files that do not exist anymore, as well as the order of files in the Descript.ion file follows no strict rule like alphanumeric sorting or similar - dunno if either might matter.

Do you have a way to reproduce?

first of all, thanks for your attention

I'm not actually sure how to reply to that as the effect described above happens to me if not all then certainly most of the time.

For a long time I mostly used an old version of ACDsee to maintain these (descript.ion) comments without any such problems, but for pretty obvious reason I'd really love to use XnView MP instead as the latter is far superior in many ways than the heavily outdated ACDsee I'm using.

I'll try to set up a scenario that easily reproduces the problem while being easily reproducible by other users but I can't tell how long that'll take for it isn't really clear to me what the underlying problem actually is.
...beyond the fact that changes done and correctly showed in the search result window of XnView MP don't really sync with the content of (all) the affected descript.ion files, for if you repeat the same search again resulting in exactly the same files, some of the comments you just had changed (and which showed changed in the search result window) reverted back to their original content again - as if XnView MP didn't correctly sync the changes made to (some of) the descript.ion files.

So far if I just entered a directory (not using the search) and change the comments on a number of files it seems to work flawlessly with the single descript.ion file in that specific directory, but whenever there are more than one descript.ion file affected and have to be updated (as on a selection of files from a search result including subdirectories) it becomes unreliable while (up to now) there doesn't seem to be any obvious pattern why it works correctly on some of the affected directories/ descript.ion files while it doesn't on others. Manually changing into these directories and changing the comments works, and (I have to check that to be certain) I seem to remember that even entering the directory and selecting files by searching there (without recursing into subdirectories) and changing works too, as long as there's only one single descript.ion file affected.

I got the impression there's a glitch somewhere in the code updating the changes made to the descript.ion files whenever there is more than one single descript.ion file affected.

Thanks to your detailed description I can reproduce the problem.

my apologies for not sufficiently describing what I referred to on the first go.

I really look forward to the chance of this getting fixed because to me using the descript.ion files is a very important feature.

It's a means of attaching all kinds of information to pictures or videos without changing the original files (by adding or changing any embedded information) and at the same time it's portable, i.e. not limited to a certain software or instance of that software (by putting that information into the software specific database) and can easily be copied/ transferred to other locations or computers.

I was sad to see the support of descript.ion files going from ACDsee at IIRC ver. 4.x and the more happy to find a decent alternative when I first stumbled over XnView (classic version) years ago before even XnView MP came along.

If I understood you correctly you were able to reproduce the scenario, hence I put on hold trying to setup one easily reproducible scenario myself for the time being unless or until you tell me to do otherwise.

and again, thanks for the attention

This problem is supposed to be fixed in XnView MP 0.96.5. Please check and confirm the bug fix here.

Sorry for being a bit slow in replying but I'm currently in the process of migrating to a new computer, including getting used to a new operating system (win 7 -> win 10).

First of all: thanks for the effort.

Preliminary (and so far very quick and superficial) checking seems to indicate the problem is fixed, unfortunately there seems to be a new problem now I'm not yet sure I can make out exactly: trying to do the update process as described in the original posting (i.e. selecting files in a directory tree with subdirectories and changing their annotation/ comment) now has XnView MP crashing.

So far I got the vague impression it's a matter of either number of files or number of directories affected, but I didn't have time yet to find out any specifics.

What I can tell is this, and it's 100% reproduceable for me:
- enter a dir with 5 subdirs, some have subdirs with up to 6 branches deep, other none at all
- start a simple find to get ALL files (result shows a list of all IMAGES, as far as I can tell the DESCRIPT.ION are not selected/ in the resulting list)
- select all 40'000+ files and try to change the comment (only in the .ION files, not the embedded ones)
- process starts and after a few seconds the program crashes

Checking the descriptions by using above mentioned search/ find again shows a number of comments were changed before the program crashed
Manually entering the subdirs (without search), selecting all files and changing the comments seems to work without an issue.

The first check that indicated that you fixed something were inside the same directory structure but at a branch with much less files affected and only 2-3 subdirs, and that seemed to have performed flawless.

Sorry for being somewhat reluctant to send the crashdumps, but SOME of the comments, file names, directory names and content are a matter of privacy, not just mine but other peoples' too - and not knowing what data is sent I didn't send the crashdumps.

I'll try to reproduce it on a more "neutral" set of images and send the crashdumps when I'll find time.

Devil505 wrote: Tue Aug 25, 2020 2:21 am I'll try to reproduce it on a more "neutral" set of images and send the crashdumps when I'll find time.

Do you have tried to reproduce with 0.97.0?