Bugzilla – Bug 2140
Allow specification of SlimServer address by DNS Name
Last modified: 2013-05-01 12:24:56 UTC
To allow streaming over the internet from a SlimServer that is addressed via a dynamic DNS address, it would be handy to be able to identify a SlimServer via a DNS name; the current implementation of the SB2 firmware allows specification only by IP address. Another customer requested this feature a year ago, but was deferred because the SB2 firmware didn't have a DNS client implementation. With the recent deployment of SqueezeNetwork, SB2 firmware presumably does implement a DNS client. So can you now enable specification of SlimServer via DNS name? Thanks!
Yes, this is far more possible now. Not going to make it for 6.2, but will address as soon as possible after. Thanks.
this will also help the admin of a squeezebox network across multiple sites - currently you have to update each client when you move the server, but DNS name addressing would avoid this
This feature would be very useful across the entire SD/Logitech range, from the SB3 to the Transporter and the Duet. Should also be implemented in the Jive/SqueezePlay application.
This isn't going to be feasible in SB2/3, but we should add it for SBC/Duet.
(In reply to comment #4) > This isn't going to be feasible in SB2/3 Why not?
Since the SB2/3 can find SqueezeNetwork, how about using SN as an intermediary to connecting to a SqueezeCenter who's IP needs to be resolved through DynamicDNS or some other similar service?
(In reply to comment #6) > Since the SB2/3 can find SqueezeNetwork, how about using SN as an intermediary > to connecting to a SqueezeCenter who's IP needs to be resolved through > DynamicDNS or some other similar service? I must be missing something here. If the SB2/3 is capable of resolving host names such as those used for SqueezeNetwork and URLs of radio stations and whatnot, why can't it also use this capability to resolve the IP address of a SqueezeCenter server?
punting to 7.3
(In reply to comment #8) > punting to 7.3 > so is this happening in 7.3?
In reply to comment #9) > (In reply to comment #8) > > punting to 7.3 > > > so is this happening in 7.3? I sure hope so.. I have 3 remote devices now and it's a p.i.t.a. having to manually reset the IP address every time my ISP changes my WAN address. If remote playing was easier to setup, Logitech might actually sell more players. Surely this is a further step towards consumerisation of Slim software?
Felix/Andy: care to update/comment on this? Felix would you be the proper person to assign this too?
I like the idea of SN providing redirection across the internet to other SC instances. Those SC instances are already talking to SN. This is going to be prohibitively difficult to do on the player UI, I suspect, so let's push it to the computers and internet.
Yeah this is an SN thing. See bug 9152.
Some years ago I asked/suggested in a different context (that I unfortunately now don't remember where) that remote SBs (= outside own LAN) would get a resampled stream. If/when the feature of this registered bug/FR is addressed, it would be nice to be able define max quality of the stream per player. Oh, and it brings up the question of having multiple, passworded, user accounts on the SqueezeCenter, IMO :). Rgds, björn
bump .... still looking forward to the Duet (and SqueezePlay) supporting DNS by name as against number. I use my SBs across 2 homes, and unfortunately my SC 7.3 instance is located at the residence where the IP changes frequently. It has become quite painful to go lookup the IP from the DynDNS name on a computer before it can be entered into the controller. Perhaps a Lua applet that can do a DNS lookup might be a nice intermediate tool - at least the IP can be determined without having to rush to a computer.
Looking back at this as a Controller bug, I'm thinking we should just fix this on the controller/squeezeplay and let the user enter a domain name or IP address on the device. This should be an easy kill on that device, right, and require no SN infrastructure changes, right Andy and Ben?
*** Bug 11107 has been marked as a duplicate of this bug. ***
Hey guys - it's been 3.5 years on the 'todo' list. It seems like you know how to maybe do this - is the 'target' of 7.4 real or just a way to slip it down the priority list. My ISP is changing my WAN IP daily - I'm considering buying an ipod / dock solution to replace the 'never-working' SB3 in my work appartment if there really is no chance to get this. One other observation - running 7.2, if the player is connected to SN I can see it from the web UI (via SN), and I can select it to connect it to SqueezeCentre, but if the IP of SC has changed since the last time it was connected then the connection attempt fails (and loses all connectivity to SN too).
*** Bug 10626 has been marked as a duplicate of this bug. ***
bump ... has this fallen off the radar?
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the original product.
Reset priority before triage.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Just another bump - it seems incredible that this issue hasn't been adressed yet. With the Duet out and more new products (Touch and Radio) on the way, the number of people going for a NAS/SC/Logitech Device setup will most probably increase, and this is the kind of bug that can render it less useful. Softsqueeze accepts domain names, so SqueezePlay and the other applications should do it too.
*** Bug 11406 has been marked as a duplicate of this bug. ***
Tom Wadzinski is no longer available to us. We'll have to consider what to do with this bug.
Bump again. This would be far more useful than entering IP addresses.
If Tom Wadzinski is no longer available, someone else should take over his tasks, shouldn't it?
+1, I really would love to see this feature implemented. Many people are working with DDNS services. At least a tweak should be available.
If I put together a patch, will you guys consider accepting it? Do you guys accept changes from outside developers? The one thing I wouldn't be able to provide is the translations for any additional strings I might add. I'm playing with this in 7.5 to see how it goes.
i'm not offical in any way, but they do accept patches from outside devs. just upload the code changes to this bug. you might have to "bug" em a bit tho to get them to actually include/verify the patch. posting in the dev section in the forum helps.
I seem to have missed this bug's 5th birthday. It doesn't seem terribly complicated but would be very useful for me to get it fixed - it would get over some sundry network issues. Pretty please?
Will someone please add this feature?
Also, is the 'Depends on' still correct? Squeezeboxes do have a DNS client nowadays...
Wow. Users are still unable to listen to music remotely unless they hard-code an IP address into their player? The ancient SoftSqueeze (er, was that back in 2004?!) can add a server by DNS name, why can't SqueezePlay? Ridiculous! It's not exactly difficult to resolve a DNS name to an IP address now is it? Rant aside, *please* implement this.
Unassigned bugs cannot have a priority.
(In reply to comment #36) > Unassigned bugs cannot have a priority. perhaps assigning it ? it's on it's 6 year now....
This won't happen for ip3k. But the same request applies for newer players. See bug 17705. *** This bug has been marked as a duplicate of bug 17705 ***
Oops... this has been changed to cover SP too.
*** Bug 17705 has been marked as a duplicate of this bug. ***
*** Bug 15990 has been marked as a duplicate of this bug. ***
(In reply to comment #39) > Oops... this has been changed to cover SP too. That happens when bugs haven't been resolved in 7 years...
It would also be helpful if this would work on the controller as well. I'm using my Squeezebox classic to play music from my server that is 1000 KM away, it works perfect, only not if m y provider changes my padres. (once a month) Please make this work.