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 backend. I'm using, these versions: $ rpm -q gstreamer-plugins gstreamer-plugins-extra-audio gstreamer-plugins-0.8.8-9 gstreamer-plugins-extra-audio-0.8.11-0.lvn.2.4 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 RHYTHMDB_EVENT_FILE_CREATED_OR_MODIFIED [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 gstreamer-plugins-0.8.11-0.gst.1.4 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.