Unresponsive after connecting to network

[ComodoHacker]

Steps to reproduce

1. The app is minimized to tray, no network connection
2. Go to sleep/hibernation (not sure if this matters)
3. Wake up, unlock user session
4. Connect to the Internet
5. Invoke Telegram from tray

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
Screenshot from Process Explorer:

[ilya-fedin]

This happens often, but not every time, and started about 2-3 months ago.

That's the time of Qt 5.12 -> Qt 5.15 update, so probably a Qt bug

[pH142857]

Same here on W7. Are you sure it's related to connecting to network though? The title might be wrong. I'd say it has something to do with going out of sleep mode.

[john-preston]

I hope I've fixed it, there was a deadlock in Qt 5.15 on Windows in thread management. We'll see in the next version.

[stale]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[pH142857]

Still an issue on my W7. I have to manually kill TelegramDesktop.exe each time I get out of sleep mode.

[ComodoHacker]

It started to manifest again, on 3.1.8. Log tail (note the wake-up moment):

[2021.10.23 00:26:32] RPC Error: request 73853 got fail with code 400, error CHAT_ADMIN_REQUIRED
[2021.10.23 00:26:36] RPC Error: request 73857 got fail with code 400, error CHAT_ADMIN_REQUIRED
[2021.10.23 00:26:38] RPC Error: request 73861 got fail with code 400, error CHAT_ADMIN_REQUIRED
[2021.10.23 00:33:31] API Warning: not loaded minimal channel applied.
[2021.10.23 10:48:45] Could not send ping for some seconds, restarting...
[2021.10.23 10:49:08] TCP Error: error packet received, endpoint: '149.154.175.100:443', protocolDcId: 3, code = -404
[2021.10.23 10:49:08] MTP Info: -404 error received in 10003 with temporary key, assuming it was destroyed.
[2021.10.23 10:49:53] Could not send ping for some seconds, restarting...
[2021.10.23 10:50:03] Could not send ping for some seconds, restarting...

[Dron007]

Same issue happens on 2 computers with Win7. Telegram stops getting any messages and stops updating channels after resuming from standby. It occurs maybe 1 time in 5-7 runs.

[juahan]

In Ubuntu this happens quite often for me. Not sure if this information helps at all, but I typically get it working again without needing to restart it by going into Settings->Advanced settings and switching from which ever proxy setting there is to the other (no proxy <-> system settings). After the switch it immediately starts working again.

[tjunussov]

MacOS ( MBP M1 ) same issue, every time (not sometime) after sleep, wont reconnect, unless manual switching in Network section "between proxy and go back."

[daaaaaavis]

As #17397 got closed and this was added as the duplicate issue - just wanted to +1 here.

M1 Macbook Air. After going to sleep and being woken up - Telegram is completely unresponsive unless I force close the application and open it again, after which it works just fine.

[ollebro]

Same issue, MacOS version 12.5.1, Telegram 4.1.1. After sleep telegram wont connect until I restart the application.

[ayuka-bg]

still have this issue

[jimzhong]

Still have this issue on flathub version 4.6.2 on Linux. Restarting the app solves the issue though.

[b-s-a]

regarding to issue #25895, which is closed as duplicate of this one.
mtp_19_00.txt
mtp_success.txt
I'm attaching two mtp logs. One (mtp_19_00.txt) is shown how Telegram tries to reconnect for some huge time after wake up computer from sleep and telegram fails to connect for 2 hours. I do not want to provide all later log files, because they contains same information.
Second log (mtp_success.txt) is for succeed case - 2 minutes to reconnect was taken.

[vadimk1337]

snap version of linux ubuntu 22.10 the problem is relevant

[lacek]

Having the same issue every time after putting my Macbook sleep overnight. Restarting Telegram becomes a daily routine of mine.

Telegram 4.7, MacOS 13.1.

[asze70]

Having the same problem behind an enterprise proxy. Connection type is "Use system proxy settings".
During a normal operation (Telegram using the proxy) I disabled the wifi and turned back again. Telegram failed to reconnect, stuck "Connecting". Checking Sysinternals Process Monitor it seems so that Telegram forgot to use the proxy, but was trying a direct connection forever.

[8tomat8]

I'm experiencing the same.
MacOS 13.3.1, Telegram 4.7

To restore the connection I either need to restart the entire application or go to Settings>Advanced>Connection>Toggle IPv6 to any state just to force the app into the reconnection.

[yuriifedorchuk]

+1
macOS Ventura, 13.2.1
Telegram 4.8.1

[damat]

Same issue
Air M2
Venture 13.0.1
Telegram 4.8.1

I was about to become a premium user, but switched from Win (no issues for years) to Mac. Can't imagine paying voluntary money for the app I have to manually reset several times a day.

This bug exists for over 2 years now, other messaging apps on MacOS doesn't have this issue.
Is there any good reason to ignore it for so long?

[udivankin]

Seems that it got worse last few months. I remember I had to restart/change proxy settings once a week last year, but eventually, it became a daily routine :(

MacBook Pro M1
Mac OSX 13.3.1
Telegram 4.8.1

[damat]

On my m2 any sleep, even 30 secs long, causes the disconnection. Hate it since so many work related chats are now in Telegram :(

…

On Wed, May 3, 2023, 14:33 allx ***@***.***> wrote: Seems that it got worse last few months. I remember I had to restart/change proxy settings once a week last year, but eventually, it became a daily routine :( MacBook Pro M1 Mac OSX 13.3.1 Telegram 4.8.1 — Reply to this email directly, view it on GitHub <#16093 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG7I7ATM6NOKGHN3GYBIE3XEIC3VANCNFSM42MITALQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ilya-fedin]

@php4fan would you be able to build tdesktop from sources with additional logging?

[php4fan]

@php4fan would you be able to build tdesktop from sources with additional logging?

I can try

[ilya-fedin]

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);
 

[rafaelsms]

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).

[ilya-fedin]

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.

[RblSb]

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.

[ilya-fedin]

@RblSb it already reconnects on connection loss. As you can see, it bugs.

[kcat]

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.

[ilya-fedin]

and the current version 4.14 is using Qt5 so it can't be caused by Qt6.

Perhaps you're running 3rd party build? macOS and Linux official builds use Qt 6 since since three years ago.

[kcat]

I'm using builds from the Debian repos:

$ aptitude versions telegram-desktop
Package telegram-desktop:                              
p   4.14.9+ds-1                                             testing                             750 
i   4.14.9+ds-1+b1                                          unstable                            800 

$ ldd `which telegram-desktop` | grep -i qt
        libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 (0x00007f976c325000)
        libQt5QuickWidgets.so.5 => /lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5 (0x00007f976c30f000)
        libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f9768600000)
        libQt5WaylandCompositor.so.5 => /lib/x86_64-linux-gnu/libQt5WaylandCompositor.so.5 (0x00007f976966d000)
        libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 (0x00007f9768000000)
        libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f9767800000)
        libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 (0x00007f9767200000)
        libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x00007f9769251000)
        libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f9766c00000)
        libQt5DBus.so.5 => /lib/x86_64-linux-gnu/libQt5DBus.so.5 (0x00007f975f4cf000)
        libQt5QmlModels.so.5 => /lib/x86_64-linux-gnu/libQt5QmlModels.so.5 (0x00007f975f175000)

Debian still builds it against Qt5 it seems (they didn't have Qt6 packages before, they do now but it seems Telegram Desktop is still using Qt5). Either way, that seems to suggest it's not a Qt6 issue if the unresponsiveness also happens when built against Qt5.

Though FWIW, it's also been a while since I've run Telegram Desktop and haven't tried the last few versions. I just started it up again to see if it still happens for me.

[ilya-fedin]

Either way, that seems to suggest it's not a Qt6 issue if the unresponsiveness also happens when built against Qt5.

People say 3.1.9 is good while 3.1.10 is bad, the only difference between them is Qt version

[ilya-fedin]

Moreover, bugs in third party versions might be introduced by third parties. Debian's tdesktop package is very patched as far as I'm aware, with various features being patched out. I wouldn't be surprised if their package has unique bugs. Especially since building with Qt 5 on macOS/Linux is not tested for 3 years.

[kcat]

People say 3.1.9 is good while 3.1.10 is bad, the only difference between them is Qt version

For me, 4.9 was good and the unresponsiveness only started happening with 4.10. I didn't realize Debian had so many patches, so it's understandable to think I'm experiencing an issue unique to their build. Still, the symptoms do seem similar to the original post; after a while of being idle or asleep, Telegram Desktop will randomly go unresponsive and take several moments to minutes to react to clicking its icon or anything else, seemingly also not sending or receiving any notifications, with the only way to fix it being to restart the app (where it will be fine initially, but happen again at some point).

[php4fan]

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.

@ilya-fedin Does it periodically actively check whether it's connected, and if it isn't it reconnects, or does it listen for some sort of "connection loss" events, and when it gets one it reconnects? (or both?) Sorry for asking again, but every time you reply to people suggesting the second, it sounds almost like the two are the same thing to you.

[php4fan]

Try to build this patch,

I'm getting errors when running build/prepare/linux.sh (before I even try to apply the patch):

Installing dependencies from lock file

No dependencies to install or update

Installing the current project: centos_env (0.1.0)
[+] Building 79.8s (42/144)                                                                                                               docker:default
 => [internal] load build definition from Dockerfile                                                                                                0.0s
 => => transferring dockerfile: 29.97kB                                                                                                             0.0s
 => resolve image config for docker.io/docker/dockerfile:1                                                                                          1.8s
 => docker-image://docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021                            1.7s
 => => resolve docker.io/docker/dockerfile:1@sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021                                0.0s
 => => sha256:657fcc512c7369f4cb3d94ea329150f8daf626bc838b1a1e81f1834c73ecc77e 482B / 482B                                                          0.0s
 => => sha256:a17ee7fff8f5e97b974f5b48f51647d2cf28d543f2aa6c11aaa0ea431b44bb89 1.27kB / 1.27kB                                                      0.0s
 => => sha256:9d9c93f4b00be908ab694a4df732570bced3b8a96b7515d70ff93402179ad232 11.80MB / 11.80MB                                                    1.5s
 => => sha256:ac85f380a63b13dfcefa89046420e1781752bab202122f8f50032edf31be0021 8.40kB / 8.40kB                                                      0.0s
 => => extracting sha256:9d9c93f4b00be908ab694a4df732570bced3b8a96b7515d70ff93402179ad232                                                           0.1s
 => [internal] load metadata for docker.io/library/rockylinux:8                                                                                     1.5s
 => [internal] load .dockerignore                                                                                                                   0.0s
 => => transferring context: 2B                                                                                                                     0.0s
 => [builder-base 1/5] FROM docker.io/library/rockylinux:8@sha256:c464612ef7e3d54d658c3eaa4778b5cdc990ec7a4d9ab63b0f00c9994c6ce980                  4.1s
 => => resolve docker.io/library/rockylinux:8@sha256:c464612ef7e3d54d658c3eaa4778b5cdc990ec7a4d9ab63b0f00c9994c6ce980                               0.0s
 => => sha256:c464612ef7e3d54d658c3eaa4778b5cdc990ec7a4d9ab63b0f00c9994c6ce980 547B / 547B                                                          0.0s
 => => sha256:69cecc7163282ad83e27b739fe8473b7c56e280e83827dcda60e5d37102457f1 529B / 529B                                                          0.0s
 => => sha256:4f2f5d89988fd9d647f941346cf6b37a2ec4c64b1f0bb48ff58658217a557e88 1.48kB / 1.48kB                                                      0.0s
 => => sha256:7ecefaa6bd84a24f90dbe7872f28a94e88520a07941d553579434034d9dca399 72.82MB / 72.82MB                                                    2.0s
 => => extracting sha256:7ecefaa6bd84a24f90dbe7872f28a94e88520a07941d553579434034d9dca399                                                           2.0s
 => [builder-base 2/5] RUN dnf -y install epel-release  && dnf config-manager --set-enabled powertools  && dnf -y install autoconf automake libto  57.6s
 => [builder-base 3/5] WORKDIR /usr/src/Libraries                                                                                                   0.0s 
 => [builder-base 4/5] RUN python3 -m pip install meson ninja                                                                                       1.4s 
 => [builder-base 5/5] RUN mkdir /opt/cmake  && curl -sSLo cmake-3.27.6-Linux-x86_64.sh https://github.com/Kitware/CMake/releases/download/v3.27.6  3.7s 
 => CANCELED [xcb-util 1/1] RUN git clone -b xcb-util-0.4.1 --depth=1 --recursive https://github.com/gitlab-freedesktop-mirrors/libxcb-util.git  &  7.5s 
 => CANCELED [mozjpeg 1/1] RUN git clone -b v4.1.4 --depth=1 https://github.com/mozilla/mozjpeg.git  && cd mozjpeg  && cmake -GNinja -B build .     7.8s 
 => CANCELED [libde265 1/1] RUN git clone -b v1.0.15 --depth=1 https://github.com/strukturag/libde265.git  && cd libde265  && cmake -GNinja .   -D  5.8s 
 => CANCELED [xcb-proto 1/1] RUN git clone -b xcb-proto-1.16.0 --depth=1 https://github.com/gitlab-freedesktop-mirrors/xcbproto.git  && cd xcbprot  7.4s 
 => CANCELED [nasm 1/1] RUN git clone -b nasm-2.15.05 --depth=1 https://github.com/netwide-assembler/nasm.git  && cd nasm  && ./autogen.sh  && ./c  7.7s 
 => CANCELED [wayland 1/1] RUN git clone -b 1.19.0 --depth=1 https://github.com/gitlab-freedesktop-mirrors/wayland.git  && cd wayland  && sed -i "  7.4s 
 => CANCELED [glib 1/1] RUN git clone -b 2.78.1 --depth=1 https://github.com/GNOME/glib.git  && cd glib  && meson build   --buildtype=plain   --de  7.1s 
 => CANCELED [libxcomposite 1/1] RUN git clone -b libXcomposite-0.4.6 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxcomposite.git  &  7.0s 
 => [patches 1/1] RUN git init patches  && cd patches  && git remote add origin https://github.com/desktop-app/patches.git  && git fetch --depth=1  2.8s 
 => CANCELED [openssl 1/1] RUN git clone -b openssl-3.2.1 --depth=1 https://github.com/openssl/openssl.git  && cd openssl  && ./config   --openssl  7.8s 
 => CANCELED [opus 1/1] RUN git clone -b v1.4 --depth=1 https://github.com/xiph/opus.git  && cd opus  && ./autogen.sh  && ./configure  && make -j$  7.8s 
 => CANCELED [pipewire 1/1] RUN git clone -b 0.3.25 --depth=1 https://github.com/PipeWire/pipewire.git  && cd pipewire  && meson build   --buildty  7.7s 
 => CANCELED [libxtst 1/1] RUN git clone -b libXtst-1.2.4 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxtst.git  && cd libxtst  && .  7.8s 
 => CANCELED [xcb-keysyms 1/1] RUN git clone -b xcb-util-keysyms-0.4.1 --depth=1 --recursive https://github.com/gitlab-freedesktop-mirrors/libxcb-  7.5s 
 => CANCELED [libxext 1/1] RUN git clone -b libXext-1.3.5 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxext.git  && cd libxext  && .  7.8s 
 => CANCELED [libwebp 1/1] RUN git clone -b chrome-m116-5845 --depth=1 https://github.com/webmproject/libwebp.git  && cd libwebp  && cmake -GNinja  7.7s 
 => CANCELED [libxdamage 1/1] RUN git clone -b libXdamage-1.1.6 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxdamage.git  && cd libx  6.9s 
 => CANCELED [breakpad 1/1] RUN git clone -b v2023.06.01 --depth=1 https://chromium.googlesource.com/breakpad/breakpad.git  && cd breakpad  && git  7.6s
 => CANCELED [xcb-wm 1/1] RUN git clone -b xcb-util-wm-0.4.2 --depth=1 --recursive https://github.com/gitlab-freedesktop-mirrors/libxcb-wm.git  &&  7.4s
 => CANCELED [xcb-render-util 1/1] RUN git clone -b xcb-util-renderutil-0.3.10 --depth=1 --recursive https://github.com/gitlab-freedesktop-mirrors  7.5s
 => CANCELED [protobuf 1/1] RUN git clone -b v21.9 --depth=1 --recursive https://github.com/protocolbuffers/protobuf.git  && cd protobuf  && git i  5.4s
 => CANCELED [rnnoise 1/1] RUN git clone -b master --depth=1 https://github.com/desktop-app/rnnoise.git  && cd rnnoise  && cmake -GNinja -B build   6.2s
 => CANCELED [zlib 1/1] RUN git init zlib  && cd zlib  && git remote add origin https://github.com/madler/zlib.git  && git fetch --depth=1 origin   7.4s
 => CANCELED [brotli 1/1] RUN git clone -b v1.1.0 --depth=1 https://github.com/google/brotli.git  && cd brotli  && cmake -GNinja -B build .   -DCM  5.9s
 => CANCELED [highway 1/1] RUN git clone -b 1.0.7 --depth=1 https://github.com/google/highway.git  && cd highway  && cmake -GNinja -B build .   -D  6.1s
 => [nv-codec-headers 1/1] RUN git clone -b n12.0.16.0 --depth=1 https://github.com/FFmpeg/nv-codec-headers.git  && DESTDIR="/usr/src/Libraries/nv  5.0s
 => CANCELED [libxrender 1/1] RUN git clone -b libXrender-0.9.11 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxrender.git  && cd lib  6.7s
 => CANCELED [libxfixes 1/1] RUN git clone -b libXfixes-5.0.3 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxfixes.git  && cd libxfix  6.4s
 => CANCELED [libxrandr 1/1] RUN git clone -b libXrandr-1.5.3 --depth=1 https://github.com/gitlab-freedesktop-mirrors/libxrandr.git  && cd libxran  6.6s
 => CANCELED [lcms2 1/1] RUN git clone -b lcms2.15 --depth=1 https://github.com/mm2/Little-CMS.git  && cd Little-CMS  && meson build   --buildtype  7.4s
 => CANCELED [libvpx 1/1] RUN git init libvpx  && cd libvpx  && git remote add origin https://github.com/webmproject/libvpx.git  && git fetch --de  7.8s
 => ERROR [xz 1/1] RUN git clone -b v5.4.4 --depth=1 https://github.com/tukaani-project/xz.git  && cd xz  && cmake -B build . -DCMAKE_BUILD_TYPE=N  5.3s
------
 > [xz 1/1] RUN git clone -b v5.4.4 --depth=1 https://github.com/tukaani-project/xz.git         && cd xz        && cmake -B build . -DCMAKE_BUILD_TYPE=None      && cmake --build build -j$(nproc)       && DESTDIR="/usr/src/Libraries/xz-cache" cmake --install build  && cd ..        && rm -rf xz:
4.823 Cloning into 'xz'...
5.136 fatal: could not read Username for 'https://github.com': No such device or address
------
Dockerfile:72
--------------------
  71 |     FROM builder AS xz
  72 | >>> RUN git clone -b v5.4.4 --depth=1 https://github.com/tukaani-project/xz.git \
  73 | >>>      && cd xz \
  74 | >>>      && cmake -B build . -DCMAKE_BUILD_TYPE=None \
  75 | >>>      && cmake --build build -j$(nproc) \
  76 | >>>      && DESTDIR="/usr/src/Libraries/xz-cache" cmake --install build \
  77 | >>>      && cd .. \
  78 | >>>      && rm -rf xz
  79 |     
--------------------
ERROR: failed to solve: process "bash -c . /opt/rh/gcc-toolset-12/enable; exec bash -c \"$@\" -s git clone -b v5.4.4 --depth=1 https://github.com/tukaani-project/xz.git \t&& cd xz \t&& cmake -B build . -DCMAKE_BUILD_TYPE=None \t&& cmake --build build -j$(nproc) \t&& DESTDIR=\"/usr/src/Libraries/xz-cache\" cmake --install build \t&& cd .. \t&& rm -rf xz" did not complete successfully: exit code: 128

[ilya-fedin]

@ilya-fedin Does it periodically actively check whether it's connected, and if it isn't it reconnects, or does it listen for some sort of "connection loss" events, and when it gets one it reconnects? (or both?) Sorry for asking again, but every time you reply to people suggesting the second, it sounds almost like the two are the same thing to you.

If I understand it right (I'm not the one who wrote that code nor I have a good understanding of it but that is generally how such things usually work), Qt should signal that a request is finished with a error and the handler should run a new connection attempt. Once it also fails with a error, it should spawn a timer (and you see the second counter in the UI) and once it expires, it should try to connect again and then everything repeats.

Not sure what you mean by "actively check": the error from the socket is the only way to know the socket is disconnected. If this part is broken then we just can't know this exact connection is broken, we can only do the overall system connection check which I'm not sure will work if the system connects fastly after sleep.

This is getting too much into the territory I have no answers for, the only person who can answer them is the person who implemented the code (the developer paid by Telegram) but he has no spare time and this is a community supplied task (GitHub issues is not an official place and people managing priorities likely don't even know about it) so has the least priority for him.

[ilya-fedin]

I'm getting errors when running build/prepare/linux.sh (before I even try to apply the patch):

You're lucky to do that exactly when GitHub has removed the repository of xz project and so the build is broken.

[john-preston]

The protocol implementation is very old and it's hard to debug and find problems there, but initially it had timeout timers for almost everything. Like, when there are no pings in a connection session for some amount of seconds it should restart, when there are no updates for some amount of seconds, when the connection interrupts with a TCP error etc etc.

But there are a lot of very complicated parts, some of which were added on top many years later (and still many years ago), like connection establishment with a new temporary encryption key creation and it seems like there is some state of everything in which everything is kinda-deadlocked, like the connection is thought of as being in process of establishing, but really nothing is going to progress anymore due to some network error which resulted in data not being delivered, but still the TCP connection is thought of as alive by Qt.

In that case it hangs like that indefinitely until some force-restart of connection triggers the whole process to start from the beginning, successfully this time.

It would be helpful to enable debug logs (type "debugmode" in Settings) and reproduce the issue, then collect full DebugLogs folder for this run (from start till the connection can't be re-established for, let's say, five minutes) and .zip them and send to me at https://t.me/preston, so that I could (maybe?) understand this connection-related state of the app when it fails to reconnect by timeout by itself.

Be aware that debug logs contain all the network data being exchanged, so share them anywhere publicly.

[php4fan]

It would be helpful to enable debug logs (type "debugmode" in Settings)

There's no search box to type in (I tried typing anyway but nothing happens) and I can't find such setting

[php4fan]

There's no search box to type in (I tried typing anyway but nothing happens)

Oh wow, I needed to type the entire word "debugmode" blindly with no visual feedback 🤦

[ilya-fedin]

Yeah, it's a cheat code like in a game

[php4fan]

So I enabled debug logs (the normal ones, I wasn't able to recompile TD with the patch adding extra logs) and left Telegram running with them.
It took a few days (suspending and resuming a few times) before it finally was unable to reconnect after waking up from sleep.

I sent the logs to @john-preston .

One thing I suggest you fix in the way debug logs are written is that the timestamps only include the time of day but not the date, and the filenames are also based solely on the time (e.g. log_17_45) so I guess files end up being overwritten cyclically if Telegram keeps running for more than 24 hours..

[john-preston]

Ok, I've deployed 4.16.5 with a fix to the problem that I've found from the logs I've received.

Please update in Settings > Advanced and keep an eye, is it working now or not.

If it wasn't fixed and is not connecting the same way after wake-up for some significant time (let's say 10 minutes) I'd ask for new debug logs, from 4.16.5 version. Thanks!

[RblSb]

Works pretty good, thank you!

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.