Changing the year for a song also changes the track length to zero

Bug #701747 reported by Mackenan Grassi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Guayadeque
Fix Committed
Medium
anonbeat

Bug Description

I'm using latest version of Guayadeque from the repository (revision 1426). Any time I change the year for a track, the track length changes to 0:00 upon hitting OK to accept changes.

Revision history for this message
anonbeat (anonbeat) wrote :

Can you give me steps to reproduce it here?

Thanks

Revision history for this message
Mackenan Grassi (mackenan) wrote :

Right click on any song (I've done this in Library view, Playlist view, and on the Player Playlist) and select Edit Songs. When the dialog comes up, change the year to any number other than what it already is (I tested this once by simply changing the year by one, e.g. from 1974 to 1973) and hit OK. The year will be successfully changed, but the Length field now reports 00:00. If this was done somewhere like the Library view, and the track is also queued up in the Player Playlist you can also see the 00:00 length listed there. This doesn't effect the track length listed near the Player controls if the song edited is the currently playing track.

Revision history for this message
anonbeat (anonbeat) wrote :

I cant reproduce it here using Ubuntu 10.10
What are you using ? can you tell me the version of the taglib ? dpkg --list | grep libtag

Thanks

Changed in guayadeque.player:
assignee: nobody → anonbeat (anonbeat)
Revision history for this message
Mackenan Grassi (mackenan) wrote :

I'm running Gentoo. I've got taglib-1.6.3 installed.

Revision history for this message
anonbeat (anonbeat) wrote :

Save version here! I cant reproduce what you says. For me the track length is kept. Are you sure you are running the 1426 revision ? Does the title of guayadeque window shows 0.2.8-1426 ?

Thanks

Revision history for this message
anonbeat (anonbeat) wrote :

Oops! Save -> Same

Revision history for this message
Mackenan Grassi (mackenan) wrote :

Yep, I'm sure I'm running the latest version. The first thing I did when I noticed the problem was to update to the latest revision and check if the problem still existed. I just booted into my Ubuntu install and have the same problem with the same revision of Guayadeque. My Ubuntu install is the 64-bit version of 10.10, and my Gentoo install is also a 64-bit build. I'm betting you're using the 32-bit build.

I think I tracked down the problem. In guTrackEditor::WriteItemData, you're passing a pointer to the track year which is of type long, while the variable is type int. This wouldn't be a problem in 32-bit environments where int and long are both 32-bits long, but it is a problem in 64-bit environments where int is 32-bits while long is 64-bits. This has the effect of allowing that call to write on a 64-bit long stretch of memory (which happens to include the length variable). You either need to change the type definitions for those variables (in the guTrack class) to long, or you need to change how the value gets assigned in the WriteItemData function.

After looking at the code, I noticed that you use the same method for updating the track number. That should be changed as well. While it doesn't appear to have the same problem if I simply change the track number, if I put in an insanely large number for the track number it will also overwrite the track year. I've attached a file that's a quick little hack to fix the problem. It allows C to do the long to int type-conversion for you. If I build Guayadeque with that little hack in place, everything works fine.

Revision history for this message
anonbeat (anonbeat) wrote :

Ohh Yes. This morning I was testing in 32bits and thatis what happened. I couldnt see couse it never happened in 32 bits. Now at home in x64 the problem shows.
Your patch have been implemented changed a litle.

Thank you very much

Changed in guayadeque.player:
importance: Undecided → Medium
status: New → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.