(descriptive non-leading subject line courtesy Explicit Subject Line Generator 0.1b1)

Now that I've broken down and finally put a router between my machines and my broadband connection, everybody on my network can now enjoy browsing and streaming my music (a la HiJack! w00t!) collection over the LAN.

However, I've got a neighbor who I'd like to allow to stream from my player at the same time, and although I can forward all port 80 requests to the empeg and browse from outside our LAN and download individual tracks, the playlist that HiJack builds uses the only IP address it knows, which is internal.

Barring the other reasons I may not want to expose my empeg to the public Internet for now is there anything that can be done, or streaming handled differently to allow one to stream both internally and globally?

I don't expect anyone to bust a nut over it -- Intranet streaming alone satisfies a big wish-list ittem of mine already -- but, thoughts? VPN?

If you are using a linux box as router, you can setup portforwarding to get the desired result :

# modprobe ip_masq_portfw
# ipmasqadm portfw -a -P tcp -L [internet IP] 80 -R [empeg IP] 80

Yeah, but the problem is that Hijack returns the playlist containing the internal IP. No amount of routing/holes in firewalls is going to get around that.

It really ought to use the details from the Host field in the HTTP request. You listening, Mark?

Or just use no hostname/ip-addres in any of the links, just relative ones. The webbrowser is responsible for sending the request to the same ip-address the document came from.
The host-field in the request header should/could be used for virtual hosts. This way you could set accesrestrictions based on the accessed IP-address...

- No amount of routing/holes in firewalls is going to get around that. -

An http-proxy-server on the router should suffice. the empeg's IP is known and addressable by the proxy. It would require some configuration in the browser though

Yeah, but you've _still_ got to fix the problem that the wrong IP appears in the URLs in the playlist response. That's all I'm saying.

You can't leave the hostname out -- Winamp playlists aren't relative to anything. You need the whole lot in there. The easiest way to do this is to put the 'Host' field in there as a prefix.

You're absolutely right. I've just looked in the code of displayserver and this is the only place where I use a hostname in the URLs. Mediaplayer over proxy should work I think, as it uses IE's proxy settings. I still think it's rather strange that winamp soesn't support HTTP-proxy's

CORRECTION : winamp does support HTTP-proxy, so theoretically it should work as described earlier...

Ah, OK. I thought you were saying that an HTTP proxy instead of a hole would just cause it to magically work. I didn't think you were advocating configuring Winamp to use that proxy.

Anyway, that's clear now: Either set up a proxy, and point Winamp at it; or hassle Mark until he outputs the URLs correctly.

>It really ought to use the details from the Host field
>in the HTTP request. You listening, Mark?

Yeah, you're 100% correct. I just used IP address at first to avoid problems with unreliable name servers and whatnot: I didn't want to have to debug people's setups while debugging the server.

But now that the server is working well, I can safely switch over to using the Host: field, falling back to IP address if Host: is not set (like when I use "telnet xxxx 80" to test the server).

FITNR.

Frank, what header fields does DisplayServer set when returning a .m3u playlist? Can you send me a complete sample response to an m3u request, including HTTP headers?

I'm trying to get the playlist server to work with as many players as possible, and perhaps you've got some tricks I haven't found yet!

Thanks.

Why not just use relative URLs and leave the hostname/IP address off altogether? Am I missing something obvious?

Okay, try it now with Hijack v184. It now uses the "Host:" field from the HTTP GET request, rather than the empeg's IP address (unless the host field was missing) in the .m3u playlists.

-ml

>Why not just use relative URLs and leave the hostname/IP
>address off altogether? Am I missing something obvious?

Yeah, we're talking about the .m3u playlist files, which have no relative path to reference from. They need the whole deal, hostname and all. Don't they?

Good point. Duh.

Can you send me an m3u (with HTTP header) as would be generated by DisplayServer?

Thanks

Ummmm. I've never even seen, much less used, DisplayServer.

Mark, here is a displayserver setup. http://empeg.dyndns.org:81/

Sean

> Okay, try it now with Hijack v184. It now uses the "Host:"
> field from the HTTP GET request, rather than the empeg's IP
> address (unless the host field was missing) in the .m3u
> playlists.

BINGO! (I didnt get to try it until 185)

(smacks forehead) I totally forgot the complete request header would contain the external IP.

Mark -- this is W I C K E D. My fiancee is streaming from within our LAN, my buddy across town is streaming from outside... w00t!

Now maybe I'll run out and buy a couple 802.11 access points and an inverter for the car...

Mark,
this is a standard HTTP-request for an m3u in displayserver :

GET /ds-bin/getfid?output=m3u&savefile=ttt&fid=9ed HTTP/1.0

Host: empeg



HTTP/1.1 200 OK

Server: EmpegCar DisplayServer/1.1 (Linux)

Connection: Keep-Alive

Content-Type: audio/x-mpegurl



http://empeg/ds-bin/getfid?output=m3u&fid=9ee

http://empeg/ds-bin/getfid?output=m3u&fid=9f6

http://empeg/ds-bin/getfid?output=m3u&fid=a09

http://empeg/ds-bin/getfid?output=m3u&fid=a19

http://empeg/ds-bin/getfid?output=m3u&fid=a28

Connection closed by foreign host.

Mmm... okay, thanks.

Nothing really different there from Hijack (except the "Keep-Alive").

I wonder what other header fields are expected by MS MediaPlayer and Apple iTunes?

-ml

The keep-alive header is probably not needed.

WIndows users have to configure windows to open their MP3-player when a file with content-type audio/x-mpegurl is received:
In explorermenu :
View -> Options -> File Types