Opened 9 years ago

Closed 9 years ago

#11597 closed defect (worksforme)

Buddies appear several times

Reported by: csaba.juhos Owned by: marv
Milestone: Component: Yahoo!/Yahoo! JAPAN
Version: 2.6.6 Keywords: buddies friends several times more than once
Cc:

Description

Hi,

I have a single Yahoo! account configured. All of my buddies in a particular group appear 33 times.

I'm experiencing this on two different systems. I can provide more info upon request.

Thanks,
Csabi

Change History (12)

comment:1 Changed 9 years ago by datallah

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
Please attach the debug log from when you sign onto the problematic account.

comment:2 Changed 9 years ago by rekkanoryo

If you can attach the blist.xml file from your .purple directory, that might be helful as well. You should be careful to sanitize the file if you attach it directly here. If you wish, you can e-mail it directly to me at rekkanoryo@… instead.

comment:3 follow-up: Changed 9 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:4 in reply to: ↑ 3 Changed 9 years ago by csaba.juhos

Replying to trac-robot:

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

Please reopen the ticket. I've sent the required info directly to rekkanoryo.

Thanks,
Csabi

comment:5 Changed 9 years ago by rekkanoryo

  • Status changed from closed to new

comment:6 follow-up: Changed 9 years ago by rekkanoryo

  • Owner changed from sulabh.dev to marv

I must be missing something, as I don't see any duplicated buddies in either the debug log or the blist.xml I received. What I *do* see is us not handling something correctly from the server. It looks as if several of the buddies on the list are ungrouped, but as far as I know that should not be possible, even if the list is split into multiple YMSG packets. Looking at the relevant code paths, I'm not entirely sure what to do to fix it.

marv, any ideas would be appreciated.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 9 years ago by csaba.juhos

Replying to rekkanoryo:

I must be missing something, as I don't see any duplicated buddies in either the debug log or the blist.xml I received. What I *do* see is us not handling something correctly from the server. It looks as if several of the buddies on the list are ungrouped, but as far as I know that should not be possible, even if the list is split into multiple YMSG packets. Looking at the relevant code paths, I'm not entirely sure what to do to fix it.

marv, any ideas would be appreciated.

Hi rekkanoryo,

There are duplicated entries in blist.xml:

$ grep juhoz1024 blist.xml | wc -l
28

juhoz1024 is a buddy in the "Buddies" group. In my current blist.xml it appears 31 times.

I've also noticed that all duplicated contacts always appear offline.

I've also found that moving all occurrences of a duplicated buddy to another group eliminates the duplicates. The buddy appears only once in the new group and it isn't permanently offline anymore. I think this is only a workaround and expect new duplicates to appear.

I'll do a fresh install on a third system and send you the debug log. I'll also send a debug log with moving around duplicate buddies.

Csabi

P.S.: Let me know if there's anything I can do to help.

comment:8 in reply to: ↑ 7 Changed 9 years ago by erick.mendes

Hi there,

I've got exactly the same issue here... I've got a Openfire server with clients using pidgin version 2.6.5. Openfire is using OpenLDAP as DB, and we got like 30 published groups, based on AD Groups.

We started to see multiplied contacts exactly from 2 specific groups. I started to try to find a reason and discovered that these 2 groups was been published twice from different AD Groups.

Example:

Security Group "A" -> Published as group "A" on Openfire Distributin Group "A" -> Published also as group "A" on Openfire.

I found that only the users that were on the two different groups "A" (or "B") was been 'cloned' multiple times on the users contact lists. The users that were only in one of the groups "A" (also only on one group "B") was not being cloned.

So, I've depublished one copy of those groups, also deleted the blist.xml from 3 machines and now I will be monitoring these contacts behaviors on the machines where I deleted the blist and on the others, but I think that's the cause of my problem.

It's not exactly your problem, but I hope it shed some light on it.

comment:9 follow-up: Changed 9 years ago by csaba.juhos

Hi guys,

It turned out that mine wasn't a Pidgin issue.
Thanks for your time and support.

Have a nice day,
Csabi

comment:10 in reply to: ↑ 9 ; follow-up: Changed 9 years ago by rekkanoryo

  • Status changed from new to pending

Replying to csaba.juhos:

It turned out that mine wasn't a Pidgin issue.
Thanks for your time and support.


What did your issue turn out to be?

comment:11 in reply to: ↑ 10 Changed 9 years ago by csaba.juhos

  • Status changed from pending to new

Replying to rekkanoryo:

Replying to csaba.juhos:

It turned out that mine wasn't a Pidgin issue.
Thanks for your time and support.


What did your issue turn out to be?

Hi rekkanoryo,

The problem was that the group had special characters in its name. I tried renaming it with Pidgin, but I couldn't. I also tried several other client applications, like meebo and yahoo's webmessenger, but they didn't work either. So I figured that the problem must be with the messenger service itself.

I've contacted yahoo support, but they didn't offer any real help. Finally, I've managed to rename the group with a version 8 yahoo messenger and everything went back to normal.

So you see, Pidgin wasn't the issue at all.

Cheers,
Csabi

comment:12 Changed 9 years ago by rekkanoryo

  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!