| 14 Jul 2025 |
 toonn | In the IPv6 future sharing your IP publically is intended, no? | 13:40:14 |
 matthewcroughan | bittorrent is more like a real broadcast (radio spectrum broadcast), because it doesn't require more bandwidth from the transmitter, to serve it to 1000 people | 13:40:40 |
| matthewcroughan | A real radio station doesn't require more bandwidth to reach more listeners (unless you count distance, which I don't) | 13:41:13 |
 @n4ch723hr3r:nope.chat | if you have a VPS or some other public device you could forward your port over that | 13:41:16 |
| matthewcroughan | Ah, not true, you can't proxy icecast neatly because it uses a combination of http and tcp | 13:41:38 |
| matthewcroughan | it runs http bits on port 8000, and tcp bits on 8000 | 13:41:50 |
| matthewcroughan | when the user hits it, nginx proxies to the http bits, and then fails on the tcp bits | 13:42:03 |
| @n4ch723hr3r:nope.chat | as far as i know you can do that over ssh | 13:42:05 |
| matthewcroughan | when you do services.icecast.enable = true and give it a stream, you can go to http://localhost:8000/stream and then you'll get binary data, not http | 13:42:40 |
| matthewcroughan | if you try to proxy to localhost:8000/stream on the public internet, with nginx, it doesn't work | 13:42:54 |
| @n4ch723hr3r:nope.chat | that sounds complicated. why doesnt icecast just do m3u8 or something like that? | 13:43:44 |
| matthewcroughan | [error] 57885#57885: *14 upstream sent invalid header: "\x20..." while reading response header from upstream, client: 192.168.5.222, server: icecast.example.com, request: "GET /radio HTTP/1.1", upstream: "http://192.168.5.196:8001/radio.ogg", host: "icecast.example.com" | 13:44:24 |
