GNOME Bugzilla – Bug 655752
Library Watcher corrupts ID3 tags if file handle is open on the file
Last modified: 2020-03-17 09:22:41 UTC
If the Banshee Library Watcher detects a new file, it imports it right away into the library. I found a problem with this behaviour: If you download a file from Jamendo directly into your music folder, Banshee corrupts its ID3 tags. Steps to reproduce: 1. Start banshee and activate the library watcher 2. Download an MP3 file directly into your music folder. 3. While downloading, look into the "Recently added" playlist in Banshee. The track will appear without any proper ID3 tag. 4. Try to rescan your library. The file does not get any more ID3 tags, they are corrupted. Any other player does not detect any tags, too. Expected behavior: The import process should only start when no file handle on this file is open. So the corruption on ID3 tags may be avoided.
I was asked to add a debug log, so I do :) I started Banshee with the debug options and (after several tries), I got the error reproduced: 1. Start music playing 2. Start download in Firefox from http://chemicaljump.com/2011/05/25/chemical-jump-guest-mix-10-nt89/ directly into your Music folder 3. Look in the Banshee Library, the track has no specific ID3 tags. The original contains correct information, as you can see in this screenshot (totem): http://imgur.com/i74kP I attached the shortened debug log. At the end, you can see the new file's import.
Created attachment 193499 [details] Debug log of the error.
Without really knowing what I'm looking for, I notice this, which seems suspicious: [27 Debug 18:10:27.916] Watcher: Deleted /home/philip/Musik/NT89-Chemical-Jump-Guest-Mix-10.mp3 [28 Debug 18:10:27.996] Watcher: Created /home/philip/Musik/NT89-Chemical-Jump-Guest-Mix-10.mp3 [29 Debug 18:10:28.096] Watcher: Created /home/philip/Musik/NT89-Chemical-Jump-Guest-Mix-10.mp3.part [8 Debug 18:10:28.945] Encountered a problem processing: file:///home/philip/Musik/NT89-Chemical-Jump-Guest-Mix-10.mp3 [8 Warn 18:10:28.945] Caught an exception - TagLib.CorruptFileException: MPEG audio header not found. (in `taglib-sharp') at TagLib.Mpeg.AudioFile.ReadStart (Int64 start, ReadStyle propertiesStyle) [0x00000] in <filename unknown>:0 at TagLib.NonContainer.File.Read (ReadStyle propertiesStyle) [0x00000] in <filename unknown>:0 at TagLib.NonContainer.File..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] in <filename unknown>:0 at TagLib.Mpeg.AudioFile..ctor (IFileAbstraction abstraction, ReadStyle propertiesStyle) [0x00000] in <filename unknown>:0 at (wrapper managed-to-native) System.Reflection.MonoCMethod:InternalInvoke (object,object[],System.Exception&) at System.Reflection.MonoCMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 It looks like the Library Watcher deletes and re-creates the file, then taglib-sharp is not able to read the audio header.
This is probably a tricky one. I did a few tests but wasn't able to reproduce the corruption. What options do you have enabled in the Preferences dialog, under "File policies" in the General tab ? The Library Watcher doesn't delete or create the file, it is notified (by the kernel or something) of what's happening on the file system. It seems browsers are downloading to a temporary file first, and of course they do that differently : Chromium 12 : 1/ When the download starts : create /path/foo.mp3.crdownload 2/ Download to the .crdownload file... 3/ When the download is finished : create /path/foo.mp3 with a 0 byte size and rename /path/foo.mp3.crdownload to /path/foo.mp3 Firefox 6 : 1/ When the download starts : create /path/foo.mp3 and /path/foo.mp3.part with a 0 byte size. 2/ Download to the .part file... 3/ When the download is finished : delete /path/foo.mp3 and rename /path/foo.mp3.part to /path/foo.mp3 I don't think we have a way to know whether a file is opened by another process, so I don't see a way for Banshee to handle this as proposed.
(In reply to comment #4) > I don't think we have a way to know whether a file is opened by another > process, so I don't see a way for Banshee to handle this as proposed. Agreed. IMO what we need to do is modify LibraryWatcher to ignore any event that comes from a file which has 0 bytes. Then later LibraryWatcher would get notified of a rename of a file, and the target file would have an extension that is in the whitelist, so it would import it correctly.
(In reply to comment #4) > Chromium 12 : > 1/ When the download starts : create /path/foo.mp3.crdownload > 2/ Download to the .crdownload file... > 3/ When the download is finished : create /path/foo.mp3 with a 0 byte size and > rename /path/foo.mp3.crdownload to /path/foo.mp3 BTW Bertrand I don't understand this step 3, I guess you mean just rename? Otherwise how can you rename file A to file B if file B already exists?
Hi Bertrand, thanks for coming back to this bug! (In reply to comment #4) > This is probably a tricky one. > I did a few tests but wasn't able to reproduce the corruption. > What options do you have enabled in the Preferences dialog, under "File > policies" in the General tab ? I'm sorry I cannot provide you with this information because I have Banshee on German. I made screenshots of the affected dialogs and I hope it will help: http://imgur.com/a/HFwSU Let me know, if I can provide more info.
I found another situation which I could reproduce the bug in. I had Banshee opened and grabbed a CD with sound-juicer 2.32.0-1[1]. As soon as sound-juicer starts grabbing the first track, Banshee detects the new file. From the first CD, only the first track was corrupted, from the second CD, the first two tracks are corrupted. Unfortunately, I don't have a debug log of it. I can probably reproduce it with a debug log. Banshee's option were constant to the situation described earlier. [1]: http://packages.ubuntu.com/natty/sound-juicer
A fix for bug #666981 was just committed, which should help with this bug : http://git.gnome.org/browse/banshee/commit/?id=cf2346be3 Could someone try to reproduce this problem with the latest git master?
I checked the bug against the Banshee daily ppa, as it may be fixed in 2.3.6. I ran banshee 2.3.6+git20120309.r1.8c50193-0ubuntu1+oneiric and kept the settings as stated above. The procedure for the download is exactly the same as in #1. The LibraryWatcher didn't detect the new file at all. I waited two or three minutes after the download succeded, but I had to rescan the library so that banshee found the new song. As it found the song, it was imported correct and without corruption.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.