LiveReload not loading

[jacwright]

I am loading my page from localhost. The livereload script injected into index.html has http://10.201.45.95:35729/livereload.js?snipver=1 which is not my computer's IP (it is 10.0.1.5). But since I don't have port-forwarding on my router to my laptop it can't load the reload script. When I hit the script at http://localhost:35729/livereload.js?snipver=1 or http://10.0.1.5:35729/livereload.js?snipver=1 it loads just fine.

Any ideas where that IP is coming from and what do do about fixing it?

[jacwright]

If I load http://10.0.1.5:8080/ then livereload uses http://10.0.1.5:35729/livereload.js?snipver=1. But when using localhost it gives the bad URL. This is still the case when I use --host=locahost.

[mattdesl]

Budo uses the internal-ip module to determine your IP. Can you test that CLI to see if it produces the same problem?

Just so I understand the problem correctly:

• When you use budo index.js --live without any other options, it produces an invalid IP and doesn't live reload
• When you use budo index.js --live --host=10.0.1.5 it works fine

[jacwright]

Correction, when I use budo index.js --live without any other options it starts a server correctly on 10.0.1.5. I can view the page from localhost, but it produces in invalid IP for the livereload.js script that is injected. If I view the page from 10.0.1.5 (without restarting the server) the URL for the livereload.js script is correctly loaded from 10.0.1.5.

When I set the host explicitly to --host=localhost it starts the server correctly on localhost and I have the same behavior as described above.

[jacwright]

This is no longer happening this morning to me. I'm not sure if there is some strange network configuration things going on. I'm on the same standard home-office network with Comcast.

Still, I see that when setting --host=localhost the server starts up on localhost but the livereload.js script is being injected with the 10.0.1.5 ip. If you fix the injection to use whatever host the server is using it will fix this other intermittent bug.

[mattdesl]

The reason the injected script uses a specific IP is so that mobile LiveReload can work out of the box. Other suggestions?

[jacwright]

I have no suggestions. I'm not sure how mobile testing works nor why I was getting that strange IP address.

[mattdesl]

Ok, there may be some strangeness in the way that budo tries to use default host address that I can clean up and lead to overall less confusion. I will leave this open while I brew on it... 😄

[jacwright]

Thank you. And good luck! :)

[jacwright]

Update: it may have been the IP of my VPN address. I'm finding this VPN IP is the IP that budo uses often by default. I'm setting to localhost because I can't have it keep changing (I use localStorage etc. which are keyed to domain) so I'll just go without live reload for now.

Could the server bind to all available IPs? I noticed that http-server will do this (this would solve the problem I believe).

Output of http-server on my machine this morning.

Starting up http-server, serving public/
Available on:
  http:127.0.0.1:8080
  http:10.0.1.5:8080
  http:10.201.45.153:8080

[jacwright]

I cloned budo and set tinylr to listen on undefined as its host. This way it will bind to any IP. This worked out great. Not sure if this will break anything and why you're limiting budo to a given host in the first place. Why not leave the host undefined for connecting on any IP? For budo and tinylr.

[mattdesl]

Cool! Right now the reasons I'm using internal-ip is:

• So it shows in terminal so the user knows which URL to hit
  • http://localhost:9966/ will still work, but it's nice to know the internal IP so you can hit that on mobile
• So that LiveReload works on mobile too; since setting it to 127.0.0.1 or localhost won't allow LiveReload script to reload across many devices

But maybe we can bind the server to undefined by default, but use the internal IP for mobile LiveReload + logging. I'm not sure that will work with your setup, though.

[jacwright]

That would be perfect. Use internal-ip for terminal logging, to open up the browser at the right URL (when using --open), and for the livereload.js script. But when binding using undefined.

That sounds like it would work. Incoming PR.

[unframework]

I can confirm a similar bug report: accessing on localhost:9966 tried to load LiveReload script from a strange IP that was not in my ipconfig or anything. I recently had logged onto a new Wi-Fi network, for context.

Now, similar to the description above, accessing on 127.0.0.1:9966 made LiveReload script tag use the proper IP address. And when I went back to localhost after this, it started working fine too. I think there is some kind of a cache that stores the IP where LiveReload thinks the script lives, and this clears it? It works now, but was definitely baffling for a bit.

Cheers! (And keep up the great work overall)

[mattdesl]

For what it's worth, the LiveReload refactor branch mentioned here should not have this issue. Feel free to give it a whirl and see if that version works out OK for you.

[unframework]

I actually wonder if it has to do with simple browser caching of the index.html content... Doing a hard reload may have helped this issue "fix itself"... Not sure.

[mattdesl]

I've definitely noticed a couple quirks in situations like airport wifi and mobile. The new LiveReload backend will probably resolve all that.

[abradley2]

Having this issue as well- livereload won't work when connected to a VPN

[mattdesl]

Thanks for testing @abradley2 – can you try the new backend and let me know?

npm i mattdesl/budo#feature/livereload-rework -g

[abradley2]

Thanks! Just tried that, I got the following warning:

Bundled LiveReload client could not be found, falling back to bundle the client on demand. This may be because you are using a git cloned version of budo instead of one installed via npm.

[mattdesl]

That's ok, the error will go away when it's published on npm properly. What version of node/npm are you on, by the way?

Otherwise, is that new version of budo working with your VPN?

[abradley2]

yeahp, it's working :)

[mattdesl]

Ok, should be all good in [email protected] now that it pulls in the new LiveReload stuff. Thanks!