Skip to content

feat(pairing): handle different server addresses in SiloRemote and TV setup #352

Description

@Quick104

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions