Search don't work

[felipe augusto]

I update nicotine+ to version 1.2.13, but after this, the search do not work anymore, I get no error messages. All other things work correctly, download, upload, chat, list share, private chat.

I use nicotine+ in a debian box and python-2.5

[anonymous]

For me it still works, Offhand tested it on his Windows machine and it worked too. In #478 Nick said it didn't work on his Windows machine anymore either after r1180, and you're running Linux.

So, it doesn't seem to be OS dependent. And this problem does seem to exist on some configurations.

Since I cannot reproduce it it's a bit tricky to track down. Some questions:

• Do you get any errors in the console/terminal?
• Are you connected to the old server or the new one?

[OffHand]

I will test the OS X build tonight.

[mrgil23@…]

I also get no search results in 1.2.13. In 1.2.12 on the same box, I get lots of search results. One symptom going along with this is that the number of connections (x/921 at the bottom of the screen) changes very slowly in 1.2.13. In 1.2.12 the x number of connections changes very rapidly.

I am running Sidux on an AMD 4850e processor, 2 GB RAM, SATA HD.

[anonymous]

Hopefull I'm not hijacking, just providing more information...

Here, I am connected to the new server, use python 2.5.4, and get this error message on the console:

.../nicotine+-1.2.13/pynicotine/gtkgui/frame.py:798: GtkWarning?: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed

loader.write(data, len(data))

in addition to GeoIP, Mutagen and libsexy not being found (I don't use them).

[mrgil23@…]

Oh, that last msg was me, forgot to change the anonymous. :-(

[quinox]

NP, I forget to login as well.

The GtkWarning? can be safely ignored (I'll fix it anyway)

You really should install Mutagen for the sake of the network - it's not for you but for everybody else :)

This is getting a bit strange. Thanks everybody for reporting (keep 'em coming), once this problem is tracked down and fixed we'll put 1.2.14 out

[anonymous]

I'm blind here, but I'll examine the report that this all started after r1180 - It's not entirely farfetched actually, I came across a fileshare bug that also dealt with <Q and <L. Now now I have to do stuff but tonight I'll make a special version for you people with problems. Please check back in 10 hours or so

[Nick Voronin <elfy.nv@…>]

Nope, no errors. And looking at captured packets I get a feeling (I'm not sure) that no response to search request is in place (which would explain lack of error messages as well). This makes malformed search request main culprit. :)

[OffHand]

It doesn't work on my Ubuntu 9.04 box anymore either...

[quinox]

I think we've located the problem and we're working on a solution, probably done by the end of this weekend

[felipe augusto]

Replying to anonymous:

For me it still works, Offhand tested it on his Windows machine and it worked too. In #478 Nick said it didn't work on his Windows machine anymore either after r1180, and you're running Linux. So, it doesn't seem to be OS dependent. And this problem does seem to exist on some configurations. Since I cannot reproduce it it's a bit tricky to track down. Some questions: * Do you get any errors in the console/terminal? * Are you connected to the old server or the new one?

no message errors, I am using this server, server.slsknet.org:2242

[felipe augusto]

I change it to sk6.slsknet.org:2242 but I get no results in search.

[anonymous]

Replying to felipe augusto:

I change it to sk6.slsknet.org:2242 but I get no results in search.

problems with old config files, I del all old config files, restart it, and all come back to normality.

[quinox]

Please try r1254, I think that should solve the matter

Based on my experiments yesterday with the help of OffHand and ><((((*> I've discovered Python uses diff. types for the value 2**31-1. On my system they are regarded as integers, on their systems as longs. Without going into details, this caused n+ to encode them into different bytes, breaking the search for those with longs.

[offHand]

It's working for me again!

[mrgil23@…]

r1254 works for me, too. Thanks!

[quinox]

Great. The change in code that triggered this behaviour might have broken other things. Should you come across anything that refuses to work please let us know!

[anonymous]

Hi,

I've been using nicotine+ 1.2.13 OSX Release Candidate for all of a few hours, the first few hours seemed to be working a treat, and i thank you you all very much for your dedication to such a project. However, now my searches aren't working - I am getting the: Exception during parsing FileSearchResult?: unpack requires a string argument length of 4 ( sometimes - trying to unpack <typ 'int' at "" followed by a 7 digit number/random port number? I'm sorry to say I'm a complete newbie but am so greatful for the fact there is active development going on so i wanted to report and hopefully learn.

[quinox]

You're right, the 1.2.14 RC .App for OSX was created before I fixed this problem and in theory has the problem mentioned in this bug - apparently in practice too. Thanks for bringing this up.

We had some trouble packing 1.2.14 final version because of a bug in Python triggered by our new browselist code. I'll ask our OSX packer to try again, if he still can't create the .App I'll make a special version without the new userbrowse code but with the search problem fixed. Please check back in a few days

[offhand]

I will check if MacPorts? has been fixed this weekend. If it is I can build a new version.

[quinox]

Offhand tried to get MacPorts? working but it's borked on his system (thanks for trying!)

But I just remember I can simply unpack the .app, fix the problem and repack it - Will do so tomorrow

[quinox]

I've hacked the RC .App with the backported fix, please try  RC2 and let us know if this runs and fixes your problem.

[quinox]

I found this on my blog today:

First of all, I noted the very next day that you and your colleague had almost immediately replied to me and so I tried to write back to you to thank you profusely for setting up my hope reflex again...however... it turns out that Akismet despises me... and I do not know how to placate it / This met creature will not let me post a reply (Submission rejected as potential spam). I have tried to reply on a number of occasions now but as I just mentioned Akismet will have none of it, so I felt I HAD to google you in order to let you know that I have been using the RC2 since yesterday and it does the job indeed! So, to get back to the point I wish to make, thank you profusely for being the heroes you so obviously are!

Problem solved (once again) :)

[quinox]

More of the same:

17:09:57 pynicotine.slskmessages.FolderContentsResponse? unpack requires a string argument of length 8 trying to unpack <type 'long'> at ' ' ' ' at 65815/628 17:09:58 There was an error while unpacking Peer message type FolderContentsResponse? size 227 contents '<cut>'

It needs the same treatment as r1289

[anonymous]

Fix committed with r1357, OffHand can you verify it?