SoulseekQT Public Build 4 for Mac

Submitted by Nir on Wed, 06/15/2011 - 02:23

Not much to say here. Seems like all of the changes made for the Linux port pretty much worked right out of the box on OSX. The no proper dock icon business has been addressed. I went through all of the basics, rooms, downloads, uploads, sharing, browsing, searching. It all seems to work. If this is the first SoulseekQT build you're trying on your mac you'll need the Qt framework installed as before. Link below.

SoulseekQT Public Build 4 for Mac
Qt framework for Mac (Cocoa)

Cheers, Nir

Tags: 
SoulseekQt
Mac port

Comments

Submitted by interconnect on Wed, 06/15/2011 - 05:32.

Awesome. I'm so happy to see that their is working being done on a proper Mac client. It is the only thing that has been missing for me since completely converting over. Will their be a future build with the Qt framework bundled in soon? I would like to test, but am hesitant as this stage, especially if it requires an additional framework which I'll probably never use again except for this. Just wanted to say thank you Nir, please keep up the awesome work! I will most definitely help beta test once the Qt framework is integrated with the app itself.

Submitted by Nir on Wed, 06/15/2011 - 15:54.

Does this one work for you?

SoulseekQT-PublicBuild4.dmg

Submitted by audiophilepj on Wed, 06/15/2011 - 20:40.

I downloaded the bundle version you last posted. Worked at first. Then started crashing. So I download the original SoulseekQT-PublicBuild4 app, and it also crashes (so the bundled version is fine). I believe it has something to do with scanning shared files. I was able to delete all my shared directories and it seems stable. I was able to search and download a file perfectly. Chat and Rooms works good so far. I have a bunch of crash logs if you want them.

The slsk dock icon shows up after a few restarts?

The app window is still labeled Build 3 :)

When I navigate to the Options Tab -> File Sharing, I get no options on top. I have to click in the window and then the 'share folder' 'unshare folder' and 'rescan shares' show up.

Very usable! Thanks Nir! Let me know if there is anyway to help,

audiophilephil@me.com

Submitted by Nir on Thu, 06/16/2011 - 00:03.

Thanks for the feedback! I'll fix the build label. Not sure why it's not showing the dock icon right away. It seems to be working here, but I'll do some more testing. As for the crash, this is definitely the most worrisome bit. I'm not sure yet how to produce a useful crash report on the Mac, but I wonder if you can somehow isolate which file is causing the crash? Perhaps by adding one subfolder at a time, using the rescan share button and seeing when it crashes? Once you have the folder it should be easy to do the same one file at a time. It might have something to do with the MP3 attribute scanner. If you know which file is causing this we can coordinate you sending it to me so I can see why it's crashing the client. Of course there's always the chance it's not a particular file causing this at all, so I understand if you don't want to go to the trouble. Chances are I'll get a crash report for this problem on Windows at some point. I'm aware of the issue where you have to click the file sharing window to get the sharing options, this will be fixed soon.

Thanks, Nir

roomx's picture

Submitted by roomx on Thu, 06/16/2011 - 06:12.

Will try it out too on Mac here.

roomx's picture

Submitted by roomx on Thu, 06/16/2011 - 07:34.

Up and working.. Nice nice

Submitted by interconnect on Fri, 06/17/2011 - 08:17.

I thought if a program crashes, OS X will automatically generate a crash report? It would be possible to then copy into a text file or something and send it to you. Is that crash report no good?

Submitted by interconnect on Fri, 06/17/2011 - 09:15.

So far so good!. I tried your bundled version in the second post and had no major issues. Here are some of the things I noticed in addition to the issues that audiophile noted:

• The window size, position, column position, etc. is not saved between quit and next launch.
• Making the window smaller/larger/resizing a column or really interacting with the interface at all causes CPU usage to skyrocket and is very slow and choppy.
• I did notice that after I connected, the dock icon immediately changed from the default OS X one to the soulseek logo and on logout changed to the red soulseek disconnected icon. The icon in /Applications/ folder still shows the default Mac OS X application icon.

And I did have some questions though...
• Is their planned support for uPnP via miniupnpc and libnatpmp?
• What server does the Qt client connect to?
• What files and their locations are created in OS X so that in testing we can fully remove the previous version?

Submitted by Nir on Fri, 06/17/2011 - 15:55.

Remembering sizes and positions is on the to-do list. If the slowness you describe is due to Qt on Mac there's not much I can do about it. As far as I recall I'm not doing anything in my own application in response to column resizing, but I'll get around to making sure. Haven't had much luck replacing the application icon outside the dock so far.

