Version: 2.4-GIT (using KDE 4.6.0) OS: Linux Occasionally, when adding ogg vorbis tracks to my collection, Amarok misreads the length as vastly shorter than it actually is. This is displayed both in the playlist and in the seek bar. I'm using the VLC backend, with VLC, Phonon and phonon-vlc built from git. Standalone VLC correctly reports the file length. I have also checked the files directly using tagpy, and the length information is correct. A full collection rescan restores the correct length to some files, but seems to get the length wrong for others. (I've left this in 'general' since I'm not sure where the problem is actually introduced.) Reproducible: Sometimes Steps to Reproduce: Add ogg vorbis files to collection. Add songs to playlist. Play songs. Actual Results: Song length is displayed incorrectly as shorter than reality for some songs in playlist and seekbar. Expected Results: Correct song length displayed. Kubuntu 10.10 with KDE4.6 from backports PPA. Music ripped from audio CD with k3b.
Maybe collection related?
I think this may be happening if Amarok runs an automated rescan while the track in question is in the process of being copied. Amarok sees the song, reads the length at that point, and doesn't update later when the complete track has been copied over. I'm not entirely sure what could be done about this, mind you.
(In reply to comment #2) > I think this may be happening if Amarok runs an automated rescan while the > track in question is in the process of being copied. Amarok sees the song, > reads the length at that point, and doesn't update later when the complete > track has been copied over. > I'm not entirely sure what could be done about this, mind you. You could be right about that as I've noticed that Amarok has read the length wrongly on some newly ripped tracks recently. How do I go about correcting it though? Perhaps removing, re-scanning, replacing and re-scanning would work.
(In reply to comment #3) > You could be right about that as I've noticed that Amarok has read the length > wrongly on some newly ripped tracks recently. > How do I go about correcting it though? Perhaps removing, re-scanning, > replacing and re-scanning would work. Settings > configure Amarok > collection > full rescan should be sufficient to restore correct lengths.
(In reply to comment #4) > (In reply to comment #3) > > You could be right about that as I've noticed that Amarok has read the length > > wrongly on some newly ripped tracks recently. > > How do I go about correcting it though? Perhaps removing, re-scanning, > > replacing and re-scanning would work. > > Settings > configure Amarok > collection > full rescan should be sufficient to > restore correct lengths. Thanks! That fixed this issue for me as well.
So can this be closed? I don't think there is much we can do for it code wise...
I think it should be fixable; the scanner should already look for file modification to read external tags, etc, so altering the behaviour there to check the file length as well should fix the issue. This said, I'm not absolutely sure it hasn't already been fixed; I haven't observed it in the last few albums I've added. Will try and reproduce.
(In reply to comment #7) > I think it should be fixable; the scanner should already look for file > modification to read external tags, etc, so altering the behaviour there to > check the file length as well should fix the issue. > This said, I'm not absolutely sure it hasn't already been fixed; I haven't > observed it in the last few albums I've added. Will try and reproduce. I have reproduced it in my latest rip. I also think it is fixable as more music players (for example Rhythmbox) have libraries that are automatically updated and they don't have this issue with wrong track length. I'm happy with the 'fix' it would just be very nice if it was solved.
As with the "fix" as per Comment #4, it works, but with newly ripped tracks, the problem still exists in Amarok 2.5.
Setting to confirmed, changing target.
not reproducible with amarok 2.6
(In reply to comment #9) > As with the "fix" as per Comment #4, it works, but with newly ripped tracks, > the problem still exists in Amarok 2.5. Do you rip the track right into a folder which is watched by Amarok? This might be the problem indeed, however I don't know how/whether we should fix this in Amarok. Also please retest with Amarok 2.7 or newer.
Any news about this? Even if you didn't buy a CD recently, could you just test with one you already have ripped by ripping it again?The version still says 2.5.0, ad we are about to release 2.8 in a few weeks...
Sam, I am closing this for now. Please reopen once you find time to reproduce this with latest git.