Sessions and Queueing: Difference between revisions

Revision as of 21:22, 13 September 2026

Home · Start here · All guides · Solve a problem · Radio terms · Developer API

Every transmission is a session between the transmitter client and the server. The server decides whether a new session is admitted immediately, queued or rejected.

Operate one session

Press Start TX once and select the new row.
Wait while it is Queued; check the reason if it is Failed or Kicked.
When Running, use Listen to Own TX to check the signal before propagation.
Use Stop Selected to stop that row. Stop All ends every session in this app.

Changing the ordinary setup form prepares another transmission. To change an existing running session, select it and enable Live Edit. Only the supported fields listed below are editable in place. Clear Finished removes old rows; it does not start or stop a transmission.

Session lifecycle

A session created with Start TX passes through these states:

Starting: the client is contacting the server.
Queued: the server is full for now; the list shows how many sessions are ahead. The session starts automatically when a slot frees up.
Running: the transmission is on the air and telemetry updates the Radio Deck.
Stopping / Stopped: the operator ended the session.
Finished: the source completed (for example the audio file ended).
Failed: the server rejected the session; the reason is shown.
Kicked: the server operator ended the session remotely; a dialog shows the reason.

Server limits

Servers can limit the total number of sessions, the number of transmit sessions, and the number of sessions per user. Current transmit-session limits and account permissions are checked against the authenticated account. Receiver-side limits can still use callsign or client-address bucketing according to server policy. When a transmit limit is reached new sessions are queued in order; when a policy forbids the session outright it is rejected with a reason.

Multiple sessions

The client can run several sessions at once (subject to server limits). The Active Sessions list shows each with its own state, and Stop Selected / Stop All control them individually or together.

Monitoring and live editing

Listen to Own TX monitors the selected running transmission as the server receives it, before propagation. It is intended for checking the transmitted signal rather than reception conditions.

Live Edit loads selected parameters from a running session into the form. Frequency, power, bandwidth, low cut, final drive, PA headroom, and compression can be changed in place. Frequency is committed by pressing Enter. Other supported values apply after a short pause. Leaving Live Edit restores the unfinished form that was present before editing.

Disconnects

If the control connection drops, the client reconnects automatically every 3 seconds. When Auto Reconnect is selected, a session interrupted by a connection error is started again after the connection returns. Sessions that were kicked or rejected show the server-supplied reason; an empty reason is displayed as "No reason given".

@@ Line 1: / Line 1: @@
+{{Documentation navigation}}
 Every transmission is a session between the transmitter client and the server. The server decides whether a new session is admitted immediately, queued or rejected.
+== Operate one session ==
+# Press Start TX once and select the new row.
+# Wait while it is Queued; check the reason if it is Failed or Kicked.
+# When Running, use Listen to Own TX to check the signal before propagation.
+# Use Stop Selected to stop that row. Stop All ends every session in this app.
+Changing the ordinary setup form prepares another transmission. To change an existing running session, select it and enable '''Live Edit'''. Only the supported fields listed below are editable in place. Clear Finished removes old rows; it does not start or stop a transmission.
 == Session lifecycle ==
@@ Line 12: / Line 23: @@
 == Server limits ==
-Servers can limit the total number of sessions, the number of transmit sessions, and the number of sessions per user. The user bucket is the callsign (case-insensitive) or, depending on server policy, the client address. When a transmit limit is reached new sessions are queued in order; when a policy forbids the session outright it is rejected with a reason.
+Servers can limit the total number of sessions, the number of transmit sessions, and the number of sessions per user. Current transmit-session limits and account permissions are checked against the authenticated account. Receiver-side limits can still use callsign or client-address bucketing according to server policy. When a transmit limit is reached new sessions are queued in order; when a policy forbids the session outright it is rejected with a reason.
 == Multiple sessions ==