After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 577583 - Enable "Write metadata to files" by default
Enable "Write metadata to files" by default
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: Metadata
1.4.3
Other All
: Normal enhancement
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
: 638275 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-04-01 07:14 UTC by Neal Aberdeen
Modified: 2020-03-17 08:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Neal Aberdeen 2009-04-01 07:14:19 UTC
Please describe the problem:
When changing the ID3 tag information within Banshee on an audio file in the music library, the tags appear to be updated; they appear correct in the music library and on e.g. an iPod. However they seem to not be saved in the audio file; if the track is removed from the music library and then re-added the tags have reverted back to their original, pre-edited state. The user then has to edit the tags again.

Steps to reproduce:
1. Take audio file with erroneous tags
2. add the audio file to the music library
3. edit the tags from within Banshee
4. note the track appears correct in the music library
5. (optional?) sync with a portable device
6. (optional?) note the track appears correct on the portable device
7. (optional?) remove track from portable device
8. remove track from music library
9. restart Banshee
10. add the track to the music library
11. note the track appears in it's pre-edited form


Actual results:
The tags have reverted to their pre-edited state

Expected results:
The edits to the tags should be preserved so that the next time the track is added it does not need to be re-edited

Does this happen every time?
Yes

Other information:
I can provide an example audio file if required
Comment 1 Andrew Conkling 2009-04-01 12:10:47 UTC
In Edit | Preferences, is "Write metadata to file" checked? (The verbiage may be slightly different; I'm going from memory.)
Comment 2 Neal Aberdeen 2009-04-01 12:17:23 UTC
Doh, no it isn't. Guess it's user error then... Would it be possible to make this option ticked as default, I'm not the only user who's made this mistake?
Comment 3 Andrew Conkling 2009-04-01 13:27:02 UTC
(In reply to comment #2)
> Doh, no it isn't. Guess it's user error then...

Don't worry, it's a frequent question.

> Would it be possible to make
> this option ticked as default, I'm not the only user who's made this mistake?

Not sure about that. The difficulty may be that not everyone would expect this behavior. I'm inclined to say that most people would, but at the same time, having it default to off is "safer" for the sake of your media's metadata.

That said, this bug can become a request for that, and the developers can decide one way or the other.
Comment 4 Jean-Francois Lepage 2009-04-01 14:21:03 UTC
Write metadata to file *IS* checked and this bug occurs! 
It's not even if I remove and re-add the file, it's as soon as banshee is closed and then re-oppened!

Cheers!
Comment 5 Andrew Conkling 2009-04-01 17:39:55 UTC
Perhaps I should have cloned this for the enhancement request in the first place, but I've created bug 577626 to cover your case, Jean-Francois.
Comment 6 Sandy Armstrong 2009-04-01 19:24:21 UTC
(In reply to comment #4)
> Write metadata to file *IS* checked and this bug occurs! 
> It's not even if I remove and re-add the file, it's as soon as banshee is
> closed and then re-oppened!

So the metadata change is still there after you close the Track Editor?  If not, are you remember to click Save?
Comment 7 Bertrand Lorentz 2009-04-01 19:43:46 UTC
I think the reason we have "Write metadata to files" disabled by default is
that we don't want to modify people's files without them knowing about it.

Better be safe than sorry ! ;)

Jean-Francois, Sandy : the discussion about metadata not being written with the option enabled should happen on bug #577626.
Comment 8 Neal Aberdeen 2009-04-16 08:56:10 UTC
Been away so not had chance to post on this.

In my case, the issue is because the music files are on an external hard drive. It is formatted to FAT32 and the owner is root so Banshee cannot make the changes.
Comment 9 jossele 2009-06-11 10:53:06 UTC
I think the user expects the metadata in the file to be changed if he changes it in banshee. That is the way it is handled by most of the other players.
Comment 10 Bertrand Lorentz 2010-12-30 10:01:37 UTC
*** Bug 638275 has been marked as a duplicate of this bug. ***
Comment 11 David Nielsen 2010-12-30 10:19:40 UTC
(In reply to comment #9)
> I think the user expects the metadata in the file to be changed if he changes
> it in banshee. That is the way it is handled by most of the other players.

I hear from users that they expect by default that Banshee does not change their files in any way. E.g. no writing of metadata, no file/folder organization by default.

However perhaps on first launch we should ask the user if he wants to manage the collection or let Banshee do it (if so, enable all our sexy metadata and organizational library features). I believe a certain fruit company does the same with their Banshee competitor.
Comment 12 Max 2010-12-30 11:52:30 UTC
(In reply to comment #11)
> I hear from users that they expect by default that Banshee does not change
> their files in any way. E.g. no writing of metadata, no file/folder
> organization by default.
> 

I disagree. The default behaviour of pretty much all media players is to keep the library in sync with the files that it contains. It's very annoying that I've edited the genre of certain tracks, for example, and now discovered that if I ever have to reimport those files, these changes will be lost. It just doesn't make sense.
Comment 13 Max 2010-12-30 12:00:50 UTC
Also, managing the collection is completely a separate issue from keeping ID3 tags in sync.

Managing the collection consists of the actual renaming of files and folders. This should be optional, and is optional in iTunes, as mentioned.

However, if we edit the ID3 tags of a file, we'd expect that file to have its ID3 tags updated. This is the default (and only) behaviour of pretty much all other media players (Foobar, Amarok, Rhythmbox etc.)
Comment 14 Andrés G. Aragoneses (IRC: knocte) 2010-12-30 12:26:20 UTC
(In reply to comment #12)
> ... It's very annoying that
> I've edited the genre of certain tracks, for example, and now discovered that
> if I ever have to reimport those files, these changes will be lost.

That is a different bug on its own I think. I mean, if a user has been updating his files without noticing about this setting being turned off, he should be able to dump his changes to the files retroactively. Can you file a different bug for that?
Comment 15 Max 2010-12-30 12:31:23 UTC
(In reply to comment #14)
> (In reply to comment #12)
> > ... It's very annoying that
> > I've edited the genre of certain tracks, for example, and now discovered that
> > if I ever have to reimport those files, these changes will be lost.
> 
> That is a different bug on its own I think. I mean, if a user has been updating
> his files without noticing about this setting being turned off, he should be
> able to dump his changes to the files retroactively. Can you file a different
> bug for that?

That would be a very useful feature, but I think the main issue is that the user doesn't notice that this setting is turned off in the first place. And I still don't understand why it's even an option. Surely if we update a song's ID3 tags, it should update them?
Comment 16 André Klapper 2020-03-17 08:16:38 UTC
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.