Rename Failed if only one "mkv"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. one subdir with only one "mkv"
2. press button "Renomer"

What is the expected output? What do you see instead?
- movie renamed...
- le renommage à échoué

What version of Movie Renamer are you using? On what operating system?
1.2.4 Alpha
Windows 7/64

Original issue reported on code.google.com by leglub...@gmail.com on 2 May 2012 at 9:49

[GoogleCodeExporter]

This kind of issue can come from many situations, maybe you don't have 
permission to write, or an invalid character in filename, or a bug in Movie 
Renamer, ...
I really don't know from where the problem comes.  

Can you please try to reproduce the bug with Movie Renamer 1.2.5_Alpha ?
if it doesn't work, after rename failed, close Movie Renamer and send back to 
me logs which are :
$Your_Drive:\Users\$You_User\Movie_Renamer\Logs\movie_renamer.log
E.g: C:\Users\Titi\Movie_Renamer\Logs\movie_renamer.log

NB: you can attach log file in a comment issue or send a mail at : 
movierenamer@free.fr

Original comment by nico.ma...@gmail.com on 3 May 2012 at 12:50

[GoogleCodeExporter]

Notes:
1) Everything is Ok when more tan one file
2) I am in 1.2.5 alpha (sorry for error in 1.2.4)

see attached file...

Original comment by leglub...@gmail.com on 3 May 2012 at 2:03

Attachments:

• movie_renamer.log

[GoogleCodeExporter]

Thanks, but this log file isn't useful because it is empty.

Movie Renamer use logs rotation which means that when you start it, it will 
create a new log file (empty) and write in it all logs and unlock log file only 
when application shutdown, all older logs are moved to the "right file", the 
most older log will be remove from HDD (we don't want to keep Megabyte of logs 
^^)

To summarize, for "good" logs, you have 2 ways :

 - 1°) Run Movie Renamer, try to rename, when rename failed, shutdown/close Movie Renamer (very important), and then the file PATH_TO_LOGS\movie_renamer.log will contains all last logs (more easy solution).

 - 2°) Search in logs folder, in movie_renamer.log.$n ($n is a number) , the log which concern the bug (not easy, and you probably never found it due to logs rotation)

I tried to reproduce your issue with no "success" (Linux 32/64bit, windows 7 32 
bit) and all works find for me.

Original comment by nico.ma...@gmail.com on 3 May 2012 at 2:30

[GoogleCodeExporter]

and this...

Original comment by leglub...@gmail.com on 3 May 2012 at 5:28

[GoogleCodeExporter]

Perfect , thanks you, i think issue is due to Movie Renamer try to rename your 
drive "F:\" because it think that is a directory, but it is a "root directory", 
only operating system can rename "root directory" (maybe some software can, i 
don't know).

I just forgot to test if it is a "root directory" ^^

I think you can say thanks to your operating system (file system), if Mr is 
able to rename your drive, i think you would have lost your data due to 
NFTS/FAT32 file system which are very strict (of course on other OS like linux, 
you can rescue your data if a things like this happen under windows ^^)

Sorry for the inconvenience, if you create another subdir, i think rename 
action will be a success

Original comment by nico.ma...@gmail.com on 3 May 2012 at 5:46

• Changed state: Accepted

[GoogleCodeExporter]

Yes if the movie is in subdir, the rename is OK

but is working also on root drive, if i have more than one file :-)

Original comment by leglub...@gmail.com on 4 May 2012 at 12:13

[GoogleCodeExporter]

This is normal (of course not, it's a bug^^), if Movie Renamer think that the 
movie directory is named like movie file, it will automatically rename folder 
during rename process, but for prevent error, i had a protection (which is 
really stupid) which check if there is other files in this directory (instead 
of check if there is other movies) and only if there is no other files, Mr will 
rename folder.

It's a "combo a two bugs", i really don't know why Mr think that "F:\.*" is in 
movie filename (just filename, not path + filename)

For Mr 2.0_Beta rename process will be implemented from scratch, the current 
process has too many bugs.

Original comment by nico.ma...@gmail.com on 4 May 2012 at 1:17

[GoogleCodeExporter]

:-)

Thanks...

Original comment by leglub...@gmail.com on 4 May 2012 at 1:41