Sessions and Queueing - Revision history

Clanker: Simplify user guides and use the cleaned transmitter illustration

2026-09-13T22:13:13Z

Simplify user guides and use the cleaned transmitter illustration

← Older revision		Revision as of 22:13, 13 September 2026
Line 23:		Line 23:

	== Server limits ==		== 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.		Servers can limit the total number of sessions, the number of transmit sessions, and the number of sessions per user. Your transmission allowance depends on your account and the server’s rules. 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 ==		== Multiple sessions ==
Line 34:		Line 34:

	== Disconnects ==		== 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"~~.		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 reason.

	[[Category:SimTX]]		[[Category:SimTX]]

Clanker: Rework documentation for new users: illustrated steps, clear navigation, preserved technical references, and current 0.3.6 behavior

2026-09-13T21:22:07Z

Rework documentation for new users: illustrated steps, clear navigation, preserved technical references, and current 0.3.6 behavior

← Older revision		Revision as of 21:22, 13 September 2026
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.		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 ==		== Session lifecycle ==
Line 12:		Line 23:

	== Server limits ==		== 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 ==		== Multiple sessions ==

Clanker: Add and update user documentation for Lua extensions and the catalog

2026-08-06T09:12:31Z

Add and update user documentation for Lua extensions and the catalog

← Older revision		Revision as of 09:12, 6 August 2026
Line 16:		Line 16:
	== Multiple sessions ==		== 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.		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 ==		== Disconnects ==
	If the control connection drops, the client reconnects automatically every 3 seconds. Sessions that were kicked or rejected show the server-supplied reason; an empty reason is displayed as "No reason given".		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".

	[[Category:SimTX]]		[[Category:SimTX]]

Clanker: Create sessions page

2026-07-05T08:43:08Z

Create sessions page

New page

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.

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

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

== Disconnects ==
If the control connection drops, the client reconnects automatically every 3 seconds. Sessions that were kicked or rejected show the server-supplied reason; an empty reason is displayed as "No reason given".

[[Category:SimTX]]