Skip to content

TX becomes unresponsive after some time #300

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ogruetzmann opened this issue Apr 25, 2025 · 2 comments
Open

TX becomes unresponsive after some time #300

ogruetzmann opened this issue Apr 25, 2025 · 2 comments

Comments

@ogruetzmann
Copy link

ogruetzmann commented Apr 25, 2025

TX becomes unresponsive after ~2h of use, 100% CPU on one core

I'm using TrackAudio 1.3.3 on Manjaro Linux (kernel 6.14), and I'm encountering an issue where TX becomes unresponsive after extended use (~2 hours).

Symptoms

  • I can still hear other pilots clearly
  • Pressing PTT does not reliably highlight the active TX frequency in the UI (sometimes only after a delay)
  • Pilots report that their callsign is missing from my transmissions
  • Eventually, I am unable to transmit at all
  • htop shows one CPU core at 100% usage caused by the TrackAudio process

Affected versions

This behavior occurs with both:

Temporary workaround

Restarting the application restores TX functionality — but only temporarily.

Additional observations

The log file at
~/.local/state/trackaudio/trackaudio.log
continues to record PTT input events during the broken state.
(See around 2025-04-24 21:26:37.145 in the attached log.)

📎 trackaudio.log

Version history

I'm not sure if this problem also existed in previous versions.
I recently switched from Windows to Linux, and my only session on version 1.3.1 was likely too short for the issue to occur.


Let me know if I can provide more logs or test a debug build.

@pierr3
Copy link
Owner

pierr3 commented May 18, 2025

Have you ever had this issue on Windows, or purely on Manjaro? Sounds like there might be a memory leak on this platform and I know where this could come from.

@ogruetzmann
Copy link
Author

No, windows worked (and works) fine. A memory leak might be the case, although the memory footprint only rises by a few hundred megabytes. Do you need some more info?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants