• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Couple of small bugs and a feature request
I use MSP on four Onyx Boox Max 3 tablets for gigs with a string quartet. When I add new pieces I put them on one tablet into four different libraries (one for each instrument). I then update the four libraries on the other three tablets using the sync function over bluetooth. That means 12 syncs each time but it's fast so not a huge problem. Since the v3 update I've been getting a bug where 2 or 3 times out of the 12 a sync will fail and it says that the database type was wrong (it was expecting type 57 but got type 0). Usually if I just try the sync again it works but sometimes I have to re-start the app. I'm using version 3.0.10 in the eInk build.

I also had a glitch at a gig last night where we'd taken a break for an hour and I'd left the tablets on and connected by bluetooth. When we started playing again one of the tablets kept disconnecting and re-connecting from the master tablet every few seconds. I turned off the BT connection for that tablet and it's fine again now and I haven't tried to replicate it - just hadn't seen it before and thought it might be worth mentioning.

Feature request. For each of the tablets I've changed the bluetooth device name so that they each have a unique name. When they're connecting via the master/servant feature (sorry, have forgotten what that feature is called now) I can see the unique name of the master tablet on the servant tablets but on the master tablet where it lists the connected devices it just has the model name for each of the servant tablets (Onyx Max). It would be great if that list gave the unique names so that if one tablet isn't connected I know which one it is.

Otherwise the app is still working really well for me. I tell the other local gigging musos about it. They're mostly ipad users and a lot of them use forscore but would like to have the MSP functionality - from what they say I don't think forscore has an equivalent to the master/servant function among others. Looking forward to being able to tell them the iOS version is ready. Also very much looking forward to the versioning update - hope that's still in the works. Guy
I'm not sure why you are seeing the issue with the database type being reported as 0. That sounds to me like some of the data is being garbled over bluetooth as I'm not doing any kind of integrity check on what is being sent. I'm not a big fan of bluetooth as I find it to be fairly unreliable. I don't have anything implemented in the sync functionality where it can request that data be sent again if it wasn't correct the first time around. That would require massive changes to the design that would most likely introduce all sorts of problems along the way. I'm relying on the messaging to be correct because I'm using TCP and it's supposed to just be on a local network (or over a short distance with bluetooth), so I didn't think that it would be necessary to add my own layer of reliability on top of that. I should mention that very little code changed for version 3.0.0 with the sync functionality. I had to add some new checks for the new annotation data, and I moved the database initialization to the start of the sync instead of reading things out piece by piece (as this is slower overall), but I didn't really change anything that would explain why you are seeing more problems now.

As far as the second issue you reported, that sounds like an issue with the OS and the bluetooth stack. I've certainly seen issues like that when connecting to other bluetooth devices with my phone (not related to MobileSheets), so I think that's just the nature of bluetooth. As I said, I don't find it to be particularly reliable and it can't handle large data transmissions at all.

As far as your feature request, the name that is listed on the leader device is obtained by combining android.os.Build.BRAND and android.os.Build.DEVICE, which is where the Onyx Max comes from. This is used for both WiFi and Bluetooth. On the client devices, since they have to list a name before they've actively connected to the leader, I use the BluetoothDevice.getName() from the device that is detected while scanning, so that's why you see the bluetooth device name you assigned. If you would like me to change the behavior so that the server lists the BluetoothDevice.getName() value as well, I can certainly do that. I have made that change in my code and it will be available with the next update. 

As far as the future plans, the iOS version will come first, then the song versioning. Thanks for spreading the word to your fellow musicians!

Cool, thanks for adding the assigned name to the server list.

Thanks for explaining the bluetooth glitches I'd seen too. I might give wifi a try for the server/client connection and see how it compares for reliability and battery use. Please don't add error correction to the sync feature on my account. When the glitch happens it's right at the start of the process so it's very quick and easy to start it again. I might try that with wifi next time too - assuming it's a BT issue then that should resolve it.
I did the sync via wifi and that worked fine - super fast and no failure due to database type. I also tried out the leader/follower connection via a wifi hotspot from my phone and that all went smoothly. I imagine it will use a bit more battery than BT but should be more reliable.

I noticed that the settings for the leader/follower function has a 'device name' field that can be changed so I set it for each follower tablet and it came up on the leader when they subsequently connected but when I disconnected and re-connected them the names all went back to Onyx Max. Should it be possible to set a device name through those settings and have them persist?
Yes, the names should be persisted. I'm not sure why it reset - I'll have to look into that.

I tried using wifi instead of bluetooth for the leader/follower connections at gigs yesterday. The connection was very solid and it didn't seem to change the battery usage on the tablets (at least not on the follower tablets - I didn't check the battery usage on the leader) as compared to using them with wifi switched off. For the wifi connection I was using a hotspot from my phone and it did chew through the phone battery a lot though so I ended up doing the last hour or two back on bluetooth connection instead. Not sure how many people use MSP for the leader/follower function but thought that info might be useful to those who do.
Quick update - the device name entered on the connection settings dialog was not being saved, so I've added code for the next update to save whatever value is entered so that you don't have to change it each time. Thanks for letting me know about that.

Sweet, thanks. Next on my wishlist is the versioning update but it would also be great to be able to edit the list of filters that come up on the library page.
I just updated the Max 3 tablets to v3.1.0 and the follower/leader function is working nicely. The device names that show up now depend on whether the connection is bluetooth or wifi. With wifi the names allocated in the follower settings show up on the leader and with bluetooth the device name that can be set through the OS bluetooth settings is used. I've made the bluetooth name and the follower/leader name the same for each device so that it doesn't matter which connection I'm using but either way the names that show up can now be unique to each tablet which is great. Many thanks
Glad to hear it's working better for you. Thanks for suggesting the change.


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
1 Guest(s)

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.