browser.js blows up inside _normalizeService when service has no fullname or txt about electron-chromecast HOT 14 OPEN

I assume your referencing the node-mdns-easy package.

https://github.com/GPMDP/node-mdns-easy/blob/master/src/browser.js#L67

from electron-chromecast.

Would you just expect the fullname to be blank if none is provided in the record?

(A blank fullname actually violates the MDNS spec but that's a different story)

from electron-chromecast.

/cc @jostrander I think you did this normalizing stuff, thoughts on how to handle?

from electron-chromecast.

That's right, browser.js = node_modules/node-mdns-easy/dist/browser.js

Would a sensible default be host + first service type or something? Not sure how fullname is used in your package, I just started kicking the tires tonight.

from electron-chromecast.

@johnspurlock I think we can just default it to the scanning type. We don't actually use fullname as far as I can see in this package. I think we used to but we replaced it with a text record.

https://github.com/GPMDP/electron-chromecast/blob/master/src/cast/index.js#L28

I don't know why we are even processing the record you posted though? It's type is homekit not cast?

from electron-chromecast.

Yeah I just made it normalized for our application, if we're missing something that could be used elsewhere by all means we can add a sensible default in.

from electron-chromecast.

Valid point though @MarshallOfSound that's not a valid google cast record.

from electron-chromecast.

I had other apps doing bonjour things at the time, I assume it was not explicitly requested by electron-chromecast, just observing another advertised service. Perhaps you can filter them out upstream somewhere?

from electron-chromecast.

@johnspurlock That would seem quite strange if it wasn't explicitly requested for node-mdns-easy to still receive it. Regardless if you want to submit a PR to node-mdns-easy with a sensible default I'll gladly accept it 👍

from electron-chromecast.

Ok thanks, I ended up using another library in the meantime - will look into a patch if I re-integrate this library.

from electron-chromecast.

another library

For chromecast integration? Can you link me through? 😄

from electron-chromecast.

Sure! Right now I'm just using castv2-client directly, which uses the same castv2 dependency, but no mdns abstraction or chrome api emulation.

from electron-chromecast.

@johnspurlock So castv2-client eliminates the need for chromecast api emulation in electron entirely? What kind of success have you had with this?

I'm having a similar problem, except my electron app throws an error when attempting to debug with a remote console. So for example, if I run my app with --remote-debugging-port=8315, and then open localhost:8315 the app throws...

Uncaught Exception:
TypeError: Cannot read property 'substring' of undefined
    at _class._normalizeService (../node_modules/node-mdns-easy/dist/browser.js:96:57)
    at _class.serviceUp (../node_modules/node-mdns-easy/dist/browser.js:74:35)
    at emitOne (events.js:96:13)
    at module.exports.emit (events.js:188:7)
    at module.exports.internal.onMessage ../node_modules/mdns-js/lib/browser.js:108:12)
    at emitThree (events.js:116:13)
    at module.exports.emit (events.js:194:7)
    at Socket.<anonymous> (../node_modules/mdns-js/lib/networking.js:144:10)
    at emitTwo (events.js:106:13)
    at Socket.emit (events.js:191:7)

This is inconvenient since node-mdns-easy prevents me from reliably debugging 😢 (remotely at least, my use case doesn't allow me to load dev tools inside electron)

from electron-chromecast.

@dskvr I just needed a cast client for my electron app (not direct chrome.cast emulation), so castv2-client instead of electron-chromecast was enough for me.

from electron-chromecast.