Web UI over bluetooth very slow

Is it just me or is the web UI very slow over bluetooth? The slowest bit is the downloading of images, e.g. images for each effects pedal, and preview images of pedalboards in the view which shows all pedalboards.

I’ve tried this from both Linux and Android (and possibly MacOS X but I can’t remember), and they had the same issue. I suppose it could be an issue with the cheap Avantree Bluetooth USB dongle I bought, but it is supposed to be Bluetooth 4.0 …

Bluetooth is inherently slow, not much we can do about it.

If you have v1.2 you can load up this page via USB http://modduo.local/icon-all.html which will load all the plugin graphics. (do not attempt to load that under bluetooth!!)
After you loaded it once, the browser should have the images in cache the next time you load modduo.local, even if it’s using bluetooth.


Bluetooth 5 will double the transmission capacity – that should alleviate the problem a bit. First devices were said to arrive “end of 2016 to early 2017”.

1 Like

I looked at Chrome’s web inspector while using the Mod UI over bluetooth and it looks like the browser does a If-None-Match request for all images even if it is cached. The Mod responds with 304 (not modified) as expected, which does obviate the need to send the whole image again, but this still means an HTTP round trip for every image resource. Given the large number of individual resources, it would probably help performance quite a bit if the browser was able to use the cached response without checking for modification first.

This behavior is strange because the Mod UI responds to image requests with Cache-Control: max-age=315360000, which should let browsers use the cached resource without checking (for ten years!). My guess is that this is because the responses have a bogus Date header: Date: Thu, 01 Jan 1970 02:25:26 GMT which breaks the max-age cache logic.

Would it be possible to have the Mod set its clock from the UI client? Short of that, I think the correct behavior according to RFC 7231 section is for the web server (Mod UI) to omit the Date header completely:

An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time.

This should work correctly because a client receiving a response without a Date is required to use the receive time as the Date.

1 Like

My two cents: having the mod duo web server enforcing the HTTP 2 protocol might also help improve performance as it allows persistent and multiplexed connections (effectively limiting the tcp round-trips while loading resources.


1 Like

Great idea to support HTTP 2 but wouldn’t it be better to prefer rather than enforce it? Otherwise the UI would stop working with browsers which don’t support it.

Very interesting findings!
I’ve done some tests, and implemented the needed bits to make the webserver skip date/last-modified headers.
See https://github.com/moddevices/mod-ui/commit/5dc4aab0f9371ce3bb36be5f896173d9a511e6fd

Confirmed to skip a bunch of 304 round-trips now.
Thanks for the heads up here.

This will be added in upcoming v1.4 release.


Excellent! Will look forward to the update.

This was last discussed 3 years ago … While from memory things did improve thanks to work from @falkTX and maybe others, unfortunately I still find this to be painfully slow. Given that the main use case is for minor “emergency” tweaking at gigs, the speed is kind of problematic.

As mentioned in Save preset edits when not attached to GUI?, I’ve hunted high and low for a dongle faster than Bluetooth 4.0 but not had any luck finding one yet. Does anyone else have suggestions for improving the speed of the web UI over Bluetooth?

Or perhaps there is another way, such as using a wifi dongle which would allow communication via an access point or via Wi-Fi Direct mode?

We have been optimizing the cache strategies the last few releases, so I imagine that will help a lot in here.
But you do have to ensure to use http://modduo.local/ (or http://modduox.local/ if Duo X) so that the same resources are used for both USB-Ethernet and Bluetooth.

1 Like

Ahhh thanks, that might explain it, because for some reason my phone’s mDNS doesn’t recognise modduo.local when I connect it over Bluetooth. Any idea why this might not work on a not-ancient Android 9 phone?

on android? no idea…

just getting the full IP to work, in my tests, required me to disable wifi and mobile data.

the old idea of using to let the browser download and cache all installed plugin resources still applies.
But on a phone… that might kill the browser :stuck_out_tongue:

Wifi connectivity might be the only really good solution to this problem …