As for port forwarding, that is my entire focus right now. The difference between the functionality of a Soulseek client that has its port forwarded and one that doesn't is just too vast to overlook. I already have miniupnpc integrated and working in SoulseekQT on Windows and I'll be looking into NAT-PMP next. I'm not sure how easy it would be to do the same integration in OSX.

SoulseekQT connects to the same server as Soulseek NS.

As for files and locations, I believe .Soulseek is created in the home folder and contains the entire client configuration. Other than that there's just $HOME/Soulseek Downloads.

Cheers, Nir

Submitted by interconnect on Sat, 06/18/2011 - 05:37.

You should be able to integrate miniupnpc and libnatpmp in the OS X build, some other non-official clients such as iSoul have done it. Many other OS X programs use it as well.

Submitted by Nir on Sat, 06/18/2011 - 15:11.

How likely is just UPnP to make a difference on a Mac? Do most Mac routers only support NAT-PMP?

Submitted by interconnect on Sun, 06/19/2011 - 07:06.

I don't know. I think the only "Mac" router is Apple's Airport Extreme and it supports NAT-PMP, although not sure about UPnP. However, not all Mac users have Airport Extremes. I, for one, have a Buffalo router with DD-WRT and it works great with both Macs and PC's.

Submitted by audiophilepj on Mon, 06/20/2011 - 10:04.

A few new notes. I wasn't sure if you wanted the OSX bugs in the 'Bugfix requests'. I'm unsure if these issues are platform specific.

The icon shows correctly when the app is running. After I shut down the app, the dock displays the default OSX icon.

I have discovered my crashing issue. When I upload to a user, when it reaches 100% complete, slsk crashes. This took me a while to discover, but I finally caught it. As I mentioned above, regarding the scanning bug, I was wrong, it scans correctly, and uploads correctly, but after an upload completes, it crashes. After a restart, the download resumes from around 75% done, reaches 100%, then crashes. I am forced the unshare the folder (quickly) and then the upload is cancelled, and slsk will remain running.

The 'Downloads' folder that holds the incomplete downloads does not delete the temp folder after it completes. The completed file is correctly moved to the 'Complete' folder, but the folder name from the download remains in the 'Downloads' folder.

Every time I restart slsk, it still rescans the shared files.

Again, Let me know if there is anything I can do to help.

Submitted by Nir on Wed, 06/22/2011 - 17:37.

Thank you for reporting these problems, I'll look into the upload crash bug on Mac. It doesn't appear to happen on Windows. Just one question regarding the re-scanning every restart, are you going by the "Shared" diagnostics tab or do you actually see scanning in the "MP3 Scanning" diagnostics tab? If the former, it's just checking to see if any files were added or removed to your shared folders.

Submitted by Nir on Thu, 06/23/2011 - 22:16.

I've found a crash bug related to uploads having their connection closed before they're initialized, which may or may not be what you're experiencing. I tried uploading an entire folder using the Mac client and had no crashes. This version also has the latest additions to the Windows version, i.e. UPnP and user context menus. I'm not sure if UPnP actually works as I'm testing inside of a virtual machine, but if your router supports it you can check the Diagnostics->Logs->Port Forwarding tab to see what it comes up with.

SoulseekQT nightly build 6/24/2011 for Mac

Submitted by audiophilepj on Thu, 06/23/2011 - 23:00.

I have port 2234 forwarded in my router. When I start the nightly build 6/24, under Diagnostics/Logs/Port Forwarding I get this...

Initializing UPnP
No Device list found during discover, miniupnp error code: 0
Adding mappnig for port 2235
UPnP appears to not have been initialized, aborting.

I used yougetsignal.com to check my port and see if QT is sending out 2234... it was not open? So I opened up port 2235, checked it, and it was open, so QT changed from using 2234 to 2235. I think this is because I have UPnP turned off in my Linksys router.

I turned on UPnP in my router and restarted QT, this is what I got...

Initializing UPnP
Device list found
http://192.168.1.1:2869/IGatewayDeviceDescDoc, InternetGatewayDevice, found
Device XML found
Adding mapping for port 2235
Found own address to be 192.168.1.101
Port successfully mapped.

QT is still using 2235, not 2234.

I think this confirms that UPnP is working on Mac QT, Nice work!

As for the upload bug fix, I'm sitting here patiently waiting for someone to download something from me :) I've asked nicely.... download something from me!

Still crashing.... damn it!

Submitted by Nir on Thu, 06/23/2011 - 23:05.

Yes, I changed the port to 2235 at some point during my testing because I also had 2234 explicitly forwarded and forgot to change it back :) Sucks to hear it's still crashing... let me see what I can find about generating a useful crash report on a Mac.

Submitted by Nir on Thu, 06/23/2011 - 23:29.

