You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, first of all, I really like your project. It's the simplest way to stream h264 to a browser, and it performs really well too.
The setup I use consists of a Raspberry PI 1B (basically the oldest series), a USB WIFI stick, and Raspberry Pi OS lite 2021.05. Server.py works like charm if I start it from a SSH shell, but won't work if I start it from rc.local.
After some debugging it turns out that WIFI connection is not established by the time the script starts and the IP is 169.254.x.x at first, and later changes to the router provided 192.168.x.x. Since the script performs html templating at startup the websocket URL's will be wrong.
This mechanism also fails if I try to access my PI from the internet. It's behind a NAT router, and a local IP doesn't work for websocket connections from the public internet.
My suggestion is to move templating into the request handlers, and use the 'Host' header of the request in the template. This way it's guaranteed that the browser will find the ws endpoint even if different DNS names or port mapping is in use.
I can send a PR, if you're interested.
The text was updated successfully, but these errors were encountered:
do you have the wait for network at boot option enabled? raspi-config > System Options > Network at Boot
if it's enabled and you start server.py right before the 'exit 0' you should get the correct ip.
also grab a copy of master and see if the latest commit helps you out. Torndao will no longer care about request origin, so cross domain/ip ws requests should work. b9931d2
The reason for having the templating done at start up was to help lower powered pi. Zeros showed cpu spikes during development when templating was done on the fly, and caused issues if more than 1 users was connected.
as an aside this might be an issue for you in the future, if it isn't already. I recently gave my pi domain names in local dns just because it was the only way to easily deal with this issue. https://developer.chrome.com/blog/private-network-access-update/
You can query the host on js side too. var ws = new WebSocket('ws://' + window.location.host + '/ws/');
That's a very good point, I'll try that out in a few days as i will probably push a new release soon as a new version of jmuxer has been released base on a bug/issue i submitted.
Hi, first of all, I really like your project. It's the simplest way to stream h264 to a browser, and it performs really well too.
The setup I use consists of a Raspberry PI 1B (basically the oldest series), a USB WIFI stick, and Raspberry Pi OS lite 2021.05. Server.py works like charm if I start it from a SSH shell, but won't work if I start it from rc.local.
After some debugging it turns out that WIFI connection is not established by the time the script starts and the IP is 169.254.x.x at first, and later changes to the router provided 192.168.x.x. Since the script performs html templating at startup the websocket URL's will be wrong.
This mechanism also fails if I try to access my PI from the internet. It's behind a NAT router, and a local IP doesn't work for websocket connections from the public internet.
My suggestion is to move templating into the request handlers, and use the 'Host' header of the request in the template. This way it's guaranteed that the browser will find the ws endpoint even if different DNS names or port mapping is in use.
I can send a PR, if you're interested.
The text was updated successfully, but these errors were encountered: