Problem / motivation
Automatically discovered media-share servers all use the generic media-share icon. Recognizing common NAS platforms such as Unraid, Synology, QNAP, and TrueNAS could make server lists easier to scan, but guessing from hostnames, ports, generic HTTP pages, or SMB behavior would create misleading branding. There are also many server vendors and custom/self-built systems, so a comprehensive hard-coded catalog is not practical.
Proposed solution
Add optional, confidence-based NAS vendor/model inference as a separate enrichment layer after transport discovery:
- Use only explicit, unauthenticated metadata with high confidence, such as Bonjour TXT records, UPnP/SSDP device descriptions, or clearly branded vendor APIs/responses.
- Model the result as typed evidence with confidence/source rather than a guessed string.
- Display a vendor logo only when the evidence explicitly identifies that vendor; otherwise retain the generic media-share icon.
- Start with a small set of common platforms (Unraid, Synology, QNAP, TrueNAS) and keep the matcher registry data-driven.
- Consider a future manual icon/vendor override for unrecognized or custom servers.
- Review logo asset licensing/brand guidelines before bundling vendor marks.
- Keep vendor inference entirely separate from protocol/port detection; branding must never affect connection routing.
Alternatives considered
- Infer from hostnames or open ports: rejected because users can rename hosts and ports do not identify vendors.
- Infer from generic SMB negotiation or HTTP
Server headers: useful only as weak supporting evidence and not sufficient alone for a logo.
- Build a comprehensive vendor catalog immediately: rejected because the ecosystem is too broad; use a generic fallback and add high-confidence matchers incrementally.
Affected backend(s)
Not applicable / not sure
Problem / motivation
Automatically discovered media-share servers all use the generic media-share icon. Recognizing common NAS platforms such as Unraid, Synology, QNAP, and TrueNAS could make server lists easier to scan, but guessing from hostnames, ports, generic HTTP pages, or SMB behavior would create misleading branding. There are also many server vendors and custom/self-built systems, so a comprehensive hard-coded catalog is not practical.
Proposed solution
Add optional, confidence-based NAS vendor/model inference as a separate enrichment layer after transport discovery:
Alternatives considered
Serverheaders: useful only as weak supporting evidence and not sufficient alone for a logo.Affected backend(s)
Not applicable / not sure