Tdesktop: Incorrect count notifications

[WiRight]

Steps to reproduce

1. Install TDesktop on new machine
2. In tray i see 1 or more unread messages (but no one exist)

Expected behaviour

No one notify (0)

Actual behaviour

1 or more show

Configuration

Operating system:
Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

Version of Telegram Desktop:
1.5.4

Used theme:
Standard

[RememberTheAir]

I've had a similar problem on 1.5.4 too. The unread counter was showing one notification less than the actual count (eg. with no unread messages, the tray icon counter was showing "-1"). This both on Linux Mint and Windows 10. I've tdesktop set up to count the chats (and not the number of messages), and only non-muted chats. I don't know how to reproduce

[biancofla]

Same issue here. Currently, I'm on Ubuntu 16.04 with Telegram 1.5.4 and the tray icon shows constantly one unread message, even if no one is really present.

[theimaginationless]

Same here on Ubuntu 16.04

[WiRight]

Reproduce it on ArchLinux.
After install TDesktop, i haven't read some messages (7 items) and reboot my system.
After start in tray TDesktop always showing const value 7 unreaded messages
Edit: __even if you read__

[emilengler]

Same issue here on Ubuntu 18.04

[martinaglv]

I can confirm this bug on multiple Ubuntu 16.04 and 18.04 machines. I have narrowed it down to this function, but I don't know enough QT to debug nor fix it.

Basically what happens is that this code generates an incorrect tray icon. These icons are cached in ~/.local/share/TelegramDesktop/tdata/ticons:

WORKAROUND

Just make a copy of the clean icon, rename it to icomute_22_0.png and the correct icon should show up. As these aren't generated again if they exist, the bug should be fixed for good.

5501, #5487, #5280

[WiRight]

@martinaglv Thx! That fix me it for now!
But in new machine bug will be reproduced

[emilengler]

@martinaglv I'm not sure but I think you mean the _trayIconImageFile() function.
Because of the filenames.

[biancofla]

After a research in the commits history, I've found this: https://github.com/telegramdesktop/tdesktop/commit/0f67f75bed0cc12f354450ffd032e8bdeaa4f15a. This specific commit seems to be the initial cause of the broken tray icon.

[martinaglv]

@biancofla thank you for tracking it down! Maybe @john-preston has an idea how to fix this.

[emilengler]

I created #5556.
This basically undo the change on how the message counter is incremented and should hopefully work and fix the bug.

EDIT:
Probably this commit didn't broke the badge message counter

[RafaelKr]

The workaround from @martinaglv does it for me. The icon has the correct name, but the image is wrong.

This means, that the image is generated with a wrong message count.

I'm not that experienced in C++, but I'm pretty sure he also pointed to the correct function: https://github.com/telegramdesktop/tdesktop/blob/61add763aeb0775984c3a073ac50e7f35eebe6e9/Telegram/SourceFiles/platform/linux/main_window_linux.cpp#L73-L124

I can imagine the following order of events are causing this bug:

1. _trayIconImageFile (L114) is called.
2. It defines the variables counter, muted state and counterSlice (L115 - L117)
3. The icon name is created with the loaded variables: icomute_22_0.png (L119)
4. L121 is checking if the file exists and at the time this bug occures it DOESN'T
5. Now the _trayIconImageGen function is called.
6. This is why the bug occures:
   Instead of passing the variables counter, muted state and counterSlice they are loaded AGAIN (L74-L77). Meanwhile a new message came in between step 2 and 6 (this step). So the values differ from the values of step 2 and the icon is generated with the wrong counter badge.
7. _trayIconImageGen returns the "wrong" image which is saved in L124 with the name created in step 3 (icomute_22_0.png).

So I think the easy solution is to pass counter, muted and counterSlice as parameters to _trayIconImageGen. This should be no problem as L123 is the only place where this function is called.

@john-preston what do you think? Is this correct? Do you want to fix it or should I?

Edit: If my assumptions are correct, I know how to fix that the error doesn't occur again. However I don't know how to fix an already wrongly generated icon.

[WiRight]

@RafaelKr > However I don't know how to fix an already wrongly generated icon.

Clear icons cache?)

[RafaelKr]

@WiRight I know what to do, but not what's the best way for it.
I think it's not the best idea to do this after each startup, I think it's better to do this just after an update. But I don't know the best way to check that.

[john-preston]

@RafaelKr This should not happen, because all code, working with Messenger::Instance().unreadBadge() / unreadBadgeMuted() happens in the main thread (both changing them on the new message arrival and reading them for _trayIconImageGen). So between generating file name and the image for that file nothing should happen with unread badge - this is a single threaded thing from the unreadBadge() point of view.

[john-preston]

But now I guess I see the bug. If _trayIconCount is equal to counterSlice, then we don't generate a new icon, but take the one we have generated last time.

But this _trayIconCount is never set to counterSlice after we generated the icon. So first we have the _trayIconImage generated with non-zero counter and then we get counterSlice equal to zero equal to _trayIconCount, so we just use the non-zero _trayIconImage.

Thanks @RafaelKr, your assumption was not correct, but this was the correct piece of code to search for the bug. I'll fix that in the next release.