Update RELEASENOTES-DEVELOPMENT.md

diff --git a/RELEASENOTES-DEVELOPMENT.md b/RELEASENOTES-DEVELOPMENT.md
index 72e0470bf69d0c37442c1799d7eeb9ca0316b5fe..46be45a308e30bf5a67a2474752c731a4ead08a6 100644 (file)
--- a/RELEASENOTES-DEVELOPMENT.md
+++ b/RELEASENOTES-DEVELOPMENT.md
@@ -3,7 +3,7 @@ Version 3.3.7d7
 **Enhancements**
 * Logs and statistics can now be directed to the system log (default), `stdout`, `stderr` or to a file or pipe of your choice using a new setting, `log_output_to` in the `diagnostics` section of the configuration file. This is very useful when the system log is disabled or diverted.
 * Audio data from the `pipe` back end, and metadata from the metadata pipe are now written using standard blocking `write` commands rather than a slightly complex non-blocking write function. Pipes are opend in non-blocking mode and chaned to blocking mode when successfully opened.
-* Separate threads for the metadata subsystems. Until now, all metadata was processed on a single thread. This included supplying the metadata pipe and the multicast stream and supplying metadata for the mqtt interface and for the `dbus` and `MPRIS` interfaces. Unfortunately, that meant that a problem with any one of these subsystems could propagate into the others. Now they all run on separate threads (almost -- the metadata pipe and multicast are still on one thread). If a subsystem blocks, it will only block itself and will not interfere with the other subsystems.
+* Separate threads for the metadata subsystems. Until now, all metadata was processed on a single thread. This included supplying the metadata pipe and the multicast stream and supplying metadata for the mqtt interface and for the `dbus` and `MPRIS` interfaces. Unfortunately, that meant that a problem with any one of these subsystems could propagate into the others. Now they all run on separate threads. If one thread blocks, it will not interfere with the other subsystems.
 
 **Bug Fixes and Enhancements**
 * Fixed a bug calculating the instantaneous synchronisation error. This bug could occasionally cause Shairport Sync to lose synchronisation and maybe even to mute for a few seconds before regaining it. It was caused by not doing modulo arithmetic properly, and it's been there for a while.