I thought that we at least used to have a filter based on known DIAL device types that corresponded to known Cast-enabled device, so that we'd try connections only when it was indeed a Cast device.  It sounds like perhaps that's not the case anymore?  I can imagine that keeping the list current could be a little annoying, but did we consciously get rid of this?

Re Comment #1, I thought that was how we had it as well, but looking through the code it looks like it has always attempted to verify if it is a cast device or not by trying to connect, not by checking against a model.

It does raise the question though, is there a reliable way to detect a cast device from the dial description without connecting to it?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e2d88405e8a90290f805360456ee330d5d1b6a91

commit e2d88405e8a90290f805360456ee330d5d1b6a91
Author: Derek Cheng <imcheng@chromium.org>
Date: Wed Oct 18 01:35:06 2017

[MediaRouter]Force dual discovery on user gesture.

- Added OnUserGesture() method to MediaSinkService, which gets called
on MRDesktop::OnUserGesture().
- The method is meant to signal the MediaSinkService that a user
gesture has occurred. It can then use this signal to "force" sinks to
be discovered right away, if supported.
- CastMediaSinkService::ForceDiscovery is renamed to OnUserGesture().
- DialMediaSinkService::OnUserGesture will re-sync DIAL-discovered
sinks to CastMediaSinkService. This helps in a very specific scenario:
if mDNS stopped working and a Cast sink that was discovered before was
lost due to network flakiness, then this gives CastMediaSinkService a
chance to recover sinks via this "forced" dual discovery mechanism.

- Another thing we can try in a future patch is to have
CastMediaSinkService retry connections for sinks stored in the
per-networkID cache. We should also have a mechanism to evict stale
entries from the cache.

Bug: 752310,  753175 
Change-Id: I77cdca84e607699b581d189d8d00380979ef5451
Reviewed-on: https://chromium-review.googlesource.com/714639
Commit-Queue: Derek Cheng <imcheng@chromium.org>
Reviewed-by: Bin Zhao <zhaobin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509646}
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/dial/dial_media_sink_service_impl.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/dial/dial_media_sink_service_impl.h
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/dial/dial_media_sink_service_impl_unittest.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/dial/dial_media_sink_service_proxy.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/dial/dial_media_sink_service_proxy.h
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service.h
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service_impl.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service_impl.h
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service_impl_unittest.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/discovery/mdns/cast_media_sink_service_unittest.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/browser/media/router/mojo/media_router_desktop.cc
[modify] https://crrev.com/e2d88405e8a90290f805360456ee330d5d1b6a91/chrome/common/media_router/discovery/media_sink_service.h

We currently try to connect DIAL-discovered devices up to a max number of failures (3), after which we will no longer attempt connection. Of course, the failure count is reset if once the device is discovered via mDNS. This simple heuristic helps prevent excessive connection attempts but there's things we can do better, e.g. modifying the DIAL device description to contain Cast-specific info and let it bake into the Cast receiver library. AFAIK there's no plans to do so right now, so please re-open this bug if that changes.