It looks like it's already producing readable stack traces. When it crashes again, can you please post the "Thread 0 Crashed" section in the crash report up to, not including, where it says "Thread 1: ..."?

Submitted by audiophilepj on Thu, 06/23/2011 - 23:41.

Here's my 'i'm not crazy' video http://www.youtube.com/watch?v=SqPg-znJfn4

Here's the crash report. Let me know if this is the correct section. I have 20 of these.

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.yourcompany.SoulseekQT 0x00085f63 TransferQueueManager::HandleUploadSocketBytesWritten(ItemPtr, long long) + 1427
1 com.yourcompany.SoulseekQT 0x0009dc46 TransferQueueManager::OnUploadSocketBytesWritten(long long) + 278
2 com.yourcompany.SoulseekQT 0x000df9eb TransferQueueManager::qt_metacall(QMetaObject::Call, int, void**) + 1547
3 QtCore 0x00eabb71 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) + 673
4 QtCore 0x00fdbb2a QIODevice::bytesWritten(long long) + 74
5 QtNetwork 0x00d8b067 QAbstractSocketPrivate::flush() + 1047
6 QtNetwork 0x00d8b23d QAbstractSocketPrivate::canWriteNotification() + 29
7 QtNetwork 0x00d790fb QWriteNotifier::event(QEvent*) + 75
8 QtGui 0x001fc19c QApplicationPrivate::notify_helper(QObject*, QEvent*) + 188
9 QtGui 0x002027e9 QApplication::notify(QObject*, QEvent*) + 2041
10 QtCore 0x00ea535c QCoreApplication::notifyInternal(QObject*, QEvent*) + 108
11 QtGui 0x001b2d1a qt_mac_socket_callback(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 154
12 com.apple.CoreFoundation 0x916d7cb5 __CFSocketDoCallback + 325
13 com.apple.CoreFoundation 0x916d77b7 __CFSocketPerformV0 + 311
14 com.apple.CoreFoundation 0x91691361 __CFRunLoopDoSources0 + 1201
15 com.apple.CoreFoundation 0x9168ef8f __CFRunLoopRun + 1071
16 com.apple.CoreFoundation 0x9168e464 CFRunLoopRunSpecific + 452
17 com.apple.CoreFoundation 0x9168e291 CFRunLoopRunInMode + 97
18 com.apple.HIToolbox 0x97dcfe04 RunCurrentEventLoopInMode + 392
19 com.apple.HIToolbox 0x97dcfbb9 ReceiveNextEventCommon + 354
20 com.apple.HIToolbox 0x97dcfa3e BlockUntilNextEventMatchingListInMode + 81
21 com.apple.AppKit 0x958f378d _DPSNextEvent + 847
22 com.apple.AppKit 0x958f2fce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
23 com.apple.AppKit 0x958b5247 -[NSApplication run] + 821
24 QtGui 0x001b43c0 QEventDispatcherMac::processEvents(QFlags) + 1488
25 QtCore 0x00f94bb1 QEventLoop::processEvents(QFlags) + 65
26 QtCore 0x00f94efa QEventLoop::exec(QFlags) + 170
27 QtCore 0x00f96576 QCoreApplication::exec() + 182
28 com.yourcompany.SoulseekQT 0x00005019 main + 201
29 com.yourcompany.SoulseekQT 0x00004dad _start + 208
30 com.yourcompany.SoulseekQT 0x00004cdc start + 40

Submitted by Nir on Fri, 06/24/2011 - 00:29.

I'll be damned if I know why it's crashing, but there are exactly three things that can go wrong in that particular bit of code, so I proofed all three and made it generate a nice log in the "audiophilepj's spectacular crash!" diagnostics tab. I can't reproduce the problem so I don't know how well any of this will work, but ideally your client won't crash and the log will be generated, in which case I'd be very interested to know what it says :) first things first though, let's see how it works: SoulseekQT-audiophilepj.zip

Submitted by audiophilepj on Fri, 06/24/2011 - 08:49.

It worked! No crash. It zips up to 100%, has a long, 10 sec - 1:30 sec delay, then displays complete.

I noticed some odd transfer hiccups. The download speed will be high, but it will stop for a 10 sec delay, but remain uploading, the progress percentage freezes, and the Kbs freeze, but nothing happens, then is starts again. Flying with high speeds. I'm wondering if its just QT lag?

Here is what the "audiophilepj's spectacular crash" tab displays.

I only copied some of the tab, it goes on FOREVER.

Thanks Nir, this release is 100% usable for me :) can't wait until it's complete!

