Re: [APP] - version 4.34.+ ( 05/2026 )

[Graf Geo]

Are there definitely some geotagged JPGs in the missing folder?

[Tapio]

Are those shown in Google Photos? I'd refresh the Android MediaStore. @Menion, does LM maybe trigger that, via "Full Rescan"?

[slarti76]

Are there definitely some geotagged JPGs in the missing folder?

Oh man, I'm so sorry! I checked again with another app, and the Geotags in this folder are missing. I have all my pictures geotagged since at least 10 years, but this folder from 5 years ago is missing them.
So nevermind!

[Menion]

@slarti76
I was already looking at the problems with the track editor mentioned here. It should already be fixed in the latest version, isn't it?

[Menion]

Version 4.34.1.1 (22.5.2026) .. have a nice weekend!
  - chg: completely new Garmin IMG map renderer
  - add: (SILVER) track elevation chart area fill is now color-coded by slope magnitude — green (<6 %), yellow (6–12 %), orange (12–20 %), red (>20 %)
  - add: (SILVER) support for Bosch eBike Smart System sensors (v19+) — live battery, speed, cadence, rider power, odometer over the Bosch Live Data Interface
  - chg: (SILVER) Specialized eBike sensor support extended to TCX 2/3/4 protocol generation (post-2019 Vado / Como / Creo / Levo gen 2 / PLW)
  - add: (SILVER) support for Shimano STEPS e-bikes (EP-8 / EP-801 / E5000 / E7000 / E8000 / EW-EN100) — live battery, speed, cadence and assist mode over BLE
  - add: (SILVER) dedicated picker entry for Fazua e-bikes (Ride 50 / Ride 60) — collapses the previous "pair as power meter + pair as speed/cadence" two-step workflow into a single connection
  - add: (SILVER) extended e-bike telemetry — motor power, motor temperature, battery health, battery temperature, battery charge cycles, remaining range, altitude gain/descent and gradient (surfaced when the bike exposes them); Shimano STEPS now surfaces the current gear and uses Shimano-specific assist-mode labels (Boost / Walk)
  - add: (SILVER) bicycle gear and remaining range from e-bike sensors are now selectable as dashboard variables (Add panel/cell → Sensor)
  - add: (SILVER) support for BT4 footpods (SIG Running Speed and Cadence profile) — Stryd, Polar, Wahoo, Suunto and others; complements the existing ANT+ footpod with the more common BLE flavour
  - chg: Expert settings: the two separate "high precision" toggles for altitude / angle are replaced by a single "High precision mode" switch that also covers distance rendering
  - fix: crash in NTRIP client when the caster dropped the TCP connection while the app was in the background
  - fix: direction arrow in search/MyLibrary now always hardware to display proper orientation

[Andrew Heard]

do you ever sleep @menion? latest beta just 2 days after 4.34.1!

[freischneider]

The bike sensor is great. Added the Shimano EP8 sensor / battery level to the dashboard. Works great.
Thanks
Question: Does the Bluetooth connection drain the battery constantly? Or only when the screen is on?

[slarti76]

@slarti76
I was already looking at the problems with the track editor mentioned here. It should already be fixed in the latest version, isn't it?

Oh, sorry, didn't check that correctly - can confirm it's fixed!

[slarti76]

- fix: direction arrow in search/MyLibrary now always hardware to display proper orientation

Cannot confirm Now, being based in Zurich, search e.g. for Warsaw shows an arrow pointing to NNW - and Warsaw is clearly east. I did some other searches, and there doesn't seem to be a consistent pattern (like 90° rotation or the like). Distance seems correct, tho.

[Joska]

I think, it depends on the vertikal and horizontal orientation of the phone, the arrows turns depending on both.

[slarti76]

I think, it depends on the vertikal and horizontal orientation of the phone, the arrows turns depending on both.

Now I get it: It's not screen orientation, it's phone orientation! They arrows actually turn when I rotate the phone. I guess that makes sense for closer destinations, not so much looking for a far away city. 

The main misunderstanding is that I'm thinking "planning", but the actual purpose is "on the road".
I think ideal would be to have two modes:

• On the road: As now, direction from current location, using phone orientation
• Planning: From current map center, using static compass directions

But I admit, probably too much effort for small detail...

[Ulrich Kiermayr]

I think, it depends on the vertikal and horizontal orientation of the phone, the arrows turns depending on both.

Now I get it: It's not screen orientation, it's phone orientation! They arrows actually turn when I rotate the phone. I guess that makes sense for closer destinations, not so much looking for a far away city. 

The main misunderstanding is that I'm thinking "planning", but the actual purpose is "on the road".
I think ideal would be to have two modes:

• On the road: As now, direction from current location, using phone orientation
• Planning: From current map center, using static compass directions

But I admit, probably too much effort for small detail...

Testing and thinking about it:

When the map is locked in "north up", the search should also respect that and show the arrow with respect to north up. (To be consistent with the map shown)

When map rotation is on, then the search should behave like it does now.

I think, this would resolve most of the confusion. Search should simply behave like the actual behavior of the map

Greetings, Ulrich

[slarti76]

I think, it depends on the vertikal and horizontal orientation of the phone, the arrows turns depending on both.

Now I get it: It's not screen orientation, it's phone orientation! They arrows actually turn when I rotate the phone. I guess that makes sense for closer destinations, not so much looking for a far away city. 

The main misunderstanding is that I'm thinking "planning", but the actual purpose is "on the road".
I think ideal would be to have two modes:

• On the road: As now, direction from current location, using phone orientation
• Planning: From current map center, using static compass directions

But I admit, probably too much effort for small detail...

Testing and thinking about it:

When the map is locked in "north up", the search should also respect that and show the arrow with respect to north up. (To be consistent with the map shown)

When map rotation is on, then the search should behave like it does now.

I think, this would resolve most of the confusion. Search should simply behave like the actual behavior of the map

Greetings, Ulrich

Very good idea! +1