Posted by: @kilimar

it seems like the extra control isn't being 'freed' and so it's stuck

I think we may mean the same thing 😊 

Rename My TV Series: 2.1.1 (Build 10)
SQLite library: v.3.25.2
OS: Windows (64 bit), Windows 10.0, i386 (32 bit application)

Bug found.  There seems to be an issue with AutoSort when dragging a list of files into the box vs adding a directory (either by drag & drop or using the Add Dir button).  When selecting a set of files in Windows Explorer and dragging them into RMTV Selected Files pane, the sort is wrong. 

Ughhh, forget the statement about "vs adding a directory".  It seems that they both have improper sort results.

Turning off AutoSort, adding the files and click Sort Files, also ends up with bad sorts.  If I move a name to different order and click sort, it just puts it back in the bad sort order.

I also want to say that the sort order isn't always the same 'bad sort' which is really strange.; although now that I am trying to reproduce the inconsistent bad sort, it isn't inconsistent bad sort, just bad sort. 

The filenames are nn[hhhhhhhh].mkv, where n is 0-9 and h is hex digit.  I don't think the brackets hurt the sort as I'm pretty sure I've had other filenames with brackets.

Hi Kilimar,

First off: thanks for posting the RMTV version info! 👍 
(most users do not post this info)

Would you have a list of file names for me so I can do some tests here?

The AutoSort function has been bothering me since day one, but I have not been able to find an algorithm yet that does it right all the time (suggestions welcome). 😉 

A few notes:

1) It tries to find a season number and an episode number. When a file name has more than 2 numbers or strange numbers, then this may interfere.

2) Adding files without AutoSort, will add files depending on how your OS hands it to RMTV. 
There are several scenario's here (eg. the order in which you selected the files, or the order listed in Explorer, etc), and they can be quite different per different platform.

Anything that can help me reproduce this bug would be great! 😊 

"V:\test-bad-sort\23[077571E5].mkv"
"V:\test-bad-sort\24[9771F006].mkv"
"V:\test-bad-sort\01[33D718B2].mkv"
"V:\test-bad-sort\02[4205379F].mkv"
"V:\test-bad-sort\03[4EF20C78].mkv"
"V:\test-bad-sort\04[C77411E4].mkv"
"V:\test-bad-sort\05[EB0158FF].mkv"
"V:\test-bad-sort\06[48CDCA02].mkv"
"V:\test-bad-sort\07[A10D0D52].mkv"
"V:\test-bad-sort\08[02A5440A].mkv"
"V:\test-bad-sort\09[46F56584].mkv"
"V:\test-bad-sort\10[40585411].mkv"
"V:\test-bad-sort\11[DBBE695D].mkv"
"V:\test-bad-sort\12[FFBD3724].mkv"
"V:\test-bad-sort\13[BC65CCDA].mkv"
"V:\test-bad-sort\14[9F2FC62D].mkv"
"V:\test-bad-sort\15[7485C56D].mkv"
"V:\test-bad-sort\16[EB30F6F0].mkv"
"V:\test-bad-sort\17[1A3E093B].mkv"
"V:\test-bad-sort\18[24396259].mkv"
"V:\test-bad-sort\19[96332624].mkv"
"V:\test-bad-sort\20[704E1C5E].mkv"
"V:\test-bad-sort\21[6BE4A7C1].mkv"
"V:\test-bad-sort\22[1C380F8A].mkv"

I think that, in general, a straight filename sort without any special logic for season and episode would work well in most cases.  Although to make it more or less complicated, depending on your view:

1) straight sort

2) option for straight sort, enhanced sort (your code), simple, regex

3) Have user enter a simple pattern matching for season/episode.  Something like from Albert Bertilisson's Renamer 6.0's Multichange (see image below)

4) RegEx pattern matching for season/episode.

I'll try to do some testing, hopefully today. But I most certainly can see why sorting goes nuts here hahah 😁 

Thanks for the list!

So with my initial test, I created all the files you listed.
AutoSort indeed makes a mess of this - which does not surprise either of us.

For example "17[1A3E093B]." strips down to these numbers: 17, 1 ,3 ,093.
RMTV is looking for a season number and an episode number. Potential years will be removed.
So now it has 4 numbers which it doesn't handle all that great 😞 

However;

• When dropping the directory on the list, with AutoSort disabled, the order remains correct.
• When selecting individual files (all of them), and starting dragging with #1, the order remains correct as well.
• When selecting individual files (all of them), and starting dragging with for example file #8, then order starts with #8 up to the end and then it adds #1 up to #8. So not in the correct order.  

Note: my Explorer view is set to "Details" and sorted by filename (this WILL make a difference).
The sort order in the last 2 experiments very strongly depends on how Windows Explorer hands over the list of filenames.
So in the last experiment, the list Explorer gives RMTV is: 8, 9, 10, ... ,23 , 24, 1, 2, 3, 4, 5, 6, 7.
In the experiment where we grabbed # 1 when dragging, the list is: 1, 2, 3, 4, ... 23, 24.

To be honest, I do not know what to do with this at the moment.
In a future release I could offer the option for AutoSort to be "smart" (guessing season and episode) or "dumb" (plain alphabetical sorting).

As for your suggestions;

1. I think straight alphabetical sort is something most users understand. So this could be an option to add (if I find space in the preferences window haha).

2. Using regex is a little too much for most users and will come with its challenges as well (unexpected results).

3. Having the user define his/her own pattern is something I'd like to avoid.

Sounds good to me. :)   

Originally and on multiple occasions, I had thought maybe it was some sort of non-space white space character and just chugged along using Albert's Renamer.  Finally decided to just test it with only alphanumeric.  In the past when I ran across this problem, I used Renamer or more painfully, reorder the files in the Selected Files pane.  

Speaking of moving files around in the Selected Files pane, I don't know why but I always have a hard time using it.  It either drops it in the wrong location (as in above or below my expected location) or it grabs two files.  For the later behavior, this is because I forget that RMTV doesn't behave as I expect .  If a file is already selected and I click a different file without the use of the Ctrl-key and drag, both files are selected and moved.  In Windows Explorer, unless the Ctrl-key is used, the any selected files are deselected and only the new selected is operated upon.

As for the former behavior (file inserted not where expected), I'm not sure how you'd solved without some sort of GUI indicator, like a thick line between two rows to let the user know where the new file(s) will be inserted.   Maybe highlight two rows to indicate that the new file(s) will be between them?

OK, I've added this option to my to-do list. It will take some work to take apart the current AutoSort and make a proper sort function. Not complicated, just takes some work 😊 

I agree with you that moving files in the "Selected Files" is a pain. This is because the control that I used is not supporting drag and drop natively.
I had to use this control, since the way I did it in the old versions of RMTV, didn't work great either, and the new control allows both lists (Files and Episodes) to move in sync.
I'm still looking for a better option 😞  
For now it takes a lot of work to replace it with something else, well, as soon as I find something else that works more intuitively.

@hans 👍 

Rename My TV Series: 2.1.1 (Build 13)
SQLite library: v.3.25.2
OS: Windows (64 bit), Windows 10.0, i386 (32 bit application)

1) Noticed that when adding a directory which has semi-colons it doesn't work.  I assume the program is using semi-colons as separators?  Worked around by renaming the directory.  I'm guessing it would have the same issue with semi-colons in filename?  

2) Did a simple sort implemented in 2.1.1.b13?  I noticed that it still has a problem with a directory where the filenames include some sort of checksum as part of the filename.  If you did, there still seems to be a problem.  Here's a list that had problem with this build:

"13[8A782A0C].mkv"
"01[62515D06].mkv"
"02[C836B65A].mkv"
"03[B0C143BF].mkv"
"04[F81E772B].mkv"
"05[5E88F818].mkv"
"06[C067D573].mkv"
"07[D5305754].mkv"
"08[127FD057].mkv"
"09[00492FA5].mkv"
"10[44E7FD78].mkv"
"11[8219D76A].mkv"
"12[103D0998].mkv"

If simple sort did not find it's way into b113, then ignore the #2. :-)

3) I noticed an unexpected behavior selecting episodes and then right clicking for the context menu to merge.  When I right click, all except the current selection would get unselected and so the merge option was unavailable.  Playing with it for a bit, it looks like you have have to "right-click to select" (which isn't normal in Windows) and get the context menu.  Just a comment here, no need to fix if you don't feel like it. :-)

4) When merging 2 episodes and it has different titles; thoughts about including a separator option under Renaming Rules for merging multiple titles?  Looks like right now it just uses a space.  I'd like it to use a semi-colon.

Hi Kilimar,... 😊 

The semicolon ( ; ) is on all filesystems (Windows/Linux/MacOS) either considered an illegal character or an undesired character.
To avoid problems in general, even if your filesystem shows a semicolon (like under MacOS or Linux), I'd highly recommend not using them.
For example under MacOS you can use a semicolon by escaping the character (for example type "\;" instead of ";"). I have not tested this under RMTV though, and I would highly recommend against using semicolons - it is a recipe for unexpected issues.

Sorting: At the moment I have not yet implemented a "simple" sort. 😁  Sorry - did not have time for that yet.

Merge/Select: This is a known problem under Windows.
The current work around is to select the items your want and press and hold SHIFT when right clicking.
I haven't found a good and satisfying fix for it yet though.
It either works as it should and selected episodes/files are not linked when scrolling (bad), or they do scroll correctly but we have this right click issue under Windows 😞 

Naming merged files: you can use different characters. Again: I'd highly recommend against using a semicolon though.

Change (for example) this:

%NFY - %SZx%EZ[x%EZ] - %T

to this:

%NFY - %SZx%EZ[;%EZ] - %T

The red/bold character only gets added when doing multiple episodes, but Windows may cause problem when using semicolons in file names. If I recall correctly (so I could be wrong) the semicolon is reserved for listing multiple files in Windows, eg. file1.avi;file2.avi etc.

Whatever is between square brackets is what is being repeated for multiple episode files. You can define multiple blocks like that. For example:

%N - s%SZe%EZ[-%SZe%EZ] - %T[,%T]

will result in something like this (season/episode and title blocks are repeated):

Stargate SG-1 - s02e07-02e08 - Message in a Bottle, Family.mp4

On the semicolon note: most mediacenter applications (for example Kodi - see this article in the Kodi Wiki, where either "e", "x" or "-" is mentioned).
Since most other mediacenter like applications have similar rules. For example here in the Plex documentation.

You know how you thought the [hash] was messing up the sorting?  I have a directory where the filenames are 10.mkv through 28.mkv.... and it sorts it wrong.

I tried drag and drop a highlighted list; as well as adding by directory.    Autosort enabled.  Of course, clicking Sort Files doesn't do anything since it think it is already sorted.  And if I drag a file into the correct order then clicking "Sort Files" will put it back in the wrong order (as expected).

Odd!

The sorting mechanism is expecting 2 numbers: a season number and an episode number - if it cannot find thee then the order will not as expected. It's been a while that I looked at the sorting order, as it could use some work, and there is also a pending request to sort simply "alphabetically". Any algorithms to sort is welcome of course, but the unusual naming of files can indeed be a pain. Most really have 2 or 3 numbers - the third number potentially being a year (which it strips).

Any suggestions are most welcome.

Have you tried adding the files to other similar applications?
I've just tested Sonarr and it doesn't know what to do with it either with filenames like "13[8A782A0C].mkv"" or "10.mkv" (since show title is missing).