Does Duet have stability issues unique to receiver/controller connection/interaction?

[Redrum]

One issue with a receiver is that users have tended to hide it away or right up beside other kit - unlike radio and touch which are on full display.

Signal is never great if a receiver is placed behind an amp or at back of a shelf.

agree, but in this test, they were both on the same shelf, next to each other, next to the receiver, but a couple feet away. Not to say that made the WIFI reception equal, as the internal antenna design and configuration/orientation differ. I did check the wireless signal strength of the receiver in settings, advanced, and it was about 50%, but who knows where "acceptable" is.

I have 3 receivers running at my house, all via wifi, in occasional use locations (outdoor speakers, etc), and it seems like after a period of non use, they get lost (don't appear on the list of players) and have to be reset. I don't know why, I don't seem to have to have this problem with touch/booms/radios.

The thing that is difficult with friend is he is not technically inclined, and my visits are not that frequent and on the short side. I really don't want him to sour on the SB experience, so I need to get him stable the best way I can.

Thanks for your thoughts, Jim

[bpa]

I have 3 receivers running at my house, all via wifi, in occasional use locations (outdoor speakers, etc), and it seems like after a period of non use, they get lost (don't appear on the list of players) and have to be reset. I don't know why, I don't seem to have to have this problem with touch/booms/radios.

I have a receiver which is wired and every so often it drops off - LMS can't see it and vice versa. My issue is due to DHCP because when I use Net::UDAP configuration to tool to look at its internals (receiver is still on net just not talking to LMS) - the relevant IP addresses are not updated.

edit:
If technically minded - you could try using net::UDAP and check a "fallen" receiver if it is still on net and check the settings are OK to talk to your LMS.
https://github.com/robinbowes/net-udap

[Redrum]

edit:
If technically minded - you could try using net::UDAP and check a "fallen" receiver if it is still on net and check the settings are OK to talk to your LMS.
https://github.com/robinbowes/net-udap

My receivers are at my other location, and one is bound to be "missing" when I go home, so I'll try that, thanks! But, what to do if this is the case? Is there a solution?

Jim

[bpa]

If you can Net::UDAP working (easiest on a linux/Ubuntu ). It's hardest on a WIndows system as it means installing Perl first.

Ideally when player is workign note IP address of LMS server and IP address of players - found on WebUI Settings/Information

When a player has dropped off .
1. Check the IP address that LMS thinks the player now has - found on WebUI Settings/Information
2. Check router to see what address router thinks player has.
3. Use Net::UDAP to contact player and get player to dump the IP address it is using and the IP address of the LMS server it wants to talk to.
4. If step 3 fail because Net::UDAP can't make contact - then reason for player dropping off is not just DHCP. If using WIfi perhaps due to power saving, or newer 802.11 features such as roaming.

[w3wilkes]

If you can Net::UDAP working (easiest on a linux/Ubuntu ). It's hardest on a WIndows system as it means installing Perl first.

It is really no harder on windows. You don't need to install Perl separately. You can get a full function .exe for Windows that doesn't require a Perl install here;

http://slim2lirc.myown.mailcan.com/udap_shell_1_0_0.exe

[Apesbrain]

...or maybe I can build him a picore with display.

If your friend has a tablet or cell phone, you don't need a display and the experience is about as convenient as Squeezebox gets:
https://forums.slimdevices.com/showt...ard&highlight=

RPi, DAC board, power supply, and case will run you about $100 on Amazon or you can buy one pre-built on allo.com. If it ever stops responding, just unplug power and plug back in. Mobile control app is free or a few bucks.

P. S. The Radio via headphone out is not that bad. Add a mobile controller and it's pretty much the full experience.

[Redrum]

Thanks to all;

Regarding tablet or phone, I realize no display is needed, I use squeeze control, but find I still like the display, rather than pulling something out of my pocket, or if someone other than myself wants to operate it. Actually, the radio is a nice front end, and they are going for about $50 on the bay. I built a pi for another friend (server with usb hdd for library), and a radio as the player. Its a good non techie ui, with the buttons and volume dial, presets, and display. With the bonus of portability with a battery.

I only mentioned the sound quality maybe not being the same as say the receiver/touch is I have played them side by side, and it seems at least the gain is different. Maybe the radio solution is best in the end, unless I run across another touch on ebay.

Regarding net:UDAP, I am an engineer, and can get around home network stuff, but other than that, IT things and the latest software development environments/languages can be a bit of a foreign language to me. I stopped actively coding at C, before it got the "++", and on unix, before there was linux I guess I am still stuck on this, once I run this test, what do I do with the results? Does it lead to a solution, or rather just a validation that the receiver can hang up?

My friend constantly complains that his internet has problems, and feels the ISP is the issue, but I think there are simple things that can be worked on to improve everything. I think that's where I need to focus my efforst to help him. Things that allot of you have been kind enough to suggest.

Thanks again for the help.

Jim

[bpa]

Regarding net:UDAP, I am an engineer, and can get around home network stuff, but other than that, IT things and the latest software development environments/languages can be a bit of a foreign language to me. I stopped actively coding at C, before it got the "++", and on unix, before there was linux I guess I am still stuck on this, once I run this test, what do I do with the results? Does it lead to a solution, or rather just a validation that the receiver can hang up?

Net::UDAP is not hard but it is "technical" in that it has a command line interface with rigid command structure and produces output which looks a bit arcane but it is easy to offer guidance

You have a problem which can be caused by a number of possibilities. The output from Net::UDAP may help eliminate some possibilities and so enable you to focus trying to find a solution.

If the problem is DHCP - then reconfiguring the router usually solves it.
If the problem is WiFi power saving by LMS server or router - again disabling options may fix it.

If the problem is caused by say a rogue device (e.g. IIRC a few years ago a smartTV which had uPNP enabled caused packet storms and knocked players off) - it will take more effort as Net::UDAP will probably only exclude possible causes.

[Redrum]

Net::UDAP is not hard but it is "technical" in that it has a command line interface with rigid command structure and produces output which looks a bit arcane but it is easy to offer guidance

You have a problem which can be caused by a number of possibilities. The output from Net::UDAP may help eliminate some possibilities and so enable you to focus trying to find a solution.

If the problem is DHCP - then reconfiguring the router usually solves it.
If the problem is WiFi power saving by LMS server or router - again disabling options may fix it.

If the problem is caused by say a rogue device (e.g. IIRC a few years ago a smartTV which had uPNP enabled caused packet storms and knocked players off) - it will take more effort as Net::UDAP will probably only exclude possible causes.

I do appreciate the help and information, but I guess I wonder if any of this will explain why a receiver hangs up, but a touch, boom, or radio don't seem to have this problem. If it's a network issue of sorts, would it not affect all players? I go back to my original post in this thread, wondering if anyone had experience where a receiver is less stable than the others. I was hoping that perhaps there was a know quirk that someone knew about.

In the end, the receivers are my least favorite players, but when they work they do the job. I think the answer is just to let my friend keep the radio, or, look for a touch for him. Then, as I continue help him get experienced in the SB world, develop his library, discover plugins, use a phone app, etc, gain confidence in the system, then maybe we can determine what he really wants in terms of user experience.

Again, in no way am I dismissing your guidance, I just think that the easiest way to solve HIS problem, is to avoid the receiver. For myself, the receivers (currently using 3) hang only occasionally, so I just reset 'em when they do.

Thanks for your help again, it's always fun to learn new things;
Jim

[dolodobendan]

I have a receiver which is wired and every so often it drops off - LMS can't see it and vice versa. My issue is due to DHCP because when I use Net::UDAP configuration to tool to look at its internals (receiver is still on net just not talking to LMS) - the relevant IP addresses are not updated.

edit:
If technically minded - you could try using net::UDAP and check a "fallen" receiver if it is still on net and check the settings are OK to talk to your LMS.
https://github.com/robinbowes/net-udap

I, too, had problems with my receivers (one wired, one wireless). Mnyb hinted that I could try fixed IPs. Never had any problem since.

(However, the Touches don't seem to be affected by whatever is causing this and work just fine with DHCP enabled.)