Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Springdream

Pages: 1 [2] 3 4
16
Bugs / Re: Slow scanning even with cache
« on: October 15, 2014, 18:56:24 »
The slowing down also applies to me. First some 1000 are quite slow, then at let's say 10000 its 1 song per second.
I guess similarity has to compare each file against each other  meaning time effort is proportional to faculity of n (N!)?

I also have the feeling that the cache does not speed up too much.

ALSO another question on the cache:
1) does it slow down if there are too many item in the cache that do not exist anymore? AND
2) if so maybe a function like "delete cache items that do not exist anymore" would be nice
3) I have the feeling that the cache is relating to absolute paths of the files. Everytime there is a changed folder name all files below that folder are lost in the cache. Maybe the cache could refer to some other file properties like a hash, checksum ect. or name, size and date?

17
Bugs / Re: Slow scanning, crashes, etc
« on: October 15, 2014, 18:45:28 »
could it be that the algorithm to compare the songs is slowing down the progress and not the calculation of the fingerprint? also for >100000 songs in the cache the cache seems to get ineffective?!

18
News / Re: Beta version 1.9.2
« on: October 15, 2014, 18:40:56 »
I also would like to try the new method you mentioned. When do you think will you make it available to the public?

19
News / Re: Beta version 1.9.2
« on: October 15, 2014, 18:39:50 »
Hello,
one suggestion regarding the time estimatin (which I like): for big selections files and folders take quite a long time to be scanned completely. Till then the estimate makes no sense. Maybe the scan could be finished completely in the beginning..?!
Regards...

20
General / Re: Open CL and NVIDIA CUDA - GeForce 8600GT
« on: October 12, 2014, 16:35:14 »
could resolve it by uning quite old driver for my n460gtx

21
Bugs / Re: Slow scanning, crashes, etc
« on: October 12, 2014, 13:14:27 »
The initial effect of slowing down also applies to me using 191 192 beta...
Any solution?

22
General / Re: Open CL and NVIDIA CUDA - GeForce 8600GT
« on: October 12, 2014, 13:02:36 »
Hello,
I have the same issues on my GTX460.
Although the log says:

2014-10-12 11:43:06   OpenCL: NVIDIA CUDA - GeForce GTX 460
2014-10-12 11:43:06   OpenCL: GeForce GTX 460 version 340.52 (OpenCL 1.1 CUDA)
2014-10-12 11:43:06   OpenCL: Work group size 64
2014-10-12 11:43:06   OpenCL ready...

When I do the benchmark I get
Calculation error or device busy

The log repeatedly says

2014-10-12 11:44:05   COpenCL::Process:416 failed [false]
2014-10-12 11:44:07   COpenCL::Process:416 failed [false]
2014-10-12 11:44:15   COpenCL::Process:416 failed [false]
2014-10-12 11:44:25   COpenCL::Process:416 failed [false]
2014-10-12 11:45:43   System error [997]
2014-10-12 11:45:43   COpenCL::Process:416 failed [false]
2014-10-12 11:45:43   System error [15100]
2014-10-12 11:45:43   CAudioComparer::BlockCL:1035 failed [false]
2014-10-12 11:45:43   System error [15105]
2014-10-12 11:45:43   CAudioComparer::ProcessCL:1124 failed [false]
2014-10-12 11:45:43   OpenCL use failed
2014-10-12 11:45:43   System error [997]
2014-10-12 11:45:43   COpenCL::Process:416 failed [false]

I have no idea of Similarity finally uses now OpenCL or not...

Any solution?

I am using Win7 Prof 64 bit



23
Wishlist / Link to duplicate when deleting
« on: January 04, 2013, 17:26:07 »
to keep album information complete although duplicates are deleted
- add a textfile with a link to the original and/or
- a link to the original

24
I just worked with Jaikoz and they store some time consuming information like accoustic fingerprints and Musicbrainz ID into the file.
The next time it is not required to calculate that stuff again.

Also maybe Similarity coud utilize already stored IDs OR if they are sufficient in quality use them for precise comparison instead.

Also a cooperation with e.g. Jaikoz may be interesting as YOU make the best duplettes checking :-) !

25
I often loose the information when mp3 are moved or similarity cache is cleared.
If not too big it may make sense to put it into mp3 properties.

26
Bugs / Re: [SOLVED] Please Help: Automark ignores mark priority
« on: January 04, 2013, 00:12:29 »
OK, works thanks a lot!

27
Bugs / Re: Automark ignores mark priority
« on: December 30, 2012, 21:45:14 »
I did some investigations :-)
for automark sorting by ... results in ... (threshold all off, ">" means when first criteria was equal, next criteria):
- Bitrate: OK
- Duration: mainly works, except:
- duration > bitrate : in some cases duration is equal (to milli second), than Bitrate is not evaluated correctly (flac with high bitrate was not considered)
-  duration > size: also size not considered correctly (when mp3/flac mixed)
- size: OK
- format: OK
- format > rating: error, seems to mark sometimes high and low ratings...
- tags?? where is it displayed. %tags means degree of identical tags, not completeness?!?

In your documentation it says either good or bad items may be marked, but I think always bad shall me marked for later deletion?!

Please, need Help! wanted to sort all my stuff during christmas holiday :-(


28
Bugs / [SOLVED] Please Help: Automark ignores mark priority
« on: December 29, 2012, 22:46:45 »
I like to mark worse songs, so my top priority is "rating".
Help says it is marking files with lowest rating.
That worked well for most of files, but a significant number of files is incorrectly marked (see attachment).
It looks like Bitrate has been given higher priority than rating?!
Regards,
Martin

29
I think it is OK!
Otherwise you cleanup your collection and don't buy the program => no progress

30
It only happens if CACHE is very big.

=> Similartity should show a screen "please wait" and hourglass.

The same applies if Similarity starts.

Here it takes 30s without saying anything!

Pages: 1 [2] 3 4