From brad@kazrak.com  Tue Jul 25 23:27:09 2000
Return-Path: <brad@kazrak.com>
Received: from pegasus.kazrak.com (adsl-209-233-16-235.dsl.snfc21.pacbell.net [209.233.16.235])
	by hub.freebsd.org (Postfix) with ESMTP id BB1CA37B5D3
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 25 Jul 2000 23:27:08 -0700 (PDT)
	(envelope-from brad@kazrak.com)
Received: by pegasus.kazrak.com (Postfix, from userid 1001)
	id BAF523E7; Tue, 25 Jul 2000 23:27:02 -0700 (PDT)
Message-Id: <20000726062702.BAF523E7@pegasus.kazrak.com>
Date: Tue, 25 Jul 2000 23:27:02 -0700 (PDT)
From: brad@kazrak.com
Reply-To: brad@kazrak.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: ripit port may create out-of-order playlists when run under SMP
X-Send-Pr-Version: 3.2

>Number:         20190
>Category:       ports
>Synopsis:       ripit port may create out-of-order playlists when run under SMP
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    reg
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 25 23:30:01 PDT 2000
>Closed-Date:    Sun Oct 1 03:22:37 PDT 2000
>Last-Modified:  Sun Oct 01 03:23:25 PDT 2000
>Originator:     R Bradford Jones
>Release:        FreeBSD 4.1-RC i386
>Organization:
Kazrak Enterprises
>Environment:

4.1-RC, SMP machine using ATAPI cdrom (via cdda2wav) and gogo.

>Description:

The ripit port may create a playlist (m3u file) that is out-of-order when run
on an SMP machine with numcpu set to 2 or higher.  The playlist is created
by "ls -rt *.mp3 > file"; it is possible that a short (but later) track
completed after a longer, earlier track, causing the short track to appear
earlier in the playlist than the longer track.

>How-To-Repeat:

Run ripit.pl using multiple CPUs on a disc with widely disparate track
lengths.  (Pink Floyd: Dark Side of the Moon demonstrated the problem twice
for me, once with tracks 3/4 and once with 8/9.)

>Fix:

Possibly store the track names into the m3u file directly (as the file begins
being encoded) instead of creating it from the filesystem after the fact.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports->reg 
Responsible-Changed-By: reg 
Responsible-Changed-When: Sun Jul 30 23:45:51 PDT 2000 
Responsible-Changed-Why:  
I wrote the numcpu hack, so I guess I have to fix it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20190 
State-Changed-From-To: open->closed 
State-Changed-By: reg 
State-Changed-When: Sun Oct 1 03:22:37 PDT 2000 
State-Changed-Why:  
Explictly sort the playlist. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=20190 
>Unformatted:
