Desktop: endless queue appends tracks one by one, each triggering a full queue reorder + log dump (UI stalls)

Duplicate Check

• I confirm I searched for existing reports and found no duplicates.

Describe the Bug

On desktop (2.1.0, Linux), when a radio / endless queue loads its next batch of tracks, the UI freezes for several seconds (audio keeps playing). It gets worse as the queue grows and eventually the app never recovers.

From the logs, each single track appended to the queue triggers a full round of work in JvmMediaPlayerHandler:

onTimelineChanged: TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED, items: N
Reordering shuffled queue: SIZE N, TITLE [...]
Reordered shuffled queue: SIZE N, TITLE [...]
Original queue: SIZE N, TITLE [... every title in the queue ...]

A batch of 50 tracks means 50 timeline events, 50 reorders of the whole queue and 50 log lines containing every title (the log alone went from ~90 to 4400 lines/minute, 15 MB per session in the journal). With 200 tracks queued that is ~10k operations in a burst on the UI thread. Per-second event counts during one batch: 50, 100, 150, 50. Disabling Endless queue in settings avoids it.

Suggested fix: append the batch as one operation (a single timeline event / one reorder per batch), and drop or downgrade the per-event dump of the whole queue.

Steps to Reproduce

1. Settings → Endless queue ON (default).
2. Start a radio from any song and wait for the queue to load 50, 100, 150+ tracks.
3. UI stalls at each batch; the stall grows with the queue size.

Expected Behavior

Adding a batch of tracks to the queue should not block the UI.

App Version

2.1.0 (desktop, AppImage)

Android Version

N/A - CachyOS (Arch), GNOME Wayland

Device Model

Laptop, AMD Ryzen / Radeon 680M

Custom ROM

• I am using a custom ROM

Custom ROM Name (if applicable)

No response

Screenshots (optional)

No response

Log / Error Details

Excerpt (titles shortened), 51 identical rounds in the same second:

Inserted song: Self Aware
onTimelineChanged: TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED, items: 0
Reordering shuffled queue: SIZE 0, TITLE []
Reordered shuffled queue: SIZE 0, TITLE []
Original queue: SIZE 1, TITLE [Self Aware]
onTimelineChanged: TIMELINE_CHANGE_REASON_PLAYLIST_CHANGED, items: 0
...
Original queue: SIZE 51, TITLE [...]
...
Original queue: SIZE 201, TITLE [...]

Start in JvmMediaPlayerHandler at the onTimelineChanged callback and trace the endless-queue batch append path. Reproduce with Endless queue enabled while watching the timeline and queue logs. Done means a batch produces one timeline event and queue reorder, without dumping the full queue for every event, and the desktop UI no longer stalls as the queue grows.