Closed ComodoHacker closed 4 months ago
Perhaps your users are corporate users or your software is not in C++? I don't imagine users of mass software like Telegram to let someone access their computer and install IDE and whatnot to debug the issue
Well, you were mentioning flatpak,
I initially observed the issue in flatpak, but I've now been using (for quite a few days) the official static binary downloaded from https://telegram.org/ and still observe the issue.
I have re-read the entire thread and there is not a single report of anyone affected saying that disconnecting and reconnecting to the network works as a workaround. On the contrary, one or two users seem to report that that triggers the issue. The only workarounds that have been reported to work are (i) restarting Telegram and (ii) changing some network setting in Telegram back and forth (proxies and the like). The only one who ever mentioned disconnecting and reconnecting to the network as a workaround is you, but you also say you cannot reproduce the issue.
I don't want to argue with you. I just have described two approaches that don't require IDE installation and don't depend on the tech (C++, web, Unity, etc.), both of them actually work with any kind of software and customers of all types.
On Tue, Mar 26, 2024, 22:06 ilya-fedin @.***> wrote:
Perhaps your users are corporate users or your software is not in C++? I don't imagine users of mass software like Telegram to let someone access their computer and install IDE and whatnot to debug the issue
— Reply to this email directly, view it on GitHub https://github.com/telegramdesktop/tdesktop/issues/16093#issuecomment-2020684783, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7I7EOTZWWLZNL4NXZJBLY2GFGLAVCNFSM42MITAL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGA3DQNBXHAZQ . You are receiving this because you commented.Message ID: @.***>
I have re-read the entire thread and there is not a single report of anyone affected saying that disconnecting and reconnecting to the network works as a workaround.
Yeah, that's the point, I asked whether that helps but no one (except of you so far) has answered the question to help with debugging. Back in the time, the only person answered that it's more actions to do but no information whether this helps or not, thus not helping with debugging. You folks require to do advanced actions to debug the issue but prefer to ignore already asked questions.
There are like 31 participants in the issue and no one answered the question in a half of the year. An answer from one person is not enough, though, maybe it's just for you, the more people answer the question the better.
What was the question? Could you please ask it again?
On Tue, Mar 26, 2024, 22:16 ilya-fedin @.***> wrote:
There's like 31 participants in the issue and no one answered the question in a half of the year. An answer from one person is not enough, though, maybe it's just for you, the more people answer the question the better.
— Reply to this email directly, view it on GitHub https://github.com/telegramdesktop/tdesktop/issues/16093#issuecomment-2020714197, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7I7GTUZ6JEQERI3TF2ILY2GGOBAVCNFSM42MITAL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGA3TCNBRHE3Q . You are receiving this because you commented.Message ID: @.***>
I only get this behaviour after sleep (a long sleep most probably, could be hours or days). Can't check right now if i had flatpak or static binary in this machine. Totally closing and reopening Telegram fixes it for me every time.
Yeah, we already know that totally closing helps. But that's not the information needed.
Oh, I missed that.
As soon as I run into the issue again, I'll let you know.
On Tue, Mar 26, 2024 at 10:20 PM ilya-fedin @.***> wrote:
here it is: #16093 (comment) https://github.com/telegramdesktop/tdesktop/issues/16093#issuecomment-1616677821
— Reply to this email directly, view it on GitHub https://github.com/telegramdesktop/tdesktop/issues/16093#issuecomment-2020726363, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7I7FVULJFNQTF33V5CIDY2GG4XAVCNFSM42MITAL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGA3TENRTGYZQ . You are receiving this because you commented.Message ID: @.***>
You haven't missed that, you was the person saying it's more actions to do, right after the message ;)
Could you please elaborate what the “system” means? Mac is connected to Wi-Fi, what should I do to answer your question? (when I will face issue again) Toggling Wi-Fi in tray?
Yeah, toggle wifi off and on. Or click on the network name and it should have disconnect button (assuming mac's UI is similar to other OS).
I meant I missed that it was a valid debug question, not a trolling one.
Message ID: @.***>
There are like 31 participants in the issue and no one answered the question in a half of the year. An answer from one person is not enough, though, maybe it's just for you, the more people answer the question the better.
here it is: #16093 (comment)
@ilya-fedin I think there are two reasons your question get ignored:
If you were asking if toggling the network off and on works as a workaround, then yes for me (I'm on Telegram Desktop v4.15.2, MacOS 13.6.2).
As one of the user enjoy this software for free, I appreciate every contributor's effort. Feel free to state any instructions that may help to debug and I'll try my best when possible.
If you were asking if toggling the network off and on works as a workaround, then yes for me (I'm on Telegram Desktop v4.15.2, MacOS 13.6.2).
Yeah, that's what I asked. Thanks.
Switching on and off helped me as well.
First observation: connection was normally restored after overnight sleep in home wi-fi, but failed to automatically reconnect to the office WiFi.
M2, MacOS Sonoma 14.2.1, Telegram Desktop 4.15.2
Another observation: oftentimes Telegram Desktop struggles with sending/receiving media on office WiFi, while the web version sends and receives files without delays.
I can perform ping/tracert or anything like that in order to debug network connectivity issues if needed.
On Wed, Mar 27, 2024 at 11:06 AM ilya-fedin @.***> wrote:
If you were asking if toggling the network off and on works as a workaround, then yes for me (I'm on Telegram Desktop v4.15.2, MacOS 13.6.2).
Yeah, that's what I asked. Thanks.
— Reply to this email directly, view it on GitHub https://github.com/telegramdesktop/tdesktop/issues/16093#issuecomment-2021884710, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG7I7A7XWMWEFMI4O3WH4DY2JAS7AVCNFSM42MITAL2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGE4DQNBXGEYA . You are receiving this because you commented.Message ID: @.***>
Today I tested resuming from long sleep. Telegram didn't update messages, it showed some old messages but only partly. Nothing indicated that it didn't have network connection (it didn't say reconnecting or anything else), it only looked like it was online, except it wasn't....After a couple of minutes it did start to update messages and went back online and was really up to date again.
I'll have to try and see that if I'm patient enough, does it come back online each time when it looks like it's offline. Usually I've just restarted Telegram and it immediately starts updating then.
Maybe we can add some sort of telemetry to track how many times particular users trigger "Settings->Advansed->Connection type" back and forth? Or even better, add "reconnect" button as suggested above + add telemetry to it.
I recall one year ago I had to trigger it a couple of times a day, now things got a lot better but still have to do it eventually. Telemetry could give us a better image of what's going on and how broad the issue is.
Today my computer resumed from sleep and Telegram didn't connect. I was home, so the computer went to sleep on the same network it woke up to many hours later.
I will try connecting to another network (like going to sleep connected to the 5GHz then changing to the 2,4GHz one after Telegram gets stuck) and also connecting to a entirely different network, such as sharing my phone's cellular network.
Maybe we can add some sort of telemetry
This can be hard due to privacy concerns and might not help much because you would need to store more information to find a pattern of affected users... Telemetry can be hard to implement on some countries.
Can't you just periodically check if you are able to connect, and if you are not (which clearly you are able to detect, as you display the "connecting..." text and spinning icon), then trigger whatever same things you do when network-related Telegram settings get changed, which always succeed in reconnecting?
If you are solely relying on "events", that's a wrong design anyway (even if you fix whatever issue is currently causing you to miss events almost systematically when resuming from sleep), because there's always a possibility that you "miss" an event, however rare that may be, and you cannot let that prevent you from reconnecting for ages. I mean of course you have to listen for the events, so that you reconnect immediately when possible, but you have to do some kind of periodic check anyway as a backup or fallback mechanism. Are you not doing that, or is that also failing for some reason?
@php4fan Yeah, it should reconnect by timeout from scratch, but there is a bug.
Can't you just periodically check if you are able to connect, and if you are not (which clearly you are able to detect, as you display the "connecting..." text and spinning icon), then trigger whatever same things you do when network-related Telegram settings get changed, which always succeed in reconnecting?
Yeah, I guess that's what was happening back in the time when tdesktop was using Qt 5. Qt 5 had so called "session management" and "bearer manager". Those things were kind of watchdog, they were checking network connection every multiple seconds and if it changes, Qt was resetting all the connections. It's possible this was masking a bug in tdesktop code: even if tdesktop's connect-wait-connect loop had some race conditions in event handling all this time (it apparently misses some error from the socket so it thinks it still waits the answer and doesn't re-schedule the next attempt), Qt was resetting the connection and re-triggering the events which was leading to the issue being masked. Since Qt 6, this is no more a thing. If someone would check 3.1.9 (the last version using Qt 5.15) and 3.1.10 (the first version using Qt 6, 6.2 precisely) and confirm 3.1.10 is the first bad version, we can conclude the Qt 5 -> 6 update is the cause.
It also seems that @php4fan's problem is a little bit different. @php4fan do you use NetworkManager?
I also wonder is there anyone affected on Windows nowadays? It still uses Qt 5.15. @pH142857 @ComodoHacker @Dron007 do you still have the issue?
@ilya-fedin I haven't noticed this issue for a long time on Win 10. As far as I know on Win7 this was not reproduced too.
@ilya-fedin I don't have this issue too. Can't tell how long, about two years probably.
It also seems that @php4fan's problem is a little bit different.
In what way?
@php4fan do you use NetworkManager?
Yes, I think so
In what way?
Network (dis)connection events don't work on your system.
Yes, I think so
Provide the result of ps aux | grep -e dbus -e NetworkManager
Network (dis)connection events don't work on your system.
What do you mean by that?
What I observe is that when I resume from sleep, Telegram fails to reconnect, just like most(*) other users report, and after that, disconnecting and reconnecting to network doesn't fix the issue, and this part is true for absolutely everyone else so far.
(*) That is except for a couple users who seem to report that the same happens after disconnecting and reconnecting without any sleep. That part is not true for me (just like most other reporters), and that actually suggests to me that network events normally work fine, when there's no sleep/resume involved.
Provide the result of ps aux | grep -e dbus -e NetworkManager
ps aux |grep NetworkManager
root 512 0.0 0.1 489668 26288 ? Ssl Mar25 1:03 /usr/bin/NetworkManager --no-daemon
teo 48421 0.0 0.0 6588 2432 pts/3 S+ 18:03 0:00 grep NetworkManager
and this part is true for absolutely everyone else so far.
Everyone else has said that disconnection and reconnection helps. You're the only one who says it doesn't help.
ps aux |grep NetworkManager
That is not the command I asked to provide the result of. Please provide the result of the command I asked.
and this part is true for absolutely everyone else so far.
Everyone else has said that disconnection and reconnection helps. You're the only one who says it doesn't help.
I was wrong about that but you are too.
@rafaelsms says:
- Disconnecting from my home network, waiting a few seconds and reconnecting to the same network didn't work for me. (Telegram did know it was offline when I disconnected, it showed the loader spinning in the left bottom corner and the loader went away when reconnecting to the network, it just didn't update)
- Disabling the entire Wi-Fi network adapter, waiting a few seconds, re-enabling it and then reconnecting to the same network did update Telegram (the preloader was shown like before, but it did update after going away).
BTW I am usually connected to two networks: an ethernet one via a USB-to-Ethernet adapter, and a WiFi via the laptop's built-in wifi interface. Whenever I disconnect and reconnect I do both: the Ethernet one by physically unplugging and plugging the USB-Eth adapter, and the Wifi via software using the tray-icon network widget.
That is not the command I asked
Sorry
ps aux | grep -e dbus -e NetworkManager
dbus 510 0.0 0.0 10820 2220 ? Ss Mar25 0:00 /usr/bin/dbus-broker-launch --scope system --audit
dbus 511 0.0 0.0 6412 2860 ? S Mar25 0:17 dbus-broker --log 4 --controller 9 --machine-id 65c2167a92164a6ba5f5a314559e5142 --max-bytes 536870912 --max-fds 4096 --max-matches 131072 --audit
root 512 0.0 0.0 489668 12592 ? Ssl Mar25 1:05 /usr/bin/NetworkManager --no-daemon
teo 642 0.0 0.0 9000 1376 ? Ss Mar25 0:00 /usr/bin/dbus-broker-launch --scope user
teo 643 0.0 0.0 5852 2304 ? S Mar25 0:02 dbus-broker --log 4 --controller 10 --machine-id 65c2167a92164a6ba5f5a314559e5142 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000
teo 819 0.0 0.0 230120 6544 ? Ssl Mar25 0:13 /usr/bin/gmenudbusmenuproxy
teo 1424 0.0 0.0 8868 1280 ? S Mar25 0:00 /usr/bin/dbus-broker-launch --config-file=/usr/share/defaults/at-spi2/accessibility.conf --scope user
teo 1425 0.0 0.0 4144 1152 ? S Mar25 0:02 dbus-broker --log 4 --controller 9 --machine-id 65c2167a92164a6ba5f5a314559e5142 --max-bytes 100000000000000 --max-fds 6400000 --max-matches 5000000000
teo 49879 0.0 0.0 6588 2244 pts/4 S+ 18:55 0:00 grep -e dbus -e NetworkManager
@rafaelsms says:
Well, it didn't work in his sense but I read it as the event has delivered given that the spinner has disappeared.
Whenever I disconnect and reconnect I do both: the Ethernet one by physically unplugging and plugging the USB-Eth adapter, and the Wifi via software using the tray-icon network widget.
Simultaneously or one after other? Is there a period of time when there's no connection at all?
Simultaneously or one after other? Is there a period of time when there's no connection at all?
I think I did it like this: disconnected both (don't know in which order), made sure there was no connection, and then reconnected both (again in random order). But I cannot swear with 100% certainty.
Provide the result of env | grep -e GTK -e GDK
Provide the result of env | grep -e GTK -e GDK
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/teo/.gtkrc-2.0:/home/teo/.config/gtkrc-2.0
GTK3_MODULES=xapp-gtk3-module
GTK_MODULES=canberra-gtk-module
GTK_RC_FILES=/etc/gtk/gtkrc:/home/teo/.gtkrc:/home/teo/.config/gtkrc
@php4fan what is the result of LANG=C nmcli g
when you're connected and when you're disconnected?
If someone would check 3.1.9 (the last version using Qt 5.15) and 3.1.10 (the first version using Qt 6, 6.2 precisely) and confirm 3.1.10 is the first bad version
I've installed 3.1.9 and I hadn't encountered any connection issues after two long sleeps so far. I will keep testing it for a full day or two before updating to 3.1.10. @ilya-fedin Thanks for looking into this issue!
Faced the issue today, by the way randomly by closing mac for 10 min. Switching off/on wi-fi network didn't work, but then instead of toggling after 3 sec, after several attempts, I decided to wait fot 20+ sec before enabling, and eventaully it worked.
@rafaelsms @MasterOfTouch what's your OS version?
Sonoma 14.4.1 (23E224)
Sonoma 14.4.1 (23E224)
Same
@php4fan what is the result of LANG=C nmcli g when you're connected and when you're disconnected?
When connected:
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled missing enabled
When disconnected:
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
disconnected none enabled enabled missing enabled
@php4fan would you be able to build tdesktop from sources with additional logging?
@php4fan would you be able to build tdesktop from sources with additional logging?
I can try
Try to build this patch, does it print the line when you disconnect/connect?
diff --git a/Telegram/SourceFiles/mtproto/mtp_instance.cpp b/Telegram/SourceFiles/mtproto/mtp_instance.cpp
index 7a9908d992..529f9a6e72 100644
--- a/Telegram/SourceFiles/mtproto/mtp_instance.cpp
+++ b/Telegram/SourceFiles/mtproto/mtp_instance.cpp
@@ -321,6 +321,7 @@ Instance::Private::Private(
_networkReachability->availableChanges(
) | rpl::start_with_next([=](bool available) {
+ LOG(("Network available: %1").arg(Logs::b(available)));
restart();
}, _lifetime);
I've installed 3.1.9 and I hadn't encountered any connection issues after two long sleeps so far. I will keep testing it for a full day or two before updating to 3.1.10
3.1.9 worked very well and it reconnected every time my computer woke from sleep.
Yesterday I've installed 3.1.10. Today, on my second wake from sleep it didn't reconnect. This time, the loader on the left bottom corner didn't even react to the Wifi network adapter being disabled/enabled (unlike the most recent version I used before starting these tests).
So Qt 6 is the cause. Downgrading to Qt 5 sounds impossible so we're back to where we were: this needs debugging but no developer could reproduce this.
It would be great if you could add an interval timer that, when it detects a loss of connection in one of several ways, could begin reconnecting. It will be better than nothing.
@RblSb it already reconnects on connection loss. As you can see, it bugs.
I wonder if there may be multiple different issues here. I've been having the issue of Telegram's UI becoming unresponsive after a while since 4.10, and the current version 4.14 is using Qt5 so it can't be caused by Qt6.
Steps to reproduce
Expected behaviour
Main window shows up.
Actual behaviour
No response.
This happens often, but not every time, and started about 2-3 months ago.
Configuration
Operating system: Windows 7 [Version 6.1.7600]
Version of Telegram Desktop: 2.7.1
Used theme: Default
Logs:
[log_freeze.zip](https://github.com/telegramdesktop/tdesktop/files/6256569/log_freeze.zip) Screenshot from Process Explorer: ![Telegram_process](https://user-images.githubusercontent.com/3299815/113542506-df446c80-95fd-11eb-8336-24592bf7ef2b.jpg)