-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot send nor receive messages #19
Comments
There's been a bunch of work recently to fix this. Can you try again with a new libyahoo-plusplus.dll download from http://eion.robbmob.com/libyahoo-plusplus.dll |
Thanks, I'll check it. It would be nice to have some sort of notification that a new version is available without tracking everything that happens on git. Pidgin is used by end-users as well, not only by developers :) |
OK, several things:
Interestingly, if I try to message one of the "dead" contacts via messenger.yahoo.com, it is smart enough to send the message to the corresponding "live" one.
I will provide a (sanitized) log on request. |
A buddy just messaged me. Instead of appearing under the buddy's ID, a new ID was created and added (as a group) Those "groups" seem to be persistent and only provide the 28-character ids. |
It seems like it is possible to figure out which live contacts the dead contacts should be replaced with. I have 3 contacts for the same buddy, one live and two dead. Yahoo tells me that there are 2 groups, the first contains the 1st and the 2nd contacts and the second contains the 1st and the 3rd contact, with the 1st contact being the default for both. The contacts (sanitized):
The groups:
Interestingly, when the 1st (live) contact sent me a message, it appeared in the conversation of the 1st group, even though I was able to concurrently converse with them in another conversation (with their user name). Hope that helps. |
Harmless, ignore.
Yes, we drop that intentionally, it would be annoying to repeat the messages on every login.
This would be more useful with the preceding frame.
Known issue, likely harmless. |
Shouldn't be an assert then :)
I use Pidgin in multiple locations. It is very inconvenient to continue a conversation that was started in another location without having access to the context. What is "annoying" to some is a n extremely useful feature for others. Having an option to enable/disable it would be best.
Here it is:
It's growing. 250 SynchBatch messages after a message, Does the native client do that as well? |
What dequis means is that the plugin records the last received message timestamp for that instance of pidgin, it should still be syncing messages accross all endpoints That |
I am not sure I follow. When I just added the Y2016 account, a lot of my old conversations (which were made on the old Yahoo account) appeared in the log, but were not shown to me when I opened a conversation window with the buddies. If the timestamp is per-conversation, I should have been shown the history. If the timestamp is global, it's the wrong approach. Incidentally, it seems that Yahoo were serious when they said the new protocol is "conversation-centric". Every time somebody starts a new conversation with you instead of continuing a previous one, it creates a new (group) contact. The native and web clients hide this but Pidgin creates another buddy that is identified only by a 26-character id. |
The conversations were with people that I talked with before (on the old Yahoo protocol). However, as I mentioned above, Pidgin presented me with two or more buddies for each person I conversed with. Some of those buddies were "dead", in the sense that I couldn't send messages to them via Pidgin. If I tried to send a message to those IDs via the web interface, it rerouted them to the "live" ids instead. |
Are there any MutationResponse's in the initial list that associate the dead ids with the not dead ones? |
I can't find the string "mutation" in the log, but I did some digging and found some connection between them. I can email you the (slightly sanitized) JSONs of the initial lists if it will help. |
Oh dammit, so there's a legitimate reason to skip messages based on timestamps. Annoying. That method was causing random message loss because yahoo is random, and others were complaining about disk usage spikes. Just forget about multiple client support for now, we'd prefer to focus on basic functionality. Really not the moment to address every single nitpick when we can barely send and receive messages. Stupid deceptively simple protocol. |
One step at the time. If you need help with beta testing, I can try. |
Can you test again with the latest revision? |
The duplicated and "dead" buddies? Yes, still getting them. |
Is that the only remaining issue out of everything that was mentioned here? Should we just merge this with #2? EDIT: can you email a new, full, minimally sanitized log? (ideally just removing the password). I'm |
email sent |
Any luck? |
Any progress? |
When I connect to the protocol, it sends me a huge amount of data which looks like my whole conversation history. Then a large number of SyncBatch messages. Then some assertions (
g_log: purple_ssl_read: assertion
data != NULL' failed`) as it writes the accounts.xml file.Messages sent to me do not arrive.
Trying to send messages gives the following in the debug window:
The text was updated successfully, but these errors were encountered: