More than three chromecasts?

[vessenes]

I'm not 100% sure this is a bug with your code, but I had problems seeing all my chromecasts with SoundCast recently. I have four chromecast audio's on my LAN, and all are viewable in the official google chromecast app for ios.

SoundCast only shows three. When I downloaded and installed this tool, it shows only three as well (although a different three).

Does this sound possible to you? One of the chromecast's has unicode characters in the name -- it shows fine in SoundCast, but does not show up with chromecast -l from the command line.

[vessenes]

Update -- I can confirm that multiple invocations of chromecast -l yield only three names, and that which names appear seems to be somewhat random.

[fardog]

hmm; taking a look at how this is written, I can totally believe it's a problem; we stop the browser after finding the first name, rather than doing any sort of timeout (the code that performs that step was contributed); I can imagine that the underlying cast-v2 client is just parallelizing some things and/or in your particular implementation it just manages to get to 3 of them before the tick of the loop that kills the browser; this isn't ideal.

unfortunately though, this code is effectively without a maintainer; I only had a mac because of my previous job, so I no longer have a place to test and work on this code, I'm sorry to say.

will leave this open and mark as "help wanted"; hopefully a contributor can help fix it.

[vessenes]

OK, if you can point me to a line or section I’ll see if I’ve got anything to offer. 

--  Peter Vessenes CEO, CoinLab Inc. @vessenes

On December 2, 2015 at 10:02:42 PM, Nathan Wittstock ([email protected]) wrote:

hmm; taking a look at how this is written, I can totally believe it's a problem; we stop the browser after finding the first name, rather than doing any sort of timeout (the code that performs that step was contributed); I can imagine that the underlying cast-v2 client is just parallelizing some things and/or in your particular implementation it just manages to get to 3 of them before the tick of the loop that kills the browser; this isn't ideal.

unfortunately though, this code is effectively without a maintainer; I only had a mac because of my previous job, so I no longer have a place to test and work on this code, I'm sorry to say.

will leave this open and mark as "help wanted"; hopefully a contributor can help fix it.

— Reply to this email directly or view it on GitHub.

[fardog]

sure, the issue is in this section specifically https://github.com/fardog/node-chromecast-osx-audio/blob/master/lib/index.js#L12-L30

what happens here is that the function called when the browser emits serviceUp will be called multiple times, once for each chromecast found; you can see that at the end of this function, it calls browser.stop() which stops the zeroconf service from looking for new services. my best guess is that there should actually be some sort of timeout here; that is, the browser.stop should only be called after a specified period of time has been reached (and ideally that timeout would be configurable via a command-line flag).

I could be off-base here (I haven't looked super thoroughly into the underlying mdns library that this uses) but that's where I'd start troubleshooting; you could even just start by commenting out that browser.stop() line and seeing if more services get listed before going any further.

thanks so much for taking a look at this!

[vessenes]

No problem. It's definitely doable to get in there and try your suggestion out; I'll see first if a timeout helps. I would think only a small timeout is needed, but it might be nice to increase that timeout if someone checks 'rescan' in the UI, just in case something was missed.

I don't love that function below, definitely made with only one chromecast in mind. I think it's too big a job for me right now to make it multi-cast friendly the whole way through, so let's go simple -- I'll keep you posted.