|
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'! |
Hi, davideves... The comments re: reducing your volume of shared files, at any one time, is intended to actually increase the number of others sharing those 'rare' files - So that they cease to be 'rare' ! As I mentioned, it's only a matter of noting how many other 'sources' there usually are for a given file. If there are numerous others sharing the same content, than it makes sense to stop sharing the same file yourself and thereby improve the chances that you will have an Upload Slot available to someone who wants the 'rare' goodies. It is quite amazing to observe the process involved in sharing something quite rare... After a short while you will begin to notice the 'sources' for that 'rare goodie' steadily increase - And, you know that YOU did that ! Nice. It is all basically about increasing the total volume of material being shared, not increasing the numbers sharing the same material. (In only the past two years, the variety of 'content' available on Gnutella Network has increased enormously... And, we all hope that growth will continue !) On the 'hashing problem' - Perhaps there is some misunderstanding here and that the situation is not that your shared files are hashed again on every launch ? And, can you check to make certain that your files that contain the 'hash data' are not being deleted for some reason or possibly being saved in an incorrect folder ? And, as Peerless mentioned, check the shared files ratio which should also serve as an indicator of the status of hashing progress... That's the most simple way to confirm whether or not the hashing is re-starting at zero or simply continuing towards completion. Last... The [Edit] up there... Not allowed to make specific references to copyrighted material. (But, hey... At least I didn't do it in Red, as is normal !) ;) |
Sorry for mentioning a specific artist. Hadn't thought about that. Have left LW on all day and all the files are now shared (about 7 hours). I'll leave LW live overnight and boot tomorrow. If LW starts to hash all the tracks once more then I shall think about my options. In truth maybe I shouldn't worry as it doesn't effect my ability to search and download and broadband allows me to leave LW live most of the time. Whilst it may be an issue I guess it's not a big problem so long as it isn't causing a problem for LW. The chat has been of value and I appreciate the comments. Some of the forums on-line house some people who you might consider peculiar and arrogant if you were to meet them in a bar. Thanks for the support. |
Quote:
Not true ! Where I live you would never think that about the folks you're referring to... Cuz when you 'met' folks like that in a bar here they'd already be quite dead and on the floor. ;) p.s. davideves, don't worry... I can help you with international distribution of those videoes from the bar Peerless crawls to... We'll make a fortune ! :p |
Yesterday I left LW is slowly hash all the tracks (c. 10,000) and this process took 6-7 hours. After another 5 hours I turned the iMac off and this morning booted up. LW is again hashing all the tracks (currently standing at 1600 out of 10,000 in 1 hour which is the same as before). What would be my next action or should I accept this is due to volume of tracks? |
Hmmm... ? As I posted above... - "And, can you check to make certain that your files that contain the 'hash data' are not being deleted for some reason or possibly being saved in an incorrect folder ?" - There is definitely a problem. The hashing should take place only once unless there is some alteration made on a file, or possibly the 'location' of a file is changed. You must be having a problem with the hash data file not being saved in the correct place... or LW is, for some reason, not 'looking' in the correct place... or The hash data file is being deleted for some reason, on shutdown or launch... or The file is somehow being 'mislabeled'... or Or, what ? :confused: |
The files are stored on a firewired external hard drive but all appears to be the same. iTunes recognises the tracks on the external hard drive and would search if it was unable to identify immediately (as it does if I download a track from LW which I can then see in iTunes. If I move the file to the external hard drive to be with the rest then iTunes tells me it can't find the file and asks if I wish it to search. I do, it does and all is OK). What if I put a thousand files on the hard drive, add the source to LW and see if these are hashed just the once? I'm not keen to mess about with the iTunes files so I could just copy a load and delete later. I noticed that when I deleted LW and installed the latest version over the weekend all my preferences were retained so maybe I hadn't unistalled correctly. For the Mac I highlight the programme and move to trash. Is there a better way to remove LW completely for the Mac? It must be very difficult to do your job when so much of it is blind and dependent upon the knowledge of someone else! |
Ah... Possibly narrowing things down here... Problem is probably related to the hash data files and your shared files being on different drives... There must be a simple 'setting' to be changed. I could easily explain what you need to do for various other clients, but not with LW... Sorry. :o btw, forgot to mention it earlier... That [man with an 'interesting' voice]... Believe it or not, I saw both him and Steve Goodman do their very first ever TV appearance... Was in the studio with friends who were the producers of the program on WFLD in Chicago... This was some months before Noah started building the ark... errr, sort of a long time ago ! :eek: |
davideves--were you able to find and look at the date modified of the two files fileurns.bak fileurns.cache ? The dates modified should change if LW is saving those files properly on quit. |
Quote:
|
I can't find either files on the Mac. |
What about on your external drive ? Sorry, I actually am assuming that you have checked there, but... Hey, you never know... |
Checked all drives and the two files are missing. Does this mean that LW can only hash and memorise up to a certain size of total files? This is an important issue for the future as I can't imagine I am the only person slowly ripping all their music partly as backup, partly because I'm anally retentive but mainly to allow me to access via my iPod. It also allows me to set up playlists that can be set to play for hours through my home on iTunes. These are the primary reasons for ripping but once done then I'm happy to share. I would imagine this would be the same for many people. My total collection will be less than 100gb but then I will start on vinyl which may add a few more gbs! LW will need to take this development into account in the future - not just because of me as I have no relevance at all but I would guess I'm not alone in doing this. |
The two files are in the LimeWire Folder inside the Preferences Folder inside the Library Folder of your home directory. Make sure these folders are writeable by you. I have occasionally seen these folders owned by root or similar bad things, this could prevent LimeWire from storing these files on shutdown. |
I've checked and these files are missing. |
Does it look similar to this: jum@ra dist$ ls -la ~/Library/Preferences/LimeWire/ total 448 drwxr-xr-x 21 jum staff 714 16 Mar 12:43 ./ drwx------ 245 jum staff 8330 16 Mar 12:43 ../ -rw-r--r-- 1 jum staff 6148 22 Jan 02:47 .DS_Store -rw-r--r-- 1 jum staff 102 16 Mar 12:42 Cookies.dat -rw-r--r-- 1 jum staff 108 15 Mar 16:48 Display.props -rw-r--r-- 1 jum wheel 3703 11 Mar 00:49 LimeWire.bsh drwxr-xr-x 3 jum staff 102 8 Feb 2003 META-INF/ -rw-r--r-- 1 jum staff 276 10 Mar 14:57 bugs.data -rw-r--r-- 1 jum staff 58900 16 Mar 12:43 createtimes.cache -rw-r--r-- 1 jum staff 158796 16 Mar 12:42 fileurns.bak -rw-r--r-- 1 jum staff 158796 16 Mar 12:43 fileurns.cache -rw-r--r-- 1 jum staff 113 16 Mar 12:42 filters.props -rw-r--r-- 1 jum staff 22965 16 Mar 12:42 gnutella.net -rw-r--r-- 1 jum staff 201 16 Mar 12:42 installation.props -rw-r--r-- 1 jum staff 1291 16 Mar 12:42 limewire.props -rw-r--r-- 1 jum staff 1030 10 Mar 2003 public.key -rw-r--r-- 1 jum staff 181 16 Mar 10:00 questions.props -rw-r--r-- 1 jum staff 1693 16 Mar 12:42 tables.props drwxr-xr-x 22 jum staff 748 3 Feb 00:14 themes/ -rw-r--r-- 1 jum staff 421 11 Mar 00:37 update.xml drwxr-xr-x 6 jum staff 204 10 Mar 2003 xml/ jum@ra dist$ |
Thanks jum--so that's how you get that info! Open Terminal (in the Utilities folder) Type "ls -la ~/Library/Preferences/LimeWire/" into the terminal window and hit return. Correct? -rw-r--r-- 1 stief staff 201631 Mar 3 16:40 fileurns.bak -rw-r--r-- 1 stief staff 202420 Mar 15 07:25 fileurns.cache [I--so that's why my fileurns.bak hasn't changed its date modified! I've been using the official build on this computer, and your CVS build on the other.] |
Yep, this how to get that info on a Unix shell. And yes, the official version does not know about this filurns.bak thing. |
Please remember I am using a Mac so I don't normally need to understand how it works - it just works. In prefs I have MANIFEST.MF limewirePro_theme.lwtp limewirePro_theme windows_theme.lwtp windows_theme default_osx_theme default_osx_theme.lwtp default_theme.lwtp default_theme black_theme black_theme.lwtp xml update.xml themes tables.props questions.props public.key META-INF limewire.props installation.props gnutella.net fileurns.cache Display.props createtimes.cache bugs.data Cookies.dat Does this make sense? Would it be easier if I just uninstalled and reinstalled? If so how do I do this on the Mac? I usually drag and drop into the trash. I feel I am getting out of my depth here! |
So you have a fileurns.cache there! Did LimeWire indeed do hash all files to the end before you did quit it? |
Yes... above he mentions that he ran the full files through to a completion of hashing. |
I am slowly getting out of ideas. Two things I can think of that might cause this: The disk your home folder is on is full or you have multiple disks with the same name. |
One possible cause is that LimeWire is opened at one point while the external drive isn't connected. If LimeWire senses that the files no longer exist, it purges the hashes of those files. Later, if they drive reconnects, the files will need to be hashed again. |
The only possible solution I can think of is to include a count of the number of times we have tried to purge the entry, and if it reaches a certain threshold then the entry is finally removed. Otherwise (if all files were always stored), the size of the list would become extremely large as users moved files to and from various locations on their drive. |
There were many problems reported elsewhere with external devices like firewire drives and OSX Panther. Looks like not all have been fixed even by today's update to Panther, judging by the Macintouch reports reports davideves, any chance the manufacturer has updated drivers on their website or there are settings which allow your external drive to "sleep"? I know Macs usually just 'work', but looks like you have something unusual going on. Sam--I noticed you've added jum's patch for the extra backup of fileurns.cache. Will that be in the next beta? |
>I noticed you've added jum's patch for the extra backup of fileurns.cache. Will that be in the next beta? Yes. |
I've become confused over my options as the detail is getting more complicated than I can handle. Instead I have searched the mac for all evidence of LW and removed repeating the process a few times. I have now reinstalled and LW did not recognise any previous prefs. LW is now hashing all the tracks again so I shall leave it running in the background for today, leave for a few extra hours to make sure all is OK and then reboot. Hopefully this will fix my repeat hashing problems. I'll keep you updated. |
Loaded most of the tracks and rebooted after closing LW. The number of shared tracks immediately went to the point at which I had closed LW suggesting that the hashing problem has been fixed by reinstallation. Many thanks for the support. |
| All times are GMT -7. The time now is 03:44 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.
Copyright © 2020 Gnutella Forums.
All Rights Reserved.