Bug 421613 - Geotagged pictures lose gps data after wifi transfer with kdeconnect
Summary: Geotagged pictures lose gps data after wifi transfer with kdeconnect
Status: CONFIRMED
Alias: None
Product: kdeconnect
Classification: Applications
Component: android-application (other bugs)
Version First Reported In: 1.3.5
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Vaca Cintora
URL:
Keywords:
: 453350 454617 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-16 12:17 UTC by Robert
Modified: 2024-08-08 18:19 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert 2020-05-16 12:17:28 UTC
SUMMARY
Missing gps data of picture taken with Android phone after wifi transfer using KDE Connect. Direct USB transfer of the same picture preserves geolocation data.

STEPS TO REPRODUCE
1. Take a picture with Android phone with location saving enabled
2. Transfer via wifi with KDEconnect to PC

OBSERVED RESULT
No gps data stored in picture file

EXPECTED RESULT
Picture EXIF geolocation info preserved

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Kubuntu 18.04
KDE Plasma Version: 5.12.9
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
Comment 1 Simon Redman 2020-06-04 18:31:27 UTC
Hi Robert,

What mechanism are you using when you say "Transfer via wifi"? Do you mean mounting the remote filesystem and copy-pasting, or do you mean using the send file feature of KDE Connect?

If you are using the send file feature, what app are you using on the phone to select and send the pictures?
Comment 2 Robert 2020-06-04 20:08:54 UTC
Hi Simon,
I used the send file feature of default Gallery app on Android 10 (Lineageos 17.1). 
Now that You mentioned it, I performed the same type of transfer with Ghost Commander file manager and it seems that gps data is preserved. Copying a picture file from a remote file system to PC also works without losing location info.
Thanks,
Comment 3 Simon Redman 2020-06-04 22:06:11 UTC
In that case, my best suggestion is to keep using the file manager to share the photos (or use the SFTP browser)

The reason this happens is because when sharing from a gallery app, Android doesn't give us just give us access to the file but instead gives fine-grained access to the different data and metadata in the picture. We would have to transport every piece of metadata individually and then assign it back to the file once transferred. It's not impossible, but I don't know if it will come any time soon.
Comment 4 Robert 2020-06-05 09:59:49 UTC
OK Simon, I think it explains the issue. Glad there's a workaround. Thanks again,


(In reply to Simon Redman from comment #3)
> In that case, my best suggestion is to keep using the file manager to share
> the photos (or use the SFTP browser)
> 
> The reason this happens is because when sharing from a gallery app, Android
> doesn't give us just give us access to the file but instead gives
> fine-grained access to the different data and metadata in the picture. We
> would have to transport every piece of metadata individually and then assign
> it back to the file once transferred. It's not impossible, but I don't know
> if it will come any time soon.
Comment 5 hong 2022-01-24 13:26:22 UTC
I have confirmed this problem on my Kubuntu 21.10, Plasma 5.23.5, Frameworks 5.90.0.
If I connect via USB, gps data is present.
If I attach the pic in Gmail or upload/download with Photos, gps is there.

So, it seems this is really an Android 12 security bug!
This is a relatively new issue 'cause it used to be just fine; 
DCIM folder gets mounted over wifi and my app simply copies the files.
Comment 6 jan etc 2022-09-20 19:14:42 UTC
Same issue when using   DCIM folder of device on PC 

https://developer.android.com/training/data-storage/shared/media#location-info-photos
Comment 7 cwo 2024-08-08 18:19:21 UTC
*** Bug 453350 has been marked as a duplicate of this bug. ***
Comment 8 cwo 2024-08-08 18:19:25 UTC
*** Bug 454617 has been marked as a duplicate of this bug. ***