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

[Redrum]

Hi;

I have alot of user experience with sb devices since 2009, but I am not one of the "under the hood" guys that provide great support on this forum. I have used duet, booms, touches, radios, and now use PiCore as servers.

Anyhow, I have been trying to help a friend get started with SB (after he saw mine) and I gave him a duet to try, and to date we have only had it hooked up on mysb.com. We have had stability lock up issues which I discussed on this thread: https://forums.slimdevices.com/showt...-address-first

Unfortunately, he is not very technical, and most of my support has been via email, over the phone. I am only at his place in person after a bit of a drive (and I need to be invited )

He has allot of network interruptions that may be due to either the ISP or his wifi. Often the duet combo will lock up (Receiver white light, doesn't play, controller can choose player, but can't control it, remote control from mysb.come doesn't work). When this happes we need to do the controller/receiver rest process (press and hold controller until fast red flash, Power and '+' on the controller, go through the setup process).

I have seen this on my setups, but always through it was because of years back using an old LMS version, wifi issues, etc. I am thinking that I have not seen this with a touch, boom, or radio, but I am not sure.

My concern/suspicion is that there is a unique relationship between the receiver and controller (or possibly the controller and any other device it's connected to) that might cause a lockup when network exceptions happen, where an integrated UI system (touch, radio, etc) does not. The controller uses wifi to communicate to the receiver, where in integrated units, the UI does not. Maybe the "control link" is susceptible?

Has anyone seen something like this or have knowledge of it?

I think my path forward might be to give him a radio to try, then, maybe look for a second hand touch for him. I had thought a duet would be perfect (carry the controller to control outdoor speakers, etc...), but with this, and when I gave him the controller to try, he had to find his reading glasses (oops, hadn't thought of that )...so, maybe it isn't ideal for him.

I appreciate any thoughts.

Jim

[w3wilkes]

I didn't read your other thread, but what you describe here is classic network trouble. Here's some things that may help at your friends place...

Use a program like "WiFi Analyzer" on an Android phone and check to see how many networks are active in the location you're testing in the 2.4Ghz band. You should see active networks most likely on channels 1 - 6 - and 11. Set your router to use the one of these 3 with the least amount of SSID's showing in the WiFi Analyzer.

The controller talks to LMS, LMS actually controls the receiver so the controller really isn't part of the problem. The only time the controller talks directly to the receiver is when you set up the receiver. The way it works is that when you set up the receiver it gets the WiFi network credentials (SSID and security key) from the controller, once the receiver attaches to the WiFi network all control of the receiver actually comes from LMS. When you select music to play from the controller it actually is telling LMS to play music on the receiver.

If your LMS server has to be on WiFi you will have your best results it your router and LMS server run on the 5Ghz WiFi band so it won't conflict with the band that the player(s) are on. It's best to have the LMS server ethernet cable attached to the router.

Good luck!

[drmatt]

I have regular issues with my receivers going blue light locked up and requiring restart. And I don't have the duet controller powered up anywhere. They just appear to drop connection to their lms instance and stay dead sometimes.

Doesn't matter too much as I don't use them that often. The one I use the least is the least stable.


Transcoded from Matt's brain by Tapatalk

[Redrum]

Thank you both,

DRMatt, do I take it from your message that your impression is that the receivers are the least stable? I remember reading in other threads that the wifi antenna is not the best performing of the sb's (perhaps due to form factor). Do you have it hooked up via LAN or wifi?

w3w,


Yes, I have wifi analyzer, and yes, he had a conflict on 6. I tried to move him to 11 over the phone, but decided to wait until my next visit. But, both he and I have cabins in the woods in northern new york, so we see maybe one other network tops. BTW, we are both on the same lousy DSL service, but mine runs rock solid. However, my physical connection might be better, who knows with this provider.

I also looked via the settings in the receiver at the wifi strength it sees and it's about 50%. Not the greatest.

When you say that the controller speaks to LMS, is this also true for mysb.com I assume? Also, in my other thread I

My over time progression/plan for getting him setup is 1) player on mysb.com (current status) 2) add LMS, build a picore server for him. So for 1) and 2) it's all wifi with the server 2) being his windows laptop. For 3 the plan is lan into the picore. Right now the location of his router prohibits the receiver from beig hooked to the lan.

My plan moving forward is to change his channel, look into relocating his router from a back room closer to the living area, and I have a spare sb radio that i'll take down and hook up both, and see if one continues to operate when the other locks up. Maybe install LMS if I have the time.

Thank again, I was just wondering if there was a "known instability" that is unique to the receiver

Jim

[drmatt]

Just based on personal experience I would say yes the receiver is the least stable of the devices I've owned. That excludes boom, and the old slim devices hardware. I ran them both wired and WiFi and haven't noticed a great difference in reliability.

They are occasionally available cheaply though and are a good pain-free headless player. (If you can get them on your WiFi/network.)


Transcoded from Matt's brain by Tapatalk

[w3wilkes]

When you say that the controller speaks to LMS, is this also true for mysb.com I assume?

Hadn't really thought about that circumstance, but I believe when you switch to mysb.com it becomes the control point since your mysb.com info is stored in the controller during setup.

And I forgot to mention the "Bridged mode". If you have a wired only network the receiver can be configured to be an AP for the controller. In this configuration the receiver acts as a WiFi access point, but still this just uses the receiver to get controller commands to LMS and then LMS still is the thing commanding the receiver.

[bpa]

He has allot of network interruptions that may be due to either the ISP or his wifi. Often the duet combo will lock up (Receiver white light, doesn't play, controller can choose player, but can't control it, remote control from mysb.come doesn't work).

I think this answers your main query - since your system is using mysqueezebox,com and if the ISP connection is erratic then Controller will not be able to communicate reliably with mysqueezebox.com and similarly mysqueezebox.com will have problems communicating with Receiver and so overall behaviour will be very erratic as ISP connection affect both sets of communication.

[Redrum]

Interesting info, makes sense, with the receiver, controller, mysb, links all dependent on stable WIFI, and ISP as well, there's allot to break if things go bad. Good to know about bridge mode, but until we get a direct connection, we are stuck with wifi.

I'll be going over there with a radio, and will install lms, and setup the radio along with the receiver, change the wifi channel to a vacant one, and see what lives and what dies. I didn't set up LMS initially because his "music library" is boxes of CD's and listening to internet radio, pandora, etc was a good first step.

Thanks again to all,

Jim

[Redrum]

I have regular issues with my receivers going blue light locked up and requiring restart. And I don't have the duet controller powered up anywhere. They just appear to drop connection to their lms instance and stay dead sometimes.

Transcoded from Matt's brain by Tapatalk

Just thought I would bump this thread with an update. I took a radio to my friends and when I left both the duet and radio were operating (I ran headphone out to his receiver, so he only had to switch sources). After a few days, he reported that the receiver/controller were not working (blue light on receiver this time) but the radio was working fine. The radio continues to work. I guess the receiver is not a good fit for him until we can address some of his network instability.

Since the headphone out of the radio to the receiver don't seem to be equivalent sound quality to line outs (to me at least), I think I'll look for a touch for him, or maybe I can build him a picore with display.

Jim

[bpa]

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.

[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