I'm glad you were able to resolve the issue you were having. :xeri_ok1ani: You may need to enable sharing "Programs" for them to be added to your library. on the My files tab in Options there is a button to Configure unsafe sharing setting.

That's excellent news the problem is fixed. :yahoo: I'm on an older mac 2008 & open in 32-bit works for myself. I have an issue when it's disabled. No doubt your newer machine handles 64-bit much better.

As BigJx pointed out, the option for sharing programs is the first option window in WS preferences window.

Attachment 6775

If you ever have a situation where you haven't used WS for a long time, perhaps a year & WS struggles to connect, then close WS & delete the gnutella file from the WireShare preferences folder. WS will access fresher information online to recreate a gnutella file next time you open WS.
LPE does not possess this ability.

It works as you both say.

I guess that by WireShare preferences you mean the following folder and its contents:
/Users/~/Library/Preferences/WireShare

Many thanks again for you kind support.

Yes. However if you wished to keep your previous settings, incomplete downloads, library & shared information then simply delete the gnutella.net file.

Thanks.

Update for the record (in case it may help someone): since jDownloader required Java 6, it installed it and now WireShare shows it is using it instead of Java 7 (even though the 32-bit mode is NOT selected in the Finder - Get Info). Amazing. It seems that there was something weird with my previous Java configuration in the Mac mini and the replacements indicated in my message above fixed it.

Additionally, the bootstrap file is no longer in:
/Applications/WireShare.app/Contents/Resources/Java/lib
which is OK.

And the Info.plist shows
<key>JVMVersion</key>
<string>1.6+</string>

On the other hand, the firewalls are open for WireShare:

Apple - System Preferences - Security & Privacy - Firewall - Firewall Options (Two Java lines ALLOW)
Little Snitch - WireShare ALLOW is java.org.limewire.ui.swing.Main

I have also opened LimeWire Pirate Edition (LPE) 5.6.2 just for curiosity (firewalls are also open for it). It always uses Java 6, but never connects in 32- or 64-bit mode. When 32-bit mode is NOT selected, it shows:
You are offline - Please check your internet connection.
and keeps Connecting for ever. If 32-bit mode is selected, then just shows Connecting for ever. In any case, the pesky window does not show. Anyway, since WireShare is in fact the LPE update, that does not worry me at all.

Thanks again for this great site!

Again WOW, WOW, WOW...

I could make LimeWire Pirate Edition (LPE) 5.6.2 to work again: set as 32-bit mode and replacing its
/Users/~/Library/Preferences/Limewire/gnutella.net
by the one of WireShare at
/Users/~/Library/Preferences/WireShare/gnutella.net

Thanks to Lord of the Rings for the tip about the gnutella.net file- Although deleting it was not enough. What worked was replacing it by the one from the working WireShare. Amazing!

It shows a blue five-bar turbo-charged connected to five hosts. Shows Java 1.6.0_65. On the other hand, as previously indicated, LimeWire - Preferences - Advanced
is set as default:
Gnutella port - Use Universal Plug 'n' Play (Recommended)

BitTorrent ports - Use Universal Plug 'n' Play (Recommended)

Of course, the Mac and Little Snitch firewall have permission for LimeWire to connect.

So now, both LimeWire and WireShare work the Mac mini with OS X 10.9.4 (Mavericks).

Just for the record, in case it may help someone.

Suggestion to the admins: perhaps the title of this thread could be changed to LimeWire Pirate Edition becomes WireShare, or something similar.

Thanks GeX, good point. I'll see how it can be best added. :)

Thanks for creating this new thread as WireShare (formerly entitled LimeWire Pirate Edition).

Update for the record, in case it may help someone:

My fixing procedure above worked as said, but created lots of items with bad permissions related to Java. I have found it today after running Apple Disk Utility and have repaired them all.

So, it is good to run Disk Utility repair permissions after the items replacement indicated in the fixing procedure above.

Your welcome. And thank you for suggesing a logical change. :)
That's not surprising. Files from a different system, different permissions. ;) I remember trying something similar 3+ years ago with replacing java files from the alternate startup drive but can't remember if it fixed the issue or not (maybe not, maybe not the same files). I simply remember one day I realised the problem seemingly vanished out of the blue when I tried to use LW5 or a LW5 based program. I'd been using LW 4.16 instead. (My favorite was 4.14 but couldn't find the installer when I bought this computer. Though found it much later.)

(Re-implementing one or more things from LW 4 is on the list of possible things to do, but no promises it will happen.)