Bug 267336

Summary: Amarok sometimes misreads song length for .ogg files
Product: [Applications] amarok Reporter: Sam Lade <sam>
Component: Collections/LocalAssignee: Amarok Bugs <amarok-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: minor CC: aakashrajdahal, esteinma, kaabud-kde, matej, mfraz74+kde, mitchell, mscho527, ralf-engels
Priority: NOR    
Version First Reported In: 2.5.0   
Target Milestone: 2.6   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Sam Lade 2011-02-28 21:05:04 UTC 
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.
Comment 1 Myriam Schweingruber 2011-03-05 15:37:46 UTC 
Maybe collection related?
Comment 2 Sam Lade 2011-03-26 16:29:46 UTC 
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.
Comment 3 Mark Fraser 2011-03-26 16:40:36 UTC 
(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.
Comment 4 Sam Lade 2011-03-26 16:45:17 UTC 
(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.
Comment 5 Erik 2011-06-21 10:58:03 UTC 
(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.
Comment 6 Myriam Schweingruber 2011-06-21 14:18:34 UTC 
So can this be closed? I don't think there is much we can do for it code wise...
Comment 7 Sam Lade 2011-06-21 15:18:00 UTC 
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.
Comment 8 Erik 2011-06-21 22:31:15 UTC 
(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.
Comment 9 Aakash 2011-12-31 03:32:52 UTC 
As with the "fix" as per Comment #4, it works, but with newly ripped tracks, the problem still exists in Amarok 2.5.
Comment 10 Myriam Schweingruber 2011-12-31 10:59:09 UTC 
Setting to confirmed, changing target.
Comment 11 MinSik CHO 2012-12-02 11:58:39 UTC 
not reproducible with amarok 2.6
Comment 12 Matěj Laitl 2013-03-03 13:36:15 UTC 
(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.
Comment 13 Myriam Schweingruber 2013-07-12 15:07:14 UTC 
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...
Comment 14 Myriam Schweingruber 2013-08-19 10:42:14 UTC 
Sam, I am closing this for now. Please reopen once you find time to reproduce this with latest git.