Posts: 38
Threads: 8
Joined: Dec 2014
Reputation:
0
12-03-2019, 06:11 AM
(This post was last modified: 11-05-2023, 06:39 AM by febus.)
Reconnection of tablets (wifi group) is not working reliably. We have to create a new group and join again almost every rehersal / gig.
Re-connect on start is ticked on...
Any way to get this functionality more stable?
Thanks,
Marc
Posts: 933
Threads: 84
Joined: Feb 2017
Reputation:
28
12-03-2019, 07:33 AM
(This post was last modified: 12-03-2019, 07:35 AM by Geoff Bacon.)
I don't use this feature so can't speak from experience.
If your tablets are Win 10 then the inactivity timer may be kicking in (this is common on desktop pc's where is program is busy for long periods with no user interaction).
So, in Win10, try one or more of the following-
- Extend the inactivity timer to 1 hour say (both Screen and Inactivity)
- Change the power options (you would have to experiment with what it offers)
- Set the wifi device so that it doesn't have power saving enabled (Device Manager| Network adapters| "Your Wifi adapter"| Power Management)
As you have multiple tablets, you might have to make sure all have the same settings (in case one failing is enough to trigger a problem on the rest).
Note: you could test by reducing the timers to a short time (3 mins say) to see if the wifi does in fact fail when the inactivity kicks in.
Geoff
PS: On rereading you post, it sounds as though you are having the problem each time you start a session rather than during a session. If this is the case, the above probably doesn't apply.
Samsung Galaxy Tab A6
Posts: 13,391
Threads: 302
Joined: Apr 2012
Reputation:
238
12-03-2019, 01:31 PM
(This post was last modified: 12-17-2019, 04:15 PM by Zubersoft.)
Hello Marc,
I'm going to need more information:
1) Are you connecting using WiFi or bluetooth? Bluetooth is more unreliable in general, so I might suggest switching to WiFi if possible using a hotspot. I can look into the bluetooth reconnection logic some more if that's what you are relying on.
2) If you are connecting using WiFi, are all tablets being assigned the same IP every time? If not, this is going to cause problems with the automatic reconnection code as it saves the IP address of the previous master.
3) Are all tablets Android? or do you have a mix? Is one tablet always the master or are you switching this each time?
Thanks,
Mike
Posts: 164
Threads: 35
Joined: Aug 2016
Reputation:
0
(12-03-2019, 06:11 AM)febus Wrote: Reconnection of tablets (wifi group) is not working reliably. We have to create a new group and join again almost every rehersal / gig.
Re-connect on start is ticked on...
Any way to get this functionality more stable?
Thanks,
Marc
Hey Marc
I've been using the Master/Slave function since it was featured.
I have about 12 tablets ranging from Android 5 to Android 9.
I had to buy a Verizon Hotspot in order for the M/Slave function to work properly as I found out that Android will drop any Wifi that doesn't have a connection to Google ... but that's another discussion in it of itself.
... nonetheless, I've never had a gig where the tablets stay connected to the Master. If the master screen is turned off or the slave screen is turned off, inevitably a few of the tablets will lose sync during the gig.
Our normal setup is such that I'm the MD and I have a Cue mic that feeds the band members' IEMs and I can tell them which song is next. For those whose tablets have lost sync to my tablet, they can just flip to the song. But last Friday we did a gig without our IEM system. 2 players' had their tablets that for whatever reason didn't keep sync to the master and they didn't know which song was next.
If you find an answer, I'd love to know what you found ... but for me, I use MSP at least 3x's a week with about 4-12 other musicians and I've never had a gig where the Master-Slave functionality worked flawlessly. As we all do during a set break, we turn off the screen to our tablets to save battery. I think that's the issue. When either the Master or Slave "sleeps", it'll lose sync. I know there was a "rejoin group" feature implemented a while back in an MSP update, but it hasn't been very successful for me.
I'll check back here in case you find a solution.
12 tablets (Insignia, ONN, Dragon Touch). Ranging from Android 5 to 9.
Posts: 164
Threads: 35
Joined: Aug 2016
Reputation:
0
12-17-2019, 12:57 PM
(This post was last modified: 12-17-2019, 04:15 PM by Zubersoft.)
(12-03-2019, 01:31 PM)Zubersoft Wrote: Hello Marc,
I'm going to need more information:
1) Are you connecting using WiFi or bluetooth? Bluetooth is more unreliable in general, so I might suggest switching to WiFi if possible using a hotspot. I can look into the bluetooth reconnection logic some more if that's what you are relying on.
2) If you are connecting using WiFi, are all tablets being assigned the same IP every time? If not, this is going to cause problems with the automatic reconnection code as it saves the IP address of the previous master.
3) Are all tablets Android? or do you have a mix? Is one tablet always the master or are you switching this each time?
Thanks,
Mike
Jumping in here.
I have the same issue. I can answer these questions based on my experience.
1) I always use Wifi. I have a Verizon Hotspot I purchased solely for MSP Master-Slave functionality.
2) I don't know. I have 12 tablets. We play at a different location every gig. Arriving at a gig and setting up 12 tablets and checking each one's IP address would be very cumbersome when I'm trying to organize a soundcheck.
3) All my tablets are Android. 1 tablet is always the master ... my tablet.
After a set break we'll return and I'll turn back on the tablets and some of them will have the layover window within MSP that warns that the group connection has been lost and asks me if I want to try to reconnect. Even if I say "yes" and tell it to quit asking me, it will show up the next gig.
I've sort of just dealt with the issues I've had with my tablets losing Master-Slave sync because we do so many gigs and I didn't really have time to investigate.
Does anyone else have a fairly large number of tablets they're running in Master-Slave mode without any dropouts?
12 tablets (Insignia, ONN, Dragon Touch). Ranging from Android 5 to 9.
Posts: 290
Threads: 14
Joined: Nov 2014
Reputation:
8
Using four Google's 12.3" Pixel Slates in master/slave mode on Bluetooth and finally it feels like 21st century sheet music.
Finally we are on the same page.
It was revelation for many of my colleagues.
Posts: 164
Threads: 35
Joined: Aug 2016
Reputation:
0
I can't use BlueTooth because there's a maximum number of devices that can be synced to a Master using BlueTooth. I think it's 6 or 7 (Mike helped me figure this out).
That's why I use Wifi.
I just asked my guitarist and he said the tablet lost sync halfway through the set. Which debunks my theory that the tablets will lose sync when either the Master or Slave's screen is turned off during our breaks.
12 tablets (Insignia, ONN, Dragon Touch). Ranging from Android 5 to 9.
Posts: 290
Threads: 14
Joined: Nov 2014
Reputation:
8
As I mentioned before I'm using 4 Google's Pixel Slates in master/slave mode connected via Bluetooth. Airturn bt105 pedal also connected to master.
I can confirm when I lock the screen for the break, screen will power off after 40 sec to save power. When I power tablets on after 10min break (using fingerprint) they stay connected bang on.
Not a single dropout.
Very happy with Bluetooth and its battery life.
Posts: 13,391
Threads: 302
Joined: Apr 2012
Reputation:
238
I think a lot of this comes down to three things:
1) The devices that are used
2) The OS version those devices are running
3) The router that connects them
I've run many tests in the past where I put the tablets to sleep for 15 minutes or more and when I turn them back on, they are all connected without issue (They don't even need to reconnect, they are just connected as the OS didn't sever the connection in any way). I have a few more tablets I can throw into the mix now, so when I get a chance, I'll try connecting around 12 devices over WiFi, see if there are any connection issues over an hour or so, then try putting them to sleep and see if that breaks the connection. If I had to guess based on past tests, I don't think I'll encounter any problems. This is one of those problems that is very difficult to solve if you can't reproduce it yourself. For example, is the reconnection code failing because different IP addresses are being assigned when the tablets reconnect to the router? Is there something in the network stack itself on Android that behaves differently across devices and OS versions? Are there bugs in my code that only occur under very specific scenarios when connection quality is low and the TCP code is disconnecting/reconnecting rapidly? It's really hard to say. I'll keep trying to address this, but I'm just grasping at straws if I don't see the problem in my test environment.
Thanks,
Mike
Posts: 4
Threads: 1
Joined: Nov 2019
Reputation:
0
I have the same issue. Although my situation is a bit different. I am simply using a network router (just plug it in, no need to purchase/pay for a hotspot plan unless you need Internet at your gigs). It would be great if I could just power up the tablets and they connect with the previous settings, but they rarely do. During gig, I keep my tablets on with no sleep, so once connected, they generally stay connected. All tablets are the same - Android, Kernel 3.18.22 (probably cannot upgrade). i played around with this several times to see if it's the server or client and really can't tell. I simply go into the Manage Device Connections and press New Master and for the clients select the group and connect. Simple button presses, but I would think the Reconnect devices at startup could handle.
You mentioned a different IP (which I assumed would not make a difference). I suppose I could create a fixed IP address for each tablet in the router settings - which might help. I agree this can be difficult to narrow down. If I could provide some logging info (maybe in the next release) I can dump the logcat to help narrow things down (I have Android studio to look at logcats)? Just an idea, which may not solve all of the above issues.
Mike
Posts: 13,391
Threads: 302
Joined: Apr 2012
Reputation:
238
The connection between each device is a direct connection (TCP) which means I need to know the IP address of the device to connect to it. That's what I'm saving at the moment and using to reconnect to that device. If I didn't rely on that, I'd have to change the logic to save some kind of unique identifier from the previous master (MAC address perhaps) so I can identify when that master is available to connect to again. I can look into making that change.
Mike
Posts: 4
Threads: 1
Joined: Nov 2019
Reputation:
0
Looks like the IP is the likely cause. When we practice (which we always do before a gig), I use our home network. And then use the wireless router just for gigs. And I can see the router is giving new IP leases. In addition, we have a 2nd wireless access point since our home has dead zones - so new IPs. Unfortunately, I cannot change the DHCP lease time on the netgear router I am using so I fixed all device IPs. Haven't been out giging yet to test, but several power-ups, and closing and opening mobilesheets many times automatically connect without a hitch using the netgear router. Not sure if hotspots have short IP lease times, but could explain if you break for a half hour or so. If MAC address could be used, I would think this would solve the problem. Thanks for the quick response.
Mike
Posts: 13,391
Threads: 302
Joined: Apr 2012
Reputation:
238
I'm working on the changes for using MAC address right now. It should be a more reliable approach. This does mean that after the next update, it will not be possible to connect devices on a lower version to devices on the current version (as they will be expecting different data).
Mike
Posts: 38
Threads: 8
Joined: Dec 2014
Reputation:
0
Hi Mike,
warming up an old topic. We still have issues with devices not re-connecting. I then have to create new group in re-join all devices. Has the change (MAC address) been implemented?
We are using several device types (iPad, iPad Pro, androids). Sometimes the clients are started before the master. Can this also cause an issue?
Thanks,
Marc
Posts: 13,391
Threads: 302
Joined: Apr 2012
Reputation:
238
Hello Marc,
Yes, I did change the code to use mac address. If there is an error with the device in retrieving that identifier, that could pose a problem though. What MobileSheets does is save the MAC address of the leader tablet, and if the leader changes IP addresses, MobileSheets will get the broadcast message with a different MAC address, and MobileSheets will recognize that the device is the same as the leader it was connected to, and will reconnect to that IP address instead. This only works if broadcast messages are being sent/received on your network (as I haven't switched to DNS SD for this yet). If you are using the "Direct Connect" option to connect devices, then this may not help, because no broadcast messages will be received, so MobileSheets won't know that the MAC address of the leader device changed. In this case, you'd need to modify the router to accept/allow broadcast packets, and you'll have to wait until I implement the changes to switch to DNS SD to turn that back off.
As far as your question, it will cause the initial connection attempt to fail, so it's not the best thing, however MobileSheets should attempt to reconnect periodically, so it should still work fine if you bring up the leader at a later point. Are you seeing the same problem across both the iPads and Android devices? Also, does the automatic discovery of devices work, or are you using the Direct Connect option?
Mike
|