@Mff73 Thank you, yes this worked. in app -> forget device -> clear app cache and data -> uninstall app in watch -> disconnect device on phone -> install app -> start in app -> sign in -> connect device -> enter code-> starts syncing -> deleted move shows up as notification and in my activity log… Back to work, thanks!

@luboskovar this is just my personal opinion - no idea what Suunto product managers plan… But this idea makes kind of sense. You can’t please anyone anyway with what you deliver for analysis. At the same time there are numerous data bases out there and everyone has it’s one preference/history with those. I for myself use Endomondo, other like TrainingPeaks, runalyze etc. So it totally makes sense to enable users get their data into their preferred tool. Then add some day to day data like steps, sleep etc in your own tool and you are done

@efejota I’ll report this. I am also not good with iOS or have tested well there

@fenr1r I have confirmed this and filed a bug with Suunto.

@Sergei-Ladeishchikov should be fixed in 2.45

Hi guys, I’m an owner of an Ambit 3 Peak and have troubles syncing my moves to the Suunto App. I have uninstalled the Movescount App and (re)installed the Suunto App several times (followed the procedure by @Brad_Olwin) but the issues remain. Some moves sync immediately, some require days if not weeks. Longer moves have more trouble. The watch starts syncing moves and the procedure fails. I have to initiate the syncing process over and over in order to get the moves to upload. But what’s funny… sometimes (rarely) the moves sync without any issues. Watch: Ambit 3 Peak Phone: iPhone 11 (iOS 13.3.1) Suunto App: 1.15.1 Haven’t found any patterns (battery status, network status, phone lock state, etc.) in the behavior. And another thing - pairing and syncing with a Samsung Note 8 works like a charm. Would be great if we had a sync through cable as a plan B.

Follow-up on my experience doing the actual race. Summary: I’ve used navigation with multiple waypoints during the entire 16 hours of the race After some considerable effort I managed to have the right set of waypoints at exact distances where aid stations were supposed to be on the race course. Two of the aid stations were visited during the race 2 times each. Other aid stations were visited once. Once I’ve had the correct preview of the waypoints in the app (see the picture above), the navigation was working mostly correctly, as expected during the race. The battery usage was exceptional - better than expected despite using navigation for the entire 16 hours and looking at the map and elevation profile most of the time. My Race 1 watch used only 27% of the battery in 16 hours, which makes the projected battery life over 59 hours. I used the High Contrast map theme. Also, I used an external HR sensor. I ran two S+ apps I was using Climb guidance 2.0 with all aid stations on the profile. That worked generally well and was useful. I could track both the remaining distance to each next aid station and the remaining ascent/descent. However I’ve run into two known issues that I’ll mention below. Both of these issues have already been reported in separate threads. [Issue 1]: The navigation route reversed twice during the race - both times when reaching the ends of out-and-back sections. This is something I’ve actually anticipated based on my prior experience - see https://forum.suunto.com/topic/12994/suunto-navigation-tendency-to-auto-reverse-route-when-it-shouldn-t.-bug-or-misguided-feature [image: 1760409898910-screenshot-2025-10-13-at-7.41.59-pm.png] This resulted in the watch showing incorrect profile and incorrect distance to next aid station until I was out of out-and-back sections. [Issue 2] The climb guidance profile could not be zoomed to the desired level of details at the end of the route. This is covered by https://forum.suunto.com/topic/13601/climb-guidance-2.0-issue-not-all-zoom-levels-are-available-at-the-end-of-the-route-see-picture. This was especially bad considering the 100 km distance.

I’m also in the same situation, app showing 58 h of recovery time, and the phone 47 h. I could perfom a photo but no more information will be added

@kingarv Did you manage to solve your problem?

@MaxiPalle I just tested this and it is working for me on S9 Baro Here are the steps: Make sure to force quit MC app Open SA and do NOT unpair from SA, simply forget the watch from the app, then select ok. Force quit SA. Open MC, the watch will automatically sync (if you select a route on the computer first, the route will sync). If you did not select a route on the computer but you select from the app, you will need to force quit MC and restart the app to restart the sync. The route will now sync with waypoints. Check to make sure the sync is finished. Do not unpair from MC app, force quit MC Open SA and select the watch to pair from the watch menu, it will connect and sync. You will lose custom sport modes from SA and have to set them up again but routes from MC with waypoints are retained. This is working for my S9baro with no issues I am on iOS13.3 and the latest SA beta.

No tricky solution on IOS from me, if uninstall reinstall doesn’t do the job. Eventually try on an Android phone if you can, and see. If it is the same “unsync” message, on android you could see if raw files are on the phone and at least get it from there. Good luck.

@egika said in iOS 2.7.0 deleted activities on the watch still sync to SA: this is still the case for the non-activity menus. You are right, just checked. But then, not sure why navigation in menu gets laggy for me. When the watch is connected all is okay, but sometimes I leave my watch behind and pick it up just before to starting the activity, then maybe sync kick in more quicker then I get into the menus (Ambit user here, not sure if that matters).

@trailcafe we think that it was related to S+ apps selection, rather than sportmode (though they could be remembered in sportmode)

@brave_dave my recovery on the app is ALWAYS 90% Watch on the other hand fluctuates

I have put this again to the Developers as I am also completely irritated about this issue.

I have been waiting patiently for this bug fix for at least 3 months now and nothing changed. I am using the Android version 3.64.2 release (3064200) and whenever I share a link from the app to open inside a browser, the ascent is way off. From my understanding, it is not something that is wrong in the app itself, it has to do with the sportstracker database and how the the website queries data, because the phone app displays it correctly - well, at least it displays it how the watch log displays it which in my books is OK. Please fix this and also enable the same range of data displayed on the shared web link as is available in the mobile app. Right now we can only see distance, duration, avg. speed, avg. pace, energy, max. speed, ascent, descent, graphs with poorly implemented analytical features, heart rate data that takes up way more space than needed and useless auto splits (where are my manual laps?). The phone app has a lot more useful features and at least we can now zoom in on the graphs … but still, who wants to do that on the phone anyway - it is OK if you want to check something quickly, but for analysing graphs I prefer to do it on my computer with a larger screen and a mouse for precision. Every time I start pinching and zooming on my phone I get nervous and want to throw it at the wall.

@dimitrios-kanellopoulos Congrats !! I’d like to say that it gets easier but…

@Brad_Olwin strange that you all were able to make about 32 hours. Maybe this is no transfer issue but the watch is simply running out of memory for all the data? Another idea: some operating systems have had file size limits due to the 16 / 32 bit data pointers… Same for backend data structures (Web / Movescount / SA)

I guess I jinxed my H10, first time this happened, this is from yesterdays run, it was a steady pace I don’t know what disturbed the sensor. Before and after that HR readings were ok. I updated firmware because I need ANT+. Maybe it was that, I’ll see. Even Polar is not 100% On ride afterwards it was flawless. [image: 1575197293169-sharedscreenshot.jpg]

@Dimitrios-Kanellopoulos Many thanks.