Retry the NQPTP probe at startup so a fresh shared-memory name does not fail - #2278
Conversation
|
Thanks for this. You'll see that there was a version of this commented out. The reason was that it wasn't needed in the setups tried, but it would certainly be useful to re-enable it. However, the timeout is a problem: The intention is to release just one version of Shairport Sync in the future, which will do AirPlay 2 if NQPTP is present and Classic AirPlay otherwise. For someone who only wants Classic AirPlay, the timeout is an unnecessary delay at startup. So, what about a timeout of 0.5 seconds? Would that cover our needs? |
nqptp creates the named shared-memory interface only when it receives the "T"
message shairport-sync sends at startup, so with a brand-new interface name
(for example a per-instance general.nqptp_shared_memory_interface_name) the
interface does not exist yet when the probe runs a moment later. The single
probe then reports "NQPTP service not found" and the instance dies
(service_type "airplay2") or silently falls back to classic AirPlay on port
5000 ("auto") on its first start; a restart succeeds only because the interface
now exists.
Re-enable the retry loop that was already present but commented out, so the
probe polls for a short window (up to 0.5s, 50ms interval) on ENOENT before
giving up. Only ENOENT ("not created yet") is retried; any other result falls
through immediately -- so a Classic-only start (no NQPTP) is not delayed beyond
that window.
88d9a4a to
7d8212d
Compare
|
Makes sense, and 0.5s is fine. In my testing the segment showed up about 50 ms after the |
2 participants
nqptp creates the named shared-memory interface only when it receives the "T"
message shairport-sync sends at startup, so with a brand-new interface name --
for example a per-instance general.nqptp_shared_memory_interface_name -- the
interface does not exist yet when the single probe runs a moment later. The probe
then reports "NQPTP service not found" and, on that first start, the instance
either dies (service_type "airplay2") or silently falls back to classic AirPlay
on port 5000 ("auto"). A restart succeeds only because the interface now exists,
so it is invisible under a supervisor that restarts -- but it bites anyone adding
a fresh instance, and "it silently came up as AirPlay 1 on port 5000" is
unpleasant to debug.
This re-enables the retry loop that was already present but commented out: the
probe polls for a short window (up to 2s, 50ms interval) on ENOENT before giving
up. Only ENOENT ("not created yet") is retried; any other result falls through
immediately.
Verified: with a fresh shm name the current code fatals on first start; with the
retry the interface is found at ~50ms and the instance comes up in AirPlay 2.
Surfaced independently by @jslove and in #2266 once instances stop sharing the
default shm name.