Bugzilla – Bug 801
Feature request: Identify client by name and not ip
Last modified: 2011-02-09 11:50:38 UTC
I'm planning to use a squeezebox with a slimserver on an internet server and not local lan server, so I can listen to my collection even if I'm not at home and don't have to run a server at home. I fiddled a little around with the server and noticed that it creates for each IP address it's own playing list. Now it would be nice if you could pass with a parameter what mp3 playing list you want to use. Like: http://...:9000/stream.mp3?name=blah, so you can listen to your list even if your ip address changes. The Squeezebox could also send its mac address as name, so it's uniquely identified even if the ip address changes (I don't know if it does it or not, I don't have yet one, but planning to buy one) I also want to give my family access to my mp3s, but they shouldn't be able to access the admin area. An option for creating different user group which can't make any server settings modifications and only edit it's own player settings would be nice.
Isn't this fixed? Players are identified by MAC, so the first part is no longer an issue. We have gazilions of requests for finer granularity in security, so the second part is taken care of by other bugs.
This bug is about software clients using stream.mp3 which does identify them by IP address. Players (SLIMP3, Squeezebox, SoftSqueeze) do use unique MAC-based identifiers, but HTTP clients do not. Using a specified name is a good way to improve this.
Created attachment 1123 [details] http client name param using stream.mp3?name=<playername> creates a new client, identified by <playername> instead of an IP. This readily accepts remote clients with changing ip addresses. One issue is that while it will happily accept two simultaneous connections using the same name, the audio chunks get broken up between them both. We'd need some logic to dump the former connection. Another option would be to take the name param and match to a client in the prefs that has that name. This would take a lot more, since we don't currently load prefs for unconnected clients. We'd then have to init, and then alter the ID to match the new IP, otherwise we'd have copied prefs for every IP used by that remote client. messy.
Dean doesn't work here any more :)
Created attachment 7029 [details] What happens when we use stream.mp3 with a remote player and a dynamic IP When I got an iPhone I bought PocketTunes, an app I was familiar with from my Palm Centro. On both phones I used PocketTunes to stream music from my SqueezeBoxServer to my phone, and in fact there are a bunch of paid and free apps for a variety of portable devices that will utilize the SqueezeBoxServer's stream.mp3. This is awesome: I stream music from my server to my car all the time. What makes it less than awesome is that the feature described in this bug has still not been implemented. I've attached this screenshot to show the result. AT&T provides a dynamic IP to the iPhone over 3G, and of course using WiFi I'm going to get whatever IP is at the hotspot. The result is this mess you see in this screen capture. The additional drag is that since I like to scrobble my tunes on Last.FM, every time my IP changes I have to go adjust my player settings as well as start a new playlist. At home this isn't a problem: because my iPhone's IP is fixed on wi-fi, the SqueezeBox Server always knows who I am and I can continue my old playlists, am already configured for last.fm, etc. We really need this feature so we can do the same thing when we're at work or in our cars, and I hope this graphic lends some credence. What isn't shown is all the LAME sessions in the server memory waiting for those IPs to come back up. Sure, I could go in every day after I get home and click "Forget this player," but it would be so much better if we could assign a name or even a fake MAC address to the remote player through the request string just like we can set the bitrate of the stream.
Any idea why this bug was set to "RESOLVED WONTFIX"? The initial problem (one player created per IP address) is not fixed, right?
(In reply to comment #6) > Any idea why this bug was set to "RESOLVED WONTFIX"? The initial problem (one > player created per IP address) is not fixed, right? I certainly had this same question. I assume it means that it's resolved because they are not going to fix it, which makes me very sad. The system works so well to stream remotely except this one, nearly dealbreaking issue. I really hoped the attachment I provided would sway them but evidently not :( Really disappointing.
(In reply to comment #7) > (In reply to comment #6) > > Any idea why this bug was set to "RESOLVED WONTFIX"? The initial problem (one > > player created per IP address) is not fixed, right? > > I certainly had this same question. I assume it means that it's resolved > because they are not going to fix it, which makes me very sad. The system > works so well to stream remotely except this one, nearly dealbreaking issue. I > really hoped the attachment I provided would sway them but evidently not :( > > Really disappointing. Yes, really disappointing, indeed. Thanks for the patch, by the way. I'm using it and it works perfectly!