Hi,
It seems that KDE Connect somehow manages to ditch some of my mp3 tags during transfer. Half of an album is properly tagged and the half is just filenames. Any idea where to check? (Google doesn’t show anything relevant).
Thanks!
IMHO impossible, kdeconnect only transfers files. Check whether the originals were properly tagged.
Yes, they were, as I had to create them manually after ripping CDs, and each and every one is done the same method.
:\ … don’t see how that could happen either.
See what the SHA1 checksum is for the file before and after transfer, if it’s the same, which it should be, then kdeconnect’s not the culprit.
What are you using to look at the tags with (before and after), is it a simple case of tag version, not all tracks tagged with the same version?
maybe it’s an id3 v1 and v2 issue maybe you only wrote v2 and your android app reads v1 or vice versa, what app did you use to rip them check it’s options and see if both v1 and v2 tags are saved
as id3 tags are saved inside the file if the file transfer is incomplete then those files shouldn’t play on your droid
I think some windows apps save metadata as alt file stream if you’re copying from ntfs to fat (android storage is fat) there will be metadata loss
you could try and pass one of those files to ffmpeg without any switches to see if they’re OK
Hi,
I used the tagging inside Amarok. Would it be better to use something else?
Problem is, it detects half of the tags in an album, and the other half it doesn’t 
Not necessarily, but first you need to establish why the tags are missing. One step at a time…
Problem is, it detects half of the tags in an album, and the other half it doesn’t
On the computer install “kid3” openSUSE Software
Use that to look at all of the (tracks) tags on one of the problematic albums to see what has been written by amarok.
If they are all OK and the same ID3 version then eliminate the (remote) possibility of kdeconnect having caused the issue by checking the SHA1 checksum of a transferred (problematic) file. Find the checksum of the file on the PC, then transfer the file PC -> Device, then Device -> PC, find the checksum again on the PC, the second should be identical to the first.
Hi,
thank you for your input guys.
I looked at the files via kid3, and everything seemed in order. Just in case, I ‘uniformed’ the tags in kid3 to make it full-proof, but the problem occured again. So then somehow miraculesly mtp through Dolphin managed to copy the files to my phone, and no tags were in any kind of disarray. Then I tried through KDE Connect again (we’re talking about the same album I used specially for this), and it borked half of the tags up again. I just don’t have time, so as soon as I can, I’ll try the hash after copying to see what’s up.
Thanks again.
A quick search on KDE bugzilla, which I must admit I didn’t do before, returned this amongst others… 383069 – Corrputed mp3 files when sent through KDE Connect Maybe relevant, I only read the first couple of posts though.
Sounds pretty similar. Will try this:
Can you try using the filesystem browser to copy/paste the file? If I recall correctly, the 'right click>send to' option has always worked without corruption. The corruption only occurred if one used the filesystem browser to copy/paste the file. If I understand correctly, the transfer was disabled on the Android side for large files, as a temporary workaround, and the actual fix is to change the mount options kdeconnect uses (See cpmments 12 and 13). As of now, the 'send a file option' works for me too, but the large file transfer via sshfs is still disabled. Hence I was wondering if a desktop release with the fix is planned soon.
and report soon.
Thanks a lot!
Forgot one solution could be to copy it via Amarok. Will be using that method until something better should arise.