program freezes during copy/move operation

[kzr]

Hi, I registered to tell you about this. Maybe it's my fault and not really a bug, but ever since I updated to 1.3.0, the program will often freeze when I use internal copy/move functions. these freezes go well over 10 seconds and it doesn't really matter how big the image is, how many files in source/destination folders, SSD, HDD, USB all act like this so it's not a bandwidth problem. also not a processing power issue (Intel Core i7) or RAM (24 GB). Catalog being on or of makes no difference whatsoever.

I use a dual screen setup, work with multiple instances of MP across both screens, no problem. until I need to copy or move files. I tested Window's own functions. boom! immediate! so for now the workaround is getting the Windows copy to/move to .reg files from the web, ctrl+click a file and use those instead. Of course, without the benefits of XN, but without wait as well, which translates into more productivity at work at the cost of extra steps.

I don't want to stop using MP. I've used other image viewers/managers in the past, but none suits my workflow better. If I can somehow help you let me know

[xnview]

you have the freeze when copy/move starts?

[kzr]

exactly. then it moves normally

[xnview]

so a freeze after pressing 'Move' button on 'Copy/Move dialog', right? Even on 1 file?

[kzr]

yes. select the files, right click and select copy or move. it freezes right there. copy dialog works fine after it actually starts copying hangs a bit here and there but justified and not like this.

on rare occasions the freeze doesn't happen. it also doesn't happen with drag/drop ops

while using a completely unrelated problem I ran into a similar issue. FL Studio, a very well known audio production program, lets you pick a set of folders to be always available in the internal browser. one of these folders is in the network. when the machine is off it takes about one extra minute to parse the folder list, likely because of waiting for a response packet, and subsequently for the timeout. This happens every time the browser refreshes, after that the file list is stored in memory and only refreshes if forced by the user or app . Could it be that XN is waiting for network folders, albeit with a shorter timeout?

I have this PC set up as a multimedia production center. not only do I have folders with several thousands of items, I have quite a few spread over the network, possibly slowing everything down if folder contents are probed/listed before every file operation. just a veteran's hunch, you're certainly more knowledgeable about the inner workings of your own software.

[xnview]

yes. select the files, right click and select copy or move. it freezes right there. copy dialog works fine after it actually starts copying hangs a bit here and there but justified and not like this.

Do you have a lot of files in this folder?

while using a completely unrelated problem I ran into a similar issue. FL Studio, a very well known audio production program, lets you pick a set of folders to be always available in the internal browser. one of these folders is in the network. when the machine is off it takes about one extra minute to parse the folder list, likely because of waiting for a response packet, and subsequently for the timeout. This happens every time the browser refreshes, after that the file list is stored in memory and only refreshes if forced by the user or app . Could it be that XN is waiting for network folders, albeit with a shorter timeout?

I don't think

[kzr]

the number of files in the folder makes no difference. i tried a big folder and I tried one file.

I'll try doing the same when the other machines in the network are on just to make sure.

[kzr]

I have confirmed it is the network slowing down the process. Since all machines are accessible the lag disappeared and every file copies/moves normally.

[kzr]

after some extensive testing I figured out the problem and it affects a lot of apps on windows.

network drives, if the host is inaccessible they cause the delay. removing all network drives solved the issue and this is therefore not an XNView bug.