Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:
Verification:
This site name www.[site].com?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: YK
« on: June 25, 2014, 23:05:25 »

Well, the logs didn't mention anything about any problematic file from my collection, but only files related to Similarity. I attached the logs, maybe you can figure something out.
Posted by: Admin
« on: June 25, 2014, 20:18:57 »

Decoder.exe file is as you guessed is out of process decoder, if one of them hang up for example Similarity can't do anything with it, it just attaches itself to new one and skips scanned files, old one can still in memory hanged up. This scheme gives us huge benefits, just imaging which would be if hang up one of threads of Similarity.exe on middle of scaning. To find problematic file you can see logs located "%appdata%\Similarity\logs" folder (enter in Explorer).
Similarity doesn't specially process link files it depends on file system and OS.
Posted by: YK
« on: June 25, 2014, 02:30:36 »

This post is pointless as I fail to give any method of recreating the bugs.

I fed a monster job to Similarity, about 200k files, mixed audio files, most were chiptunes, took me few hours.

By the end, when I checked the results, the 100%, 100%, 100% duplicates were somewhy in the middle of the list, maybe it's ok, because of some logic we, average Joes, do not understand with our pea sized brains.
But what was interesting, after I exited Similarity, Decoder.exe was still holding the target dir as hostage. Had to terminate it manually.
Also, tell the user to keep the target dirs under simple, short paths as complex paths, especially with symbols in name will make Similarity to miss few hundred duplicates.