Using Android mobile with activity binary protocol, running pace zone percentages are displaying up to 15 decimal places. Display is normal when binary protocol is turned off.
Also just checked Linux x86_64 desktop and it is the same as above.
Using Android mobile with activity binary protocol, running pace zone percentages are displaying up to 15 decimal places. Display is normal when binary protocol is turned off.
Also just checked Linux x86_64 desktop and it is the same as above.
Thanks. I have just fixed this.
I have added binary protocol support for chats. If you have a lot of chats (I have 600+!) then this helps.
Should this affect the load speed of the /compare page? That is the one I am most interested in seeing a speedup on (and it still takes a long time with binary fetching enabled)
No these speedups wonât help with that page. How many activities are you comparing? It shouldnât be particularly slow. It might take a while to get data if you compare activities that you havenât looked at in the last 30 days because data has to be fetched from cloud storage.
Looking at the season compare page, not activities compare. It takes about 2 minutes to fully load in the last 4 years of data.
So far so good with the new binary protocol!
I have no chatâs, but as soon as I enable âbinairy chats protocolâ no activities will be loaded.
If I uncheck the protocol they load fast, but enabeling the protocol again and nothing loads.
This is on Android Chrome.
I have fixed that bug, will deploy tm. Tx.
There is a general problem with Safari on Mac and iOS and the binary protocol, not just with chats. Binary messages above a certain size cause the WebSocket connection to close. Activities âworkâ because the server streams them back in small batches. I spent half of today trying to figure this out.
I have added support for browsers stuck behind corporate proxies that block WebSocketâs. Unfortunately this means that if the binary protocol causes Safari to break it is likely to fallback to SockJS. You might not notice immediately but the performance is much slower. This is what appears at the bottom of the /settings page:
You should turn off the binary protocols one by one (starting from the bottom of the list) to see if that works.
It looks like the issues with Safari and the binary protocols are fixed. Please turn all of them on and post if you run into anything. For the Java devs out there: I had to replace Tomcat with Jetty. It seems Tomcat does something with binary WebSocket messages and compression that Safari doesnât like.
The binary protocols are now enabled by default for everyone. If you had previously used the checkboxes on the /settings page to toggle them on/off these take precedence.