Library indexing is MUCH faster when performed on a wired (as opposed to wireless) Sonos component. But how can I convince/force Sonos Controller for Windows to use the wired component as its "Associated ZP"?
Page 1 / 1
Long (!) time Sonos owner here. Configuration: Sonos Connect Ethernet cabled to router, NAS cabled to same router, Windows PC connected to same router, five other Sonos components connected over SonosNet. Music library of 11,000 some odd tracks on NAS.
Back in the day, library indexing was no longer lightening-fast. I understand from other posts that older Sonos components cannot perform incremental music library "updates" and must re-index the entire music library every time. C'est la vie.
Unfortunately for me, the Sonos Controller for Windows pretty much NEVER selects the wired Sonos Connect as its "Associated ZP." For reasons unknown, it always selects one of the wireless Sonos components. You can see where this is heading ...
* If the "Associated ZP" is a wireless component, music library indexing takes about half an hour
* If the "Associated ZP" is the wired Connect, music library indexing takes less than five minutes
How do I convince/force Sonos Controller for Windows to select its "Associated ZP" as the wired Connect? I run around the house and physically unplug the power from all the wireless components. That technique worked OK for debugging purposes, though it felt kinda' silly. That technique is not acceptable under normal circumstances.
So the question on the table is as follows: how can I convince/force the Sonos Controller for Windows to ALWAYS use the wired Connect as its "Associated ZP," thereby performing music library re-indexing in under five minutes?
Back in the day, library indexing was no longer lightening-fast. I understand from other posts that older Sonos components cannot perform incremental music library "updates" and must re-index the entire music library every time. C'est la vie.
Unfortunately for me, the Sonos Controller for Windows pretty much NEVER selects the wired Sonos Connect as its "Associated ZP." For reasons unknown, it always selects one of the wireless Sonos components. You can see where this is heading ...
* If the "Associated ZP" is a wireless component, music library indexing takes about half an hour
* If the "Associated ZP" is the wired Connect, music library indexing takes less than five minutes
How do I convince/force Sonos Controller for Windows to select its "Associated ZP" as the wired Connect? I run around the house and physically unplug the power from all the wireless components. That technique worked OK for debugging purposes, though it felt kinda' silly. That technique is not acceptable under normal circumstances.
So the question on the table is as follows: how can I convince/force the Sonos Controller for Windows to ALWAYS use the wired Connect as its "Associated ZP," thereby performing music library re-indexing in under five minutes?
You can't. The 'Associated ZP' is the player whose response to the SSDP discovery multicast arrives first. It's pot luck which gets selected.
This is a question I once put to Sonos too. Unfortunately there's no official way to steer the DCR towards any specific player. All you can do is keep restarting the DCR until it comes up trumps.
It would be interesting to see whether deliberately introducing wireless interference would be sufficient to slug the SSDP responses from unwired nodes.
This is a question I once put to Sonos too. Unfortunately there's no official way to steer the DCR towards any specific player. All you can do is keep restarting the DCR until it comes up trumps.
It would be interesting to see whether deliberately introducing wireless interference would be sufficient to slug the SSDP responses from unwired nodes.
You didn't know it when you sent your reply, but it helped me kludge a solution: rather than "introducing wireless interference," I introduced TCP/IP interference!
On my the Windows PC running the controller, I added a firewall rule to BLOCK all outbound UDP traffic to the IP addresses of the wireless players. Viola, the wired controller wins the "Associated ZP" contest.(Oddly, I've been unable to make the firewall rule more specific. SSDP multicast is UDP port 1900, but the kludge does not work if I block only that port.)
Note that this is a KLUDGE. If any of the components get a different IP address from my DHCP server, for example, it will stop working. (I may be able to get my router to force static IP addresses, associating them with the MAC addresses of the Sonos components.)
On my the Windows PC running the controller, I added a firewall rule to BLOCK all outbound UDP traffic to the IP addresses of the wireless players. Viola, the wired controller wins the "Associated ZP" contest.(Oddly, I've been unable to make the firewall rule more specific. SSDP multicast is UDP port 1900, but the kludge does not work if I block only that port.)
Note that this is a KLUDGE. If any of the components get a different IP address from my DHCP server, for example, it will stop working. (I may be able to get my router to force static IP addresses, associating them with the MAC addresses of the Sonos components.)
Yuk. I can''t help thinking that this might have Unintended Consequences...
Do note that the firewall rule in question is on my Windows PC firewall, not my router firewall. Yuk, nevertheless. And I forgot to add a "knock wood," and the controller just picked up a wireless component as the "Associated ZP". Argh.
In order to make the firewall rule repeatable/effective, I need to block ALL TCP/UDP traffic to the wireless components (knock wood). With that over-the-top mechanism in place, the only component the controller can see is the wired ZP. Given only one choice, the controller can only make pick the "correct" Associated ZP. ;-)
Clearly, I cannot leave that over-the-top firewall rule turned on all the time. So what I've got is a handy-ish "kill switch":
[1] Turn on the firewall rule
[2] Launch the Windows Controller, which now sees only the wired ZP
[3] Launch the manual library indexing
[4] Turn OFF the firewall rule
While that four-step tango is a 9 out of 10 on the kludge scale, it DOES save nearly half an hour on manual library indexing. So if you squint your eyes just a bit, it end up as a "win" in the end.
In order to make the firewall rule repeatable/effective, I need to block ALL TCP/UDP traffic to the wireless components (knock wood). With that over-the-top mechanism in place, the only component the controller can see is the wired ZP. Given only one choice, the controller can only make pick the "correct" Associated ZP. ;-)
Clearly, I cannot leave that over-the-top firewall rule turned on all the time. So what I've got is a handy-ish "kill switch":
[1] Turn on the firewall rule
[2] Launch the Windows Controller, which now sees only the wired ZP
[3] Launch the manual library indexing
[4] Turn OFF the firewall rule
While that four-step tango is a 9 out of 10 on the kludge scale, it DOES save nearly half an hour on manual library indexing. So if you squint your eyes just a bit, it end up as a "win" in the end.
Why not set abandon the kludge and just set the library to reindex at 3am every day when you don't care how long it takes. I must admit I wasn't aware that some components can't update incrementally, but then there's a lot I don't know.
John, thanks for the reply. After I add a new album, I like to listen to the new album ... so invariably I run a manual library indexing. And then I wait around for 30+ minutes. 😉 With my "foolproof" (knock wood) four-step tango, the manual library indexing takes less than five minutes.
All components used to perform incremental updates. With one of the automagic firmware updates (sometime in the last few months), OLDER components lost the ability to perform incremental updates. Giving the Sonos folks the benefit of the doubt, I'm guessing that older components don't have enough of something (RAM?) to perform incremental updates with said firmware update.
All components used to perform incremental updates. With one of the automagic firmware updates (sometime in the last few months), OLDER components lost the ability to perform incremental updates. Giving the Sonos folks the benefit of the doubt, I'm guessing that older components don't have enough of something (RAM?) to perform incremental updates with said firmware update.
It is true that older components lack resources to do an incremental update, but you only need a single new component to speed it up again. This is because the update will be carried out on the newest Sonos unit in the system, then copied to the others. Surely you can find a spot for a shiny new Play:1? :;
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.