Telegram and Materialgram not working

Ask Fedora
1

Last week, Telegram stopped working - I couldn’t make group calls. It was just connecting, and I was happy to find Materialgram as a working replacement, and today also latest.

Does anyone use Telegram for group calls and is it working?

2

(from Grok)

Materialgram Group Video Calls Stuck on “Connecting” on Fedora Kinoite

Description

Materialgram (io.github.kukuruzka165.materialgram, version 5.14.3.1) group video calls fail to connect, remaining stuck on “connecting” on Fedora Kinoite (Wayland, Fedora 42). The issue mirrors previous problems with Telegram Desktop, which were temporarily resolved by switching to Materialgram. Terminal output shows Qt rendering errors, suggesting a compatibility issue with the Freedesktop Platform runtime or Wayland/Qt.

Environment

  • OS: Fedora Kinoite 42 (Wayland)
  • Materialgram: 5.14.3.1 (Flatpak, Flathub, Freedesktop Platform 24.08)
  • Hardware: AMD Ryzen 7, AMD Radeon RX 580
  • PipeWire: Virtual microphone setup (virtual_sink at rate=48000, loopback to alsa_output.pci-0000_04_00.6.analog-stereo)

Symptoms

  • Group video calls (1:1 or group) stay stuck on “connecting” indefinitely.
  • Terminal errors when running flatpak run io.github.kukuruzka165.materialgram:
QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
qt.qpa.wayland: Creating a popup with a parent... (Wayland popup parenting issue)
  • Audio routing via virtual_sink works locally, but calls don’t connect to test remote audio.
  • Previously, a phone connect/disconnect trick worked with Telegram AppImage, but it fails here.

Attempted Workarounds

  1. Runtime Switch: Tried Freedesktop Platform 23.08 (flatpak run --runtime=org.freedesktop.Platform//23.08), but failed due to missing libabsl_strings.so.2407.0.0.
  2. Qt Rendering Tweaks:
  • QT_QPA_PLATFORM=xcb: Failed due to missing libxcb-cursor0.
  • QT_QPA_PLATFORM=minimal: Produced QOpenGLWidget errors, no connection.
  • QT_WAYLAND_FORCE_DPI=96 and QT_OPENGL=software: Same Qt errors, no improvement.
  1. Permissions: Verified Network, D-Bus, and Wayland access in Flatseal.
  2. Downgrade: Attempted downgrade to 5.11.1.1 or 5.8.1.1, but commits unavailable on Flathub.
  3. Debug Logging: WEBRTC_LOG_LEVEL=verbose and QT_LOGGING_RULES="qt5ct.debug=true" showed no additional WebRTC logs, only Qt errors.

Suspected Cause

The issue likely stems from a compatibility problem in the Freedesktop Platform 24.08 runtime, possibly related to srtp with OpenSSL (Freedesktop SDK issue #1873: Build srtp with openssl (#1873) · Issues · freedesktop-sdk / freedesktop-sdk · GitLab), affecting WebRTC calls. Qt 6.9.1 (noted in Telegram 5.14.3-3 rebuild: upgpkg: 5.14.3-3: Qt 6.9.1 rebuild (7902bb23) · Commits · Arch Linux / Packaging / Packages / telegram-desktop · GitLab) may introduce Wayland rendering issues, as evidenced by QPainter and QWidget errors. A system update (Fedora 42 or Flatpak runtime) may have triggered the regression, as Materialgram previously worked.

Steps to Reproduce

  1. Install Materialgram 5.14.3.1 via Flatpak (Flathub) on Fedora Kinoite 42 (Wayland).
  2. Start a group video call or 1:1 call.
  3. Observe “connecting” status with no connection.
  4. Run flatpak run io.github.kukuruzka165.materialgram and note Qt errors in terminal.

Additional Notes

  • Previously used Ivan’s Telegram AppImage with phone trick, suggesting a WebRTC signaling issue.
  • Other users report similar issues post-Flatpak updates (Discover reviews).

Request

Please investigate potential srtp/OpenSSL runtime issues or Qt 6.9.1/Wayland conflicts. Suggestions for alternative runtimes, Qt patches, or WebRTC fixes are appreciated.

3

The update to blame will be a Flatpak runtime update, not a Fedora update, because - as you linked - the root cause is in the freedesktop-sdk Flatpak runtime (Build srtp with openssl (#1873) · Issues · freedesktop-sdk / freedesktop-sdk · GitLab)

4

Thank you for pointing this out. Can you explain what now? I posted this, hopefully someone involved in a project might see, or someone might come with a solution. You pointed me to something that, as a non-programmer, don’t know how to use your information. Thanks for understanding.

5

The underlying issue here is with a Flatpak runtime, and it isn’t specific to Fedora - you’d have the same issue using that Flatpak on any distribution. So the issue won’t get solved on Fedora Discussion, but maybe we can find workarounds.

RPMFusion has a telegram-desktop package, i.e. not a Flatpak. But from your other thread, I understand you’re using Kinoite, so you can’t just dnf install that package.

Possible workarounds (in the order of preference that I would try them):

  1. What about using Telegram in a web browser? (You could try both Firefox and Chromium to see what works best.) Personally I don’t use Telegram but I do use Zoom, and I found the Zoom Flatpak didn’t work well. Now I just use the Zoom web client in Chromium and it works fine for my purposes.

  2. Create a distrobox and install the RPMFusion telegram-desktop package in that.

  3. Enable the RPMFusion repos and use layering with rpm-ostree to add the RPMFusion telegram-desktop package to your install.

6

Thank you. Will try them …