249437 - M3U playlist containing relative paths to MP3 files cannot be found by media player

Status: RESOLVED DUPLICATE of bug 225882

(Firefox :: File Handling, defect)

Description

[Tony Garland]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When clicking on the example URL which is an M3U file containing a play list of
MP3 files whose location is relative to the M3U file, neither the QuickTime
plugin nor Windows Media Player play the list properly.  This only occurs when
the playlist is played back over http:// -- it works fine on a local HD (played
back over file://).

This same problem occurred in earlier versions of IE and WMP, but was fixed
somewhere along the way so playback of M3U files with relative paths works OK
now for IE (6) and WMP (9).

WMP complains that it cannot find the specified file. (It finds the M3U file OK
because it lists the individual track titles as given by the M3U file names, but
it can't seem to locate the actual MP3 files themselves which are listed within
the M3U file.)

Reproducible: Always
Steps to Reproduce:
1. Go to
http://www.spiritandtruth.org/teaching/Romans_9-11/01_Romans_9_1-5/webshow/index.m3u
2. Watch either QuickTime or Windows Media Player launch.
3. QuickTime plays through each file with "silence" for a few seconds. WMP gives
an error indicating "cannot find the specified file."

Actual Results:  
QT and WMP are unable to play the M3U file containing relative MP3 file paths.

Expected Results:  
Play the sequence of MP3 files as a single recording stream.

Comment 1

[Ali Ebrahim]

Makes sense. This isn't a bug, though, because the M3U file when given a
relative path looks in the same folder, i.e. on the local harddrive. If it needs
to load content from elsewhere (such as a URL), it needs to be given an absolute
path.

Comment 2

[Tony Garland]

As a software developer by profession, may I comment on your decision to mark
this "defect" as "resolved" and "invalid?"

This reminds me of the "engineering purist" approach to product development of
which I've been a party to many times myself.  It doesn't matter whether
something WORKS or not, all that matters is whether it meets an abstract
definition in someone's head (or even on paper).  The plain fact of the matter
is that M3U files behave differently on local HD vs. on a website.  We can talk
all day long about whether they should or not and whether Firefox is meeting the
letter of the law or not, but the real ramification will be seen in the fact
that users (such as myself) will back away from using a promising IE replacement
because of the simple fact that M3U played from a website (using relative paths)
DOES work with IE, but doesn't with Firefox.

Put yourself in the shoes of folks (like me) who develop websites targeted both
for the internet and for recording to CDROM.  Wouldn't you like your M3U files
to be location-independent (and support relative paths like all other HTML,
etc.)?  I submit that deciding to define this as expected operation is putting
one's head in the sand and leaving yet another advantage for IE to make Firefox
look substandard.

People will vote with their feet -- M3U works better with IE so why mess with
Firefox if there isn't even any interest in addressing the issue?

Comment 3

[Tony Garland]

One additional comment.  You state:

"This isn't a bug, though, because the M3U file when given a
relative path looks in the same folder, i.e. on the local harddrive."

The problem is, the M3U file is originally _not_ on the hard drive--it is
located on the server.  If it strictly used a relative path--it would be
relative to its original location--not some abstract location where it happens
to be downloaded by the browser.  (In other words, if the browser moves the file
to a different location--a local cache on the hard drive--then it should also
take care of translating relative paths to point back to the absolute location
on the server relative to the original M3U file location.)  This seems simple
enough.

Comment 4

[Ali Ebrahim]

You're right, I was somewhat hasty here. Now that you've explained it further,
this is actually a real bug. It's one that we already have in the system though,
bug 225882.

Comment 5

[Ali Ebrahim]

*** This bug has been marked as a duplicate of 225882 ***