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 323425 - [Patch] Add support for changing year of multiple songs
[Patch] Add support for changing year of multiple songs
Product: rhythmbox
Classification: Other
Component: general
Other All
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Reported: 2005-12-07 03:40 UTC by Alex Lancaster
Modified: 2005-12-09 19:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Support changing the year in multiple songs (5.52 KB, patch)
2005-12-07 03:41 UTC, Alex Lancaster
none Details | Review
Updated patch using "-u" (9.06 KB, patch)
2005-12-07 03:54 UTC, Alex Lancaster
committed Details | Review

Description Alex Lancaster 2005-12-07 03:40:46 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.
Comment 1 Alex Lancaster 2005-12-07 03:41:52 UTC
Created attachment 55726 [details] [review]
Support changing the year in multiple songs
Comment 2 James "Doc" Livingston 2005-12-07 03:46:41 UTC
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.
Comment 3 Alex Lancaster 2005-12-07 03:54:45 UTC
Created attachment 55727 [details] [review]
Updated patch using "-u"
Comment 4 James "Doc" Livingston 2005-12-07 06:39:48 UTC
The patch looks good, and works for me, so I've committed it to cvs. Thanks.
Comment 5 Alex Lancaster 2005-12-08 16:41:04 UTC
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.
Comment 6 James "Doc" Livingston 2005-12-09 10:05:38 UTC
Alex: that sounds very strange, it works for me. Is there anything odd about the
files you are changing the tags of?
Comment 7 Alex Lancaster 2005-12-09 15:11:26 UTC
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?
Comment 8 James "Doc" Livingston 2005-12-09 15:27:17 UTC
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?
Comment 9 Alex Lancaster 2005-12-09 16:36:47 UTC
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
Comment 10 Alex Lancaster 2005-12-09 16:38:51 UTC
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.
Comment 11 Alex Lancaster 2005-12-09 17:15:15 UTC
Just upgraded to gstreamer-plugins 0.8.11 with FC4 packages from

# rpm -q gstreamer-plugins

Problem still persists.
Comment 12 Alex Lancaster 2005-12-09 19:09:00 UTC
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.