morgan/UxPlay
1
0
Fork 0
mirror of https://github.com/morgan9e/UxPlay synced 2026-04-14 00:04:13 +09:00
Code Issues Packages Projects Releases Wiki Activity

set ntp timeout limit to 5, add informative error message when reached

Browse Source
This commit is contained in:
fduncanh
2022-02-09 13:56:19 -05:00
parent 8910a6e246
commit 249fcafa66
7 changed files with 14 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.html
View File

@@ -108,7 +108,7 @@
<p>To troubleshoot GStreamer execute “export GST_DEBUG=2” to set the GStreamer debug-level environment-variable in the terminal where you will run uxplay, so that you see warning and error messages; (replace “2” by “4” to see much (much) more of what is happening inside GStreamer). Run “gst-inspect-1.0” to see which GStreamer plugins are installed on your system.</p>
<p>Some extra GStreamer packages for special plugins may need to be installed (or reinstalled: a user using a Wayland display system as an alternative to X11 reported that after reinstalling Lubuntu 18.4, UxPlay would not work until gstreamer1.0-x was installed, presumably for Wayland’s X11-compatibility mode). Different distributions may break up GStreamer 1.x into packages in different ways; the packages listed above in the build instructions should bring in other required GStreamer packages as dependencies, but will not install all possible plugins.</p>
<h3 id="mirror-screen-freezes">5. Mirror screen freezes:</h3>
<p>This can happen if the TCP video stream from the client stops arriving at the server, probably because of network problems (the UDP audio stream may continue to arrive). At 3-second intervals, UxPlay checks that the client is still connected by sending it a request for a NTP time signal. If a reply is not received from the client within a 0.3 sec time-window, an “ntp timeout” is registered. If a certain number (currently 10) of consecutive ntp timeouts occur, UxPlay assumes that the client is “dead”, and resets the connection, becoming available for connection to a new client, or reconnection to the previous one. Sometimes the connection may recover before the timeout limit is reached, and if the default limit is not right for your network, it can be modified using the option “-reset <em>n</em>”, where <em>n</em> is the desired timeout-limit value (<em>n</em> = 0 means “no limit”). If the connection starts to recover after ntp timeouts, a corrupt video packet from before the timeout may trigger a “connection reset by peer” error, which also causes UxPlay to reset the connection. When the connection is reset, the “frozen” mirror screen of the previous connection is left in place, and will be taken over by a new client connection when it is made.</p>
<p>This can happen if the TCP video stream from the client stops arriving at the server, probably because of network problems (the UDP audio stream may continue to arrive). At 3-second intervals, UxPlay checks that the client is still connected by sending it a request for a NTP time signal. If a reply is not received from the client within a 0.3 sec time-window, an “ntp timeout” is registered. If a certain number (currently 5) of consecutive ntp timeouts occur, UxPlay assumes that the client is “dead”, and resets the connection, becoming available for connection to a new client, or reconnection to the previous one. Sometimes the connection may recover before the timeout limit is reached, and if the default limit is not right for your network, it can be modified using the option “-reset <em>n</em>”, where <em>n</em> is the desired timeout-limit value (<em>n</em> = 0 means “no limit”). If the connection starts to recover after ntp timeouts, a corrupt video packet from before the timeout may trigger a “connection reset by peer” error, which also causes UxPlay to reset the connection. When the connection is reset, the “frozen” mirror screen of the previous connection is left in place, and will be taken over by a new client connection when it is made.</p>
<h3 id="failure-to-decrypt-all-video-and-audio-streams-from-old-or-non-apple-clients">6. Failure to decrypt ALL video and audio streams from old or non-Apple clients:</h3>
<p>This triggers an unending stream of error messages, and means that the audio decryption key (also used in video decryption) was not correctly extracted from data sent by the client. This should not happen for iOS 9.3 or later clients. However, if a client uses the same older version of the protocol that is used by the Windows-based AirPlay client emulator <em>AirMyPC</em>, the protocol can be switched to the older version by the setting <code>OLD_PROTOCOL_CLIENT_USER_AGENT_LIST</code> in lib/global.h. UxPlay reports the client’s “User Agent” string when it connects. If some other client also fails to decrypt all audio and video, try adding its “User Agent” string in place of “xxx” in the entry “AirMyPC/2.0;xxx” in global.h and rebuild uxplay.</p>
<p>Note that Uxplay declares itself to be an AppleTV3,2 with a sourceVersion 220.68; this can also be changed in global.h. It is crucial for UxPlay to declare this old value of sourceVersion, as this prompts the Apple client to use a less-encrypted “legacy” protocol needed by third-generation Apple TV’s, which are 32-bit devices that cannot run modern tvOS; it is probably not necessary for UxPlay to claim to be such an old AppleTV model.</p>

2
README.md
View File

@@ -451,7 +451,7 @@ other required GStreamer packages as dependencies, but will not install all poss
This can happen if the TCP video stream from the client stops arriving at the server, probably because of network problems (the UDP audio stream may continue to arrive). At 3-second
intervals, UxPlay checks that the client is still connected by sending it a request for a NTP time signal. If a reply is not received from the client within a 0.3 sec
time-window, an "ntp timeout" is registered. If a certain number (currently 10) of consecutive ntp timeouts occur, UxPlay assumes that the client is "dead", and resets the connection,
time-window, an "ntp timeout" is registered. If a certain number (currently 5) of consecutive ntp timeouts occur, UxPlay assumes that the client is "dead", and resets the connection,
becoming available for connection to a new client, or reconnection to the previous one. Sometimes the connection may recover before the timeout limit is reached, and if the
default limit is not right for your network, it can be modified using the option "-reset _n_", where _n_ is the desired timeout-limit value (_n_ = 0 means "no limit"). If the connection
starts to recover after ntp timeouts, a corrupt video packet from before the timeout may trigger a "connection reset by peer" error, which also causes UxPlay to reset the

4
README.txt
View File

@@ -587,8 +587,8 @@ stream may continue to arrive). At 3-second intervals, UxPlay checks
that the client is still connected by sending it a request for a NTP
time signal. If a reply is not received from the client within a 0.3 sec
time-window, an "ntp timeout" is registered. If a certain number
(currently 10) of consecutive ntp timeouts occur, UxPlay assumes that
the client is "dead", and resets the connection, becoming available for
(currently 5) of consecutive ntp timeouts occur, UxPlay assumes that the
client is "dead", and resets the connection, becoming available for
connection to a new client, or reconnection to the previous one.
Sometimes the connection may recover before the timeout limit is
reached, and if the default limit is not right for your network, it can

2
lib/raop.h
View File

@@ -40,7 +40,7 @@ struct raop_callbacks_s {
/* Optional but recommended callback functions */
void (*conn_init)(void *cls);
void (*conn_destroy)(void *cls);
void (*conn_reset) (void *cls);
void (*conn_reset) (void *cls, int timeouts);
void (*conn_teardown)(void *cls, bool *teardown_96, bool *teardown_110 );
void (*audio_flush)(void *cls);
void (*video_flush)(void *cls);

2
lib/raop_ntp.c
View File

@@ -351,7 +351,7 @@ raop_ntp_thread(void *arg)
logger_log(raop_ntp->logger, LOGGER_DEBUG, "raop_ntp exiting thread");
if (conn_reset && raop_ntp->callbacks.conn_reset) {
raop_ntp->callbacks.conn_reset(raop_ntp->callbacks.cls);
raop_ntp->callbacks.conn_reset(raop_ntp->callbacks.cls, timeout_counter);
}
return 0;
}

2
lib/raop_rtp_mirror.c
View File

@@ -507,7 +507,7 @@ raop_rtp_mirror_thread(void *arg)
logger_log(raop_rtp_mirror->logger, LOGGER_DEBUG, "raop_rtp_mirror exiting TCP thread");
if (conn_reset && raop_rtp_mirror->callbacks.conn_reset) {
raop_rtp_mirror->callbacks.conn_reset(raop_rtp_mirror->callbacks.cls);
raop_rtp_mirror->callbacks.conn_reset(raop_rtp_mirror->callbacks.cls, 0);
}
return 0;
}

10
uxplay.cpp
View File

@@ -50,7 +50,7 @@
#define DEFAULT_DEBUG_LOG false
#define LOWEST_ALLOWED_PORT 1024
#define HIGHEST_PORT 65535
#define NTP_TIMEOUT_LIMIT 10
#define NTP_TIMEOUT_LIMIT 5
static std::string server_name = DEFAULT_NAME;
static int start_raop_server (std::vector<char> hw_addr, std::string name, unsigned short display[5],
@@ -591,8 +591,12 @@ extern "C" void conn_destroy (void *cls) {
}
}
extern "C" void conn_reset (void *cls) {
LOGI("***ERROR lost connection with client");
extern "C" void conn_reset (void *cls, int timeouts) {
LOGI("***ERROR lost connection with client (network problem?)");
if (timeouts) {
LOGI(" Client no-response limit of %d timeouts (%d seconds) reached:", timeouts, 3*timeouts);
LOGI(" The default timeout limit n = %d can be changed with the \"-reset n\" option", NTP_TIMEOUT_LIMIT);
}
close_window = false; /* leave "frozen" window open */
raop_stop(raop);
reset_loop = true;