Problem
A phone using a network-plugin address and a TV using the same server's public address should still work together on the same LAN. URL-derived server matching can hide the TV from the remote-only picker. Sending a title includes more targets, but handoff asks the TV to use the phone's URL even when the TV already has a working address.
Companion setup has the related reachability problem: a Tailscale address working on the phone does not establish that the TV can reach it.
This is coordinated follow-up work to Silo-Server/silo-server#1096, linked to Silo-Server/silo-server#1169 and Silo-Server/silo-server#1192. Server contract dependency: Silo-Server/silo-server#1268.
Source evidence
The following behavior was inspected in source; it has not been reproduced on physical devices for this report.
shared/src/androidMain/kotlin/org/siloserver/silo/network/AndroidServerRegistry.kt: idFor encodes the normalized URL; serverIdsMatch canonicalizes spelling but does not associate different hostnames.
androidApp/src/androidMain/kotlin/org/siloserver/silo/android/ui/screens/cast/SiloCastTargetPickerSheet.kt: the remote-only picker filters by that ID; sending a title includes other targets.
SiloCastController.kt and TV RemotePlaybackIdentityManager.kt: the handoff carries and uses the phone's URL.
- Shared companion pairing sends one server URL.
PairingReceiver.kt attempts device login at that URL and surfaces failure without a provider setup or alternate-address recovery flow.
Required outcome
- Use the agreed verified server identity to recognize one deployment across public/LAN/plugin addresses. Keep local credential and settings keys intact; do not merge accounts or profiles because addresses match.
- Keep the remote-only TV visible when its working address differs from the phone's. Use a reachable TV address for temporary profile handoff and playback while preserving profile authorization and session cleanup.
- During companion setup, test access from the TV before reporting success. Distinguish an unreachable address from denied authorization or an expired/mismatched confirmation code.
- When a plugin address is unreachable, offer provider setup help, retry, and an explicit public-address option if the server supplies one. For Tailscale, advise installing or connecting the TV app and obtaining access to the server's network; do not claim the app is absent based only on a failed request.
- Check the alternate endpoint's identity and reachability before continuing pairing. Save the address that worked on the TV without changing the phone's preferred address.
- Keep manual URL/sign-in fallbacks and clear recovery when no public address is configured. Drive provider names and help from capabilities rather than hostname or IP-range guesses.
- Preserve same-LAN discovery and scope. Sharing a tailnet does not establish eligibility for automatic SiloRemote profile handoff. Keep code confirmation for onboarding distinct from automatic playback handoff.
- Do not introduce automatic mid-playback network switching in this work.
Validation
Cover Android phone and tablet with Android TV and Apple TV, plus iPhone/iPad with Android TV. Include phone-on-plugin/TV-on-public for the same server; reachable plugin access on both; TV unable to reach the plugin address; public fallback accepted, unavailable and identity-mismatched; different servers; and expired/mismatched pairing codes. Verify remote-only discovery, send-to-TV, selected profile, playback route, and recovery separately. Record physical-device results before closing the corresponding acceptance tasks.
Related platform acceptance tasks: #330, #331, #336 and #337. Sibling implementation: Silo-Server/silo-apple#341.
AI disclosure
AI-assisted issue drafting and source inspection: gpt-6 in Codex through T3 Code, using GitHub CLI and the repository unslop skill. No implementation or physical-device acceptance is claimed. Independent review: n/a for this follow-up proposal.
Problem
A phone using a network-plugin address and a TV using the same server's public address should still work together on the same LAN. URL-derived server matching can hide the TV from the remote-only picker. Sending a title includes more targets, but handoff asks the TV to use the phone's URL even when the TV already has a working address.
Companion setup has the related reachability problem: a Tailscale address working on the phone does not establish that the TV can reach it.
This is coordinated follow-up work to Silo-Server/silo-server#1096, linked to Silo-Server/silo-server#1169 and Silo-Server/silo-server#1192. Server contract dependency: Silo-Server/silo-server#1268.
Source evidence
The following behavior was inspected in source; it has not been reproduced on physical devices for this report.
shared/src/androidMain/kotlin/org/siloserver/silo/network/AndroidServerRegistry.kt:idForencodes the normalized URL;serverIdsMatchcanonicalizes spelling but does not associate different hostnames.androidApp/src/androidMain/kotlin/org/siloserver/silo/android/ui/screens/cast/SiloCastTargetPickerSheet.kt: the remote-only picker filters by that ID; sending a title includes other targets.SiloCastController.ktand TVRemotePlaybackIdentityManager.kt: the handoff carries and uses the phone's URL.PairingReceiver.ktattempts device login at that URL and surfaces failure without a provider setup or alternate-address recovery flow.Required outcome
Validation
Cover Android phone and tablet with Android TV and Apple TV, plus iPhone/iPad with Android TV. Include phone-on-plugin/TV-on-public for the same server; reachable plugin access on both; TV unable to reach the plugin address; public fallback accepted, unavailable and identity-mismatched; different servers; and expired/mismatched pairing codes. Verify remote-only discovery, send-to-TV, selected profile, playback route, and recovery separately. Record physical-device results before closing the corresponding acceptance tasks.
Related platform acceptance tasks: #330, #331, #336 and #337. Sibling implementation: Silo-Server/silo-apple#341.
AI disclosure
AI-assisted issue drafting and source inspection: gpt-6 in Codex through T3 Code, using GitHub CLI and the repository unslop skill. No implementation or physical-device acceptance is claimed. Independent review: n/a for this follow-up proposal.