[0.93b1] Move to not working

[jadO]

Again and again, move to via context menu is not working.
Error message: Can't remove source. However file gets created in destination directory. But not removed from the source. So it is creating duplicates.

Edit: And still categories and color labels get removed on move also via drag and drop. It is unusable this way.

[xnview]

Again and again, move to via context menu is not working.
Error message: Can't remove source. However file gets created in destination directory. But not removed from the source. So it is creating duplicates.

Is it a new bug? Could you tell me how to reproduce? Windows?

[jadO]

Is it a new bug?

It's not a new bug. I have reported it 2 times already here and here.

[jadO]

This seems to be a weird bug and not present at all times.
Also it seems that XnvieMP does not correctly handle assigned categories and ratings when moving.
Here is what happened:
1. Move file to other folder via context menu.
2. When prompted that source cannot be removed skip.
3. Check in destination folder, chances are that there is the file that should have been moved without any ratings or categories now.
4. Now move the original file again and choose overwrite.
5. Check destination folder. Chances are that the file still has no categories or ratings assigned althoug it has been overwritten thus the old file is no longer present.
6. Move the file back to old source folder, in that folder chances are that the file is shown with ratings and categories again.

This behavior is somewhat shocking. It means that somehow XnviewMP stores ratings and categories even after a file has been moved. So they depend on the folder a file is in and not on the file itself. This can lead to totally wrong display on category results or even erroneous deletion of files.

Edit: It seems that similar issues have been reported with previous versions: viewtopic.php?f=82&t=34069&hilit=rating#p135796

[xnview]

This seems to be a weird bug and not present at all times.
Also it seems that XnvieMP does not correctly handle assigned categories and ratings when moving.

Please send me your xnview.ini?

[jadO]

This seems to be a weird bug and not present at all times.
Also it seems that XnvieMP does not correctly handle assigned categories and ratings when moving.

Please send me your xnview.ini?

It's not a matter of the xnview.ini. I have just tried with a completely new XnviewMP portable setup and it shows exactly the same problem as described.

[xnview]

It's not a matter of the xnview.ini. I have just tried with a completely new XnviewMP portable setup and it shows exactly the same problem as described.

which windows?

[jadO]

It's not a matter of the xnview.ini. I have just tried with a completely new XnviewMP portable setup and it shows exactly the same problem as described.

which windows?

Windows 8.1 64bit

[xnview]

and which format do you move? i have no problem

[jadO]

and which format do you move? i have no problem

Just tested with flv, webm, 3gp, mp4, so it is pretty much any format I guess.

[xnview]

oh ok, video files, i have tested with image files!

[wnicnz]

While you're looking at this problem, this may be related, introduced in 0.93:
previous versions, "Move to" moved the file and then selected the NEXT file in the list. Now it seems to move to PREVIOUS file . I don't have a lot of time to look into this right now, but I'll try and explain.
My use case, I'm reviewing a set of pictures, some of which I want moved to another folders. So I view (fullscreen) file 001, then 002, 003, 004 ... decide I want to move 004, so move it. XnviewMP shows me 003 again (but the next file to examine is 005).
In browser mode, it looks like the (previous) file is half-selected ie the highlight colour is pale.
If multiple files are selected, same thing, eg if I have 001 to 010.jpg; select #6 and #7 and move, then after the move, the current file is #5 (expected: #8)
Linux / KDE (Kubuntu 18.10)
Hope this helps!

[wnicnz]

Further to my previous comment: Looks like the Move / select previous-instead-of-next behaviour started in 0.91 .. I had to downgrade to 0.90 to get the old behaviour back.
Apologies for a second unmoderated post in wrong thread- I thought you'd appreciate bug report more than not, feel free to move this to another thread if possible

[xnview]

Thanks to your detailed description I can reproduce the problem.

[Jubelbube]

A solution with disadvantage:
Settings / File list / Custom Filter / in "Video" column deactivate "Show in Preview"

The disadvantage: No Video-Preview in XNview, only with external viewer.

The XNview-People are smart. It would be great if they could fix this disadvantage, too.