Slow track recognition
 

I am slowing ripping all my CDs, storing them on an external hard drive and making them all available through Limewire (3.8.5 Pro). I use an iMac OSX.3 and broadband. Currently I have just under 10,000 tracks available but each time I start up Limewire it takes approximately 6 hours to 'share' all the tracks. On the previous version of Limewire the 'sharing' was pretty much immediate and I haven't changed my setup apart from instaled the latest version of Limewire. Is this normal? What it means is that I often close down the iMac long before the full sharing is available.

I was going to mention the same thing, but the post implies that this is a recurrent event,
i.e. The shared files are hashed at every launch.
?

Another comment which is very valid is that 10,000 files is way too many in terms of performance... A great deal of bandwidth is going to be consumed in the simple responses to queries, right ?

Far better to establish multiple sharing folders of moderate size and rotate the sharing...

Also, doing a search for the files you are sharing will reveal how many other people are
sharing the exact same file(s)...
If the sources are high for any particular file(s), it is best to remove them from your sharing folders and thereby allow other, possibly more 'rare' files, a higher likelihood of being shared.

I should have explained that I use iTunes to rip my CDs and these are stored in folders created by iTunes. I wouldn't wish to mess about with iTunes as it works so well and my primary purpose is to safely store all my CDs and secondly to allow sharing. I shall put up with the slow 'hashing'!

OK...

BUT, your iTunes 'Library' folders should not really also be your 'shared' files.

Far better to keep shared files separate from any files that you may consider to be things you want to keep in the 'bank'.

Plus, no matter what, something is not set or set up correctly if you are having your files 'hashed' every time you launch LimeWire.

Well, Mr. P !!!
Hashing seems to be about the only 'logical' conclusion...
What else could it be ?

I mean, on a rough guess, not knowing at what level of 'quality' he is doing what are presumed to be .mp3 files, it must be at least 40GB... And, if they're .wav he's sharing, than we could all retire for a month on what it must have cost to buy that external drive, huh ?

Gotta be 'hashing', but why on every launch ?

Hey, 'logical' conclusions about anything related to computers !!!
That's funny !

:eek:

All my tracks have been ripped in iTunes using the standard AAC encoder (128 kbps standard) and show as .m4a files. They certainly sound better (fuller) than mp3 and no .wav files! I haven't added many tracks since I purchased the professional and latest version so do you think I should delete the current program and download again? I'm happy to share the files I've got but wouldn't wish to mess up the system as Limewire seems very good. For me the best aspect of music sharing is to be able to download those songs that have been stuck in my head for years like 1960's TV themes. I find it a very useful catharsis!

Ursula is quite correct - my external hard drive contains 10,000 tracks and is currently at 40gb. The previous version didn't struggle with this at all though.

OK on all so far, but the ridiculously named 'accountantese' of "the bottom line" stills says, something is for sure wrong as those files should only be 'hashed' ONCE unless they are altered in some way... Unless I am totally missing the way LimeWire deals with sharing/unsharing 'shared folders'... However, I can't believe anything that negative about LW because if you cannot, for example, 'unshare' a folder (temporarily) without going through the whole 'hashing' process when said folder is again shared, than LW is in serious need of joining the early 21st century !!! This, I do not believe !!!
I say the above bits because that may hint towards some problem with a 'setting' or whatever... But, this 're-hashing' is on every launch...

One question that I think of now... Is the 'hashing' of ALL the files happening at a fairly high-priority, i.e. fairly quickly, or, is the 'hashing' going on WAY in the background and taking an enormous amount of time to actually complete 'hashing' ALL the files ?
Meaning, maybe it isn't re-starting the 'hashing', but slowly 'finishing' it...

I know it's a weekend and all, but it seems a little strange to me that someone else has not come in with, "Hey, I've got the same problem and..."

Wonder what trap_jaw4 thinks about this one... ???

Apologies.. Rambling here a bit in thinking about it all... but, the basics to refresh... argue away about this, btw !!!...

Not in any necessary order of priority -

Too many files are being shared at once... Honestly !

Whatever iTunes 'Library Bank' files there may be should NOT affect anything with LW... UNLESS they are also being selected for sharing...

The 'type' of files has no actual bearing on the 'hashing problems'...
(they could just as well be Serbo-Croat cook book files in TomeRaider format !)
No ?

There is absolutely no need at all to 'mess about with' anyhting to do with iTunes and the files used for iTunes...
The problem lies with either LW or the manner in which LW is set up in this particular case...

And, last for now... davideves is just another one of those typical criminally-minded types who routinely does searches for things such as "60's" and the like... You know, Peerless, he's just like us !!!!!!!!!

:p

you guys are doing a great job helping out us Mac folks. All I can add is that your numbers sound right to me Peerless (and thanks for taking the time), that the earlier reported problems with external firewire drives and early versions of Panther shouldn't apply here, and that the only time LW might rehash all the files is if the fileurns.cache gets corrupted somehow.

The hash is written (and backed up) in two files stored in the ~Library->Preferences->LimeWire folder

fileurns.bak
fileurns.cache

those files are about 200KB each storing hashes for 1128 files here (~4 GB). Perhaps that will give another benchmark.

I have shared >11,000 files with no obvious problems in the past, but nowhere near 40 GB.

edit--Took just about 7 mins to hash the kid's Music folder (174 files; 1.27 GB) minutes; the fileurns.cache started at 4KB and ended up at 44 KB (800MHz iMac OS 10.3.2 running the LW 3.9.2jum288), but on the startup disk.

Hmmm that fits the 6-7 hrs hash time for the file number, but only 3-4 hours based on total size.

I have installed the latest version (3.8.7) and I shall leave the iMac running for the next few days to ensure all the tracks are hashed. Sometime next week I shall reboot and see what happens. Many thanks for your suggestions. To date 1200 tracks have been hashed in one hour. This appears to be in accordance with everyone's thoughts so hopefully this will work. It was suggested earlier that I allow only a proportion of the tracks to be available on Limewire, eg. rare recordings. Since I get approximately 50 uploads a day I can see that the tracks that I would consider rare aren't shared as frequently as others. The most frequently uploaded track is a 'duet' between a tramp and [a man with an 'interesting' voice] from an album that is available in most decent sized shops. I wouldn't know which ones to share. It would be nice to be able recommend tracks similar to the Amazon pops up with 'if you liked that then you may like this'. On occasion I have noticed one person slowly collecting a whole album so I have tried to 'chat' but have never found anyone willing to communicate. Why have chat available? It seems to me to be another way of 'sharing'!