XnView: MP 1.3.1 - 64-bit
OS: Windows 10 - 64-bit
Renaming videos (I tested this with H.264 encoded MP4s, but the format probably doesn't matter) both in the viewer and in the browser produces the following error message if the video is already open in a tab, even if playback was never started:
To reproduce:
1. Uncheck "Auto play video" in Tools->Settings->Misc
2. Browse a folder with MP4 videos files.
3. Open tab for arbitrary video by double clicking it, but do not play the video
4. Try renaming the video (e.g. by pressing the default shortcut key F2) => Error
5. Change back to browser.
6. Try renaming the video by right-clicking the thumbnail (which is just an icon for me) )=> Error
Expected behaviour: Renaming should be possible both in the browser and in the viewer, even if the video file is open in a tab. As a bonus, the time stamps of the files should not be touched by the renaming process (could be the case already).
1.3.1.: Renaming videos produces error when video is open in tab
Moderators: helmut, XnTriq, xnview, Dreamer
Re: 1.3.1.: Renaming videos produces error when video is open in tab
you are able to reproduce each time?
Pierre.
Re: 1.3.1.: Renaming videos produces error when video is open in tab
Sorry, I missed the reply.
Yes, this is 100% reproducible.
Yes, this is 100% reproducible.
Re: 1.3.1.: Renaming videos produces error when video is open in tab
ok, right. Renae failed because the stream is opened in viewer mode
Pierre.
Re: 1.3.1.: Renaming videos produces error when video is open in tab
Upon rename, the stream would need to be closed and then reopened, wouldn't it?
Re: 1.3.1.: Renaming videos produces error when video is open in tab
This was fixed in 1.4.2 for the browser, i.e., I can now rename videos when they are not open in their own tab. However, if the video is already opened in its own tab, there is still above mentioned pop up saying: "An error occured during renaming."
I understand that the video stream must be closed and reopened for renaming, and the videos must optimally be fast-forwarded to the same position where the renaming was triggered. Could this be fixed as well?
I understand that the video stream must be closed and reopened for renaming, and the videos must optimally be fast-forwarded to the same position where the renaming was triggered. Could this be fixed as well?