GNOME Bugzilla – Bug 323425
[Patch] Add support for changing year of multiple songs
Last modified: 2005-12-09 19:09:00 UTC
It should be possible to change the year in the ID3 tag of multiple songs.
Attached is a patch (may need some work as I am new to rhythmbox code) that adds
support for changing the year for multiple songs in the multiple song dialog.
Created attachment 55726 [details] [review]
Support changing the year in multiple songs
Can you make the patch by passing -u to diff/cvs diff. Unified diffs are much
easier to read, and don't break so often when cvs changes.
Created attachment 55727 [details] [review]
Updated patch using "-u"
The patch looks good, and works for me, so I've committed it to cvs. Thanks.
Latest HEAD appears to have sync problems with ID3 tags after changing year. I
change the year from 1065 to 1060 and it changes, then reverts back to 1065.
But the change appears to stick in the ID3 file itself, when checking with an
external tool like id3info or tagtool, but somehow gets out of sync with the
rhythmdb.xml. This persists even after "Delete"ing the file from the Library
and readding it, and then shutting down and restarting.
Alex: that sounds very strange, it works for me. Is there anything odd about the
files you are changing the tags of?
Maybe, I've been using several files as test files, and changing the tags in
multiple tagging problems: easytag, tagtool, kid3 and rhythmbox to test all
combinations, and perhaps some remnants of old tags aren't being deleted. I've
tried deleting *all* ID3 tags (both v1 and v2).
Now I also sometimes get into the situation that the ID3 tag isn't being written
to the file, but it is changed in rhythmbox.xml. Very strange. Can you suggest
some canonical files to test?
CVS versions from the last week or so will report (in a dialog) any errors that
gstreamer gives us while writing, so if it's not reporting a problem then either
gstreamer has told us it worked, or there is a bug in the error reporting.
I've occasionally gotten double-tagged files where it contains both the old and
the new tags, and some things report the old ones and some the new ones. We
don't have any test files (although the gstreamer people have heaps); what I do
suggest is trying with a file that you haven't done lots of tag fiddling with
(especially by RB), such as a freshly ripped track, and see if the problem
happens with that.
Also what version of gst-plugins are you using?
Tried the freshly-ripped tracks, still problem.
Right now, it appears that the ID3 tags are being written to the file, and they
change in the interface, and then a sync action is performed and they revert to
the old versions, so it seems a problem in the sync code, not in the gstreamer
I'm using, these versions:
$ rpm -q gstreamer-plugins gstreamer-plugins-extra-audio
The base gstreamer-plugins is from FC4, and the MP3 plugins is the canonical one
for Fedora from Livna.org.
I'm also seeing a lot of messages in the debug log about directories being
interpreted as files:
[0x85de778] [rb_shell_player_sync_buttons] rb-shell-player.c:1674 (03:12:37):
syncing with source 0x87833f0
[0x85de778] [rhythmdb_check_changed_file] rhythmdb.c:3851 (03:12:37): adding
newly located file file:///home/alex/mp3/singletons/untagged
[0x85de778] [rhythmdb_process_events] rhythmdb.c:1668 (03:12:37): processing
[0x8736298] [action_thread_main] rhythmdb.c:1963 (03:12:37): executing
RHYTHMDB_ACTION_LOAD for "file:///home/alex/mp3/singletons/untagged"
[0x8736298] [rb_metadata_load] rb-metadata-gst.c:702 (03:12:37): loading
metadata for uri: file:///home/alex/mp3/singletons/untagged
[0x8736298] [rb_metadata_gst_error_cb] rb-metadata-gst.c:420 (03:12:37): caught
error: "/home/alex/mp3/singletons/untagged" is a directory.
This often appears after I make a change to a tag using the Properties dialog.
Just upgraded to gstreamer-plugins 0.8.11 with FC4 packages from gstreamer.net:
# rpm -q gstreamer-plugins
Problem still persists.
OK, I think I've actually narrowed down what the problem actually is, but I've
no idea how to fix it. The tags aren't being correctly overwritten by
rhythmbox. Since it is unrelated, I've opened up a new bug: bug #323658.