[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.
[09:10:57] l_secsElapsed is not zero.
[09:10:57] l_bytesUploadedItem is null.
[09:10:57] lp_bytesUploaded is null.

Submitted by audiophilepj on Fri, 06/24/2011 - 12:04.

After some more testing, uploading will hang at 100% done for a long time, sometimes 15 minutes or more. I have been patient a view times, let it sit, my queued line gets really long, it eventually changes the status to complete, and starts next in line. It's not crashing, which is awesome. The display for downloading progress and Kbs is very smooth, refreshing very fast and accurate. The uploading progress and Kbs is chopping and sporadic. I'm guessing it's due to slower connections. 2.1 and 4.6 Kbs is slow. Could connection speed effect how frequent the status is updated? Waiting for someone with a fast connection to dl. Again, it works. I'm curious how it looks on the other end. Thanks,

Submitted by Nir on Fri, 06/24/2011 - 16:12.

Ah, it seems clear that the socket write handler is getting called over and over again despite the fact that nothing new is being written to the socket. This shouldn't happen and has never happened to me on either Windows or the Linux and Mac virtual machines, which makes me think it might have something to do with the Qt libraries. One thing I suggest you try is get the absolute latest Qt framework, I believe it's the first option on this page here (Carbon instead of Cocoa). Then run the version of the client that's been crashing and see if the crashes still happen.

Regarding the upload hanging, I've noticed that on Linux and Mac I often don't get any socket close notifications no matter how long I wait. I thought it might have something to do with the virtual machine software I'm using, but it might actually be an issue with Qt as well. There are already timeout mechanisms in the client for most of these cases but they might not be kicking in in the case of already complete uploads. Part of the problem here is that as part of Qt abstracting its socket functionality for its multiplatform purposes, you can't really get an acknowledgement when data has actually been sent and received by the remote party, so to avoid premature closure the Qt client just sends the data and waits for the downloader to close the socket instead. If the closure notification is never received it would explain what you're seeing. One thing I can try is do a partial socket close, which would send a close request to the downloader but give them a chance to receive the last bit of data, which may or may not make a difference. I'll post a version later tonight that does this, and if that doesn't do the trick I'll make sure there's a working timeout for the situation that will ensure you don't have to wait very long at the end of each upload.

As for uploading being choppy, I'm seeing this as well. It might be the result of sending too little information at a time (8k right now), so I'm gonna try upping that soon.

Submitted by audiophilepj on Fri, 06/24/2011 - 23:59.

I uninstalled QT Cocoa completely, and installed QT Carbon. Installed QT Public Build 4, same crashing issue. Installed QT nightly build 6/24, crashes. Installed QT-audiophilepj, hangs after 100%, a few downloads complete, but hangs on some. I even got a few crashes after it reaches 100% on QT-audiophilepj now?

Breath in..... breath out....

I apologize for the bad news.

Back to QT Cocoa with QT-audiophilepj? It ran all day without a crash. Uploading is a mess, but no crashes.

I'll keep experimenting. Keep up the hard work. If you get frustrated, take a few days off :)

Thanks Nir!

Submitted by Nir on Sun, 06/26/2011 - 03:39.

I really appreciate all your help with hunting these bugs down. A lot of this stuff may very well indicate problems that have existed in the original Soulseek client and that have mystified me for a very long time, namely the tendency of some networks/operating systems/routers not to properly handle connection closure or connection attempt timeout. Thankfully some of these issues eventually started popping up in my Mac virtual machine which made it easier to test. I've made quite a few changes already, all of them significant improvements to the reliability of the upload system that I can only hope will address the problems you're experiencing. At this point I seem to be able to upload large numbers of files from the Mac client to another client running on a different ISP without any issues. I wouldn't be surprised if any of these changes will trigger new crashes on your machine, in which case feel free to post new crash reports if you're not thoroughly sick of this already :)

SoulseekQT-audiophilepj2.zip

Thanks! Nir

Submitted by audiophilepj on Sun, 06/26/2011 - 11:17.

Victory. The latest version uploads flawlessly. 100% -> complete in a second!

I was getting very concerned. I have Ubuntu installed dual boot on my MacBook Pro. I installed the Linux version and it was uploading fine. That made me believe it was a Qt thing. I tried every Qt library and framework, I even installed the SDK 1.1.2 (libraries,creator,development tools). It was still hanging at 100%.

I just uploaded 30 files, no issues. All of their status popped to complete within seconds.

I think you got it. I can't thank you enough for your time. Odd thing is... I don't mind tinkering with Qt, and enjoy it. I look forward to more features :)

Submitted by Nir on Sun, 06/26/2011 - 22:04.

That's really great to hear! A lot of these fixes should help with the versions for the other platforms as well. I know what you mean about Qt, there's something about the straightforwardness of it that makes dealing with it fun even when it misbehaves ;)