| T O P I C R E V I E W |
| wolph42 |
Posted - 13 Nov 2007 : 00:38:52
Hi,
First of all a LOT of thanks for implementing the new feature. It works like a charm!
(for those reading this without understanding: XMM know recognizes movie filenames ending with CD1 and CD2 and automatically joins them during the disk scan)
As promised I would test it and until so far the only 'bug' I could find is that in case of "The Blob CD1.avi" (with the put-"the"-at-the-end-of-the-name feature turned on) this results in "Blob , The.avi" (the space in front of the ',').
Other stuff that could be expected not to work are movies spread over three or more files. Interestingly enough the feature now 'joins' cd1 into one entry and joins cd2 and cd3 into another entry. However I think I have maybe four of these cases and I guess in general they're quite rare so not really a bother to do those manually. Of course if you feel like straightening this last bit out as well, I won't stop you  .
Also there are numbers in "()" behind the join number i,e,: 4(0,9565217). I don't know what you use m for but from a cosmetic point of view you might want to consider leaving these out, although I guess it is still necessary to differentiate between the 'automatic joins' and the 'manual joins' (which currently works).
Ok now here the results if you want to make it idiot proof (I guess this is mostly a 'bug' in the scanner algorythm and not in the double check part):
If you
1. select a folder to scan and while scanning you stop it.
2. select the same folder again and continue scanning.
then the result is that all the items found in step 1. are again added in step 2. (and recognized as double cd's and marked as such).
I guess the neat way is to check whether the folder to scan has previously been scanned and if so then empty the list (although I can imagine this will also have unsatisfactory results: scan dir1, scan dir2, scan dir1 again, everything previously scanned is wiped...)
Finally some remarks (you could call it features)
-I did miss a checkbox: "scan subfolders". Currently XMM does this automatically, but sometimes you don't want that.
-You might want to mention the 'rules' for XMM to recognize double file movies. Although as far as i could test, the only two rules I could distinguish is that people use arabic numbers ("1","2") and apart from the numbers, the filenames must be exactly the same.
If I find more I'll let you know. For now again: a lot of thanks, this has saved me a lot of tedious time... |
| 5 L A T E S T R E P L I E S (Newest First) |
| mikamikaze |
Posted - 22 Nov 2007 : 22:03:10
The problem is that as it's actually done, I think data are damaged if the user isn't doing the check on each import.
Before, if you wasn't linking two files, two entries were created, it was quite easy to detect (name in double in the file list).
But now, if somebody import his files and isn't checking if files hav been linked, there are multiples movies (alien 1, alien 2 ...) in one file, now it's quite ompossible to detect it. You have to check in the right tab to check if some files are in the wrong place ... that's what is not fair in my mind.
I agree it can save time on your situation but you have to think the lost of time it will produce if somebody forget (or don't know he has) to unlink badly detected files.
It's why there is something to do and not just accept because you're aware of how it's working and you've changed your procedure because you was the feature requester.
It's not a horror for me, I know what I have to do now. But I have a little tip to enhance the actual algorithm. I observed a pattern in all my filenames. There's always a space before the number when it's a serie of movies:
MyLife 1
MyLife 2
But when it's a multiple file for a movie the isn't any space before the number:
YourLife - CD1
YourLife - CD2
I hope you'll take it in account after checking it's not breaking something else.
Thanks for your support. |
| wolph42 |
Posted - 15 Nov 2007 : 15:14:01
quote:
Originally posted by mikamikaze
"Taking a look" is not really fair for the user :)
This new algorithm can corrupt databases joining movies that wasn't if the user is not aware of the auto-linking.
Shoul de good to make it optional and customizable.
Thanks.
In all fairness, the immense task of joining all movies manually, versus the very minor task of unjoining the wrong 'conclusions' of the engine is a trade off I'm very happy to live with.
So I agree with Alessio that the engine (always) will have it's limitations and that these rather unigue exceptions are a bit too much too handle in detail. I just mentioned it to at least make him aware that this is an (albeit tiny) issue.
On the other hand I do think that you (Alessio) should mention something on the scanning screen so user actually now this is a new feature. And obviously it would be nice if you can turn it off, although I can't really see why you'd want that |
| mikamikaze |
Posted - 14 Nov 2007 : 13:59:35
"Taking a look" is not really fair for the user :)
This new algorithm can corrupt databases joining movies that wasn't if the user is not aware of the auto-linking.
Shoul de good to make it optional and customizable.
Thanks.
|
| Alessio Viti |
Posted - 14 Nov 2007 : 09:43:04
Hi Wolph42,
I can imagine also without try it 
Of course there are some limitations in the engine, you should "take a look" to the grid before proceed with import and maybe "unjoin" these movies.
Alessio |
| wolph42 |
Posted - 14 Nov 2007 : 00:09:08
guess what happened with the movies
oceans 11
oceans 12 and
oceons 13
 |
|
|
