Under some circumstances kid3 deletes files when tagging them. This happened to me when tagging files without padding that are not writable but can be deleted. The files where also placed on a samba share (I do not know if this is relevant). In this case kid3 showed a warning, that the file is not writable and the file was gone. It seems like kid3 writes a metadata_edit file and moves it over the original file when no padding is present. The metadat_edit file was also lost during this operation. Thus, it is impossible to restore the file without a backup. This happens quite often when using the internal preview feature to play the edited song or the file is accessed by some other application. Since it is a common approach to play a song in order to tag the genre, this happened more than once to me. Operating System: Gentoo Linux KDE Plasma Version: 5.21.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.11.6-gentoo OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-3770 CPU @ 3.40GHz Memory: 30.9 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4000
Kid3 does not do the tagging itself, it uses 3rd party libraries. The ".metadata_edit" string can be found in the sources of libFLAC, so I suppose that this library is responsible for this behavior. I would suggest that you use TagLib for FLAC files. Uncheck "OggFlacMetadata" in the "Plugins" tab of the settings and make sure that "TaglibMetadata" is checked. Then restart Kid3. Please check if the problem also happens when using TagLib.
Created attachment 136809 [details] dialog error writing
Created attachment 136810 [details] dialog change permissions
I have tried to reproduce the bug for later taglib testing and I can not reliably reprocude it (see below). I like do share the insight about OggFlacMetadata behavior before I continue testing with taglib. 1. play a track A in kid3 2. remove a picture block of A 3. save (takes some time over a slow connection) -> a dialog appears: "Error while writing file" (see attachment "dialog error writing"). At this point the track is still present. 4. select another track B for playing in kid3 5. save track A (applies imideately)-> now another dialog (YES/NO question) appears: "Error while writing file. Do you want to change the permissions?" (see attachment "dialog change permissions"). At point 5 Track 4 is already lost. Thus, the answer does not change any outcome. Hence, it seems there might be some behavior of kid3, that is actually involved in triggering the bug" - May it be, that the play feature does not properly close a file handler of A when playing B? - Somehow kid3/libflac seems to reuse the previously saved metadata_edit file on the second save. Independent of kid3 i sometimes observe on my network drive, that some file operations, e.g., deletion of files, do not immediately appear in my filemanager. In this situation I sometimes need to refresh the content of the folder to actually see the change. Thus, my guess here is that the problem somehow occurs with locking and not released files. Thus, kid3/libflac somehow assumes, that the metadata_file is still present, but actually it is not. Or, the file handle is still there, but the file is in some "to delete when file handle is release" state, such as described in another context here: https://github.com/atom/atom/issues/10596 => maybe kid3 can do something here by properly closing handled and/or syncing the folder content before the second save.
I am unable to reproduce the issue with taglib. For the picture removal scenario it just keeps the padding block (see Bug 434552) and thereby the rewrite of the audio data is not even triggered. Thus, I also tried another scenario in which an actual audio rewrite is happening: 1. remove the padding with metaflac 2. open the file with kid3. 3. play the file in kid3 4. add some additional data to the VORBIS_COMMENT 5. save metadata in kid3 Also the rewrite scenario worked flawless with taglib. Thus, I have the same question as in Bug 434552: Shouldn't OggFlacMetadata plugin be disabled by default? Is it still needed at all? If it is needed and kid3 cannot do any workaround to not trigger the bug, the user should actually be warned, that the plugin is dangerous on network drives.
Thanks for your investigations. Unfortunately, the situation is not so easy. Especially bug 864 (https://github.com/taglib/taglib/issues/864) is a reason not to recommend TagLib 1.11.1 for Ogg/Vorbis files. There were also a few other minor issues with Ogg and FLAC files, which were fixed for version 1.12, which was released recently on 2021-02-16. There are quite a few Linux distributions which still have TagLib 1.11.1 and not 1.12, and this will continue for a while because Debian is in freeze. So as long as not everybody is using TagLib 1.12, I will not change the default plugins.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
already provided the info
Closing this as a workaround exists - use TagLib.