Closed Bug 235641 Opened 21 years ago Closed 19 years ago

Download to cache is cut short for audio mp3 files

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: fmouse-gentoo, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040217 Mozilla is running plugger 4.0 plug-in to handle mp3 files, which may or may not be relevant. I don't know if mozilla or plugger undertakes transfer to mozilla cache. If plugger does this, and knows where the mozilla cache is, then this is a plugger.so problem and I'm reporting this in the wrong place. Reproducible: Always Steps to Reproduce: 1.Go to a web link to an mp3 file, such as the one cited in this report 2. 3. Actual Results: Cached file starts playing almost immediately, however transfer to cache is apparently aborted and the play terminates after about 20 seconds when the cached audio is exhausted. Looking at the cache, this is always after about 343000 bytes have been transferred, plus or minus a few K. This happens in galeon, also, as one might expect. Expected Results: When transferring an explicitly linked mp3 file, the entire file should be transferred before any attempt is made to play it, as opposed to an mp3 file linked via an m3u file. Because I'm on a good cable modem connection, I can't really tell if the sound file is being handed off to the plugin before or after the download to cache aborts.
This sounds a lot like bug 89270. Mozilla really can't stream.
Nor should it if the explicit target of a link is an mp3 file. It should download the file, which is expected to be of reasonable finite length, and _then_ launch the plug-in to play it. The problem may be that it's trying to stream, and cutting the transfer to cache short. Don't know if this is happening in mozilla or plugger. As an experiment, I accessed a tiff image file of considerable size, since tiff images are also handled by plugger. The entire file downloaded before it was displayed. Pseudo-streaming in all browsers that I know of is accomplished by indirect reference to an mp3, providing the URL of the mp3 file in a file with an extension of .m3u. The m3u file is what's explicitly linked. In this case, the entire job is generally passed off to a 3rd party player which handles the streaming.
>Nor should it if the explicit target of a link is an mp3 file. It should >download the file, which is expected to be of reasonable finite length, and >_then_ launch the plug-in to play it. this is not how plugins work, nor how they should work. (in general). you do want to start your flash files to play, and show some stupid animation, while the rest of the file gets loaded... Now, if you want that to be done for mp3 files handled by plugger, complain to the plugger authors.
(In reply to comment #3) > >Nor should it if the explicit target of a link is an mp3 file. It should > >download the file, which is expected to be of reasonable finite length, and > >_then_ launch the plug-in to play it. > > this is not how plugins work, nor how they should work. (in general). you do > want to start your flash files to play, and show some stupid animation, while > the rest of the file gets loaded... > > Now, if you want that to be done for mp3 files handled by plugger, complain to > the plugger authors. I'm referring to the the general design of the entire browser system and browser SOP, and what constitutes expected behavior as I understand it. If I'm mistaken here then I'm willing to stand corrected, but my understanding is that an explicit link to an mp3 file is _not_ expected to stream, but to download and then play, wheras an indirect link via an m3u file _is_ expected to stream (actually pseudo-stream). A full-spectrum audio mp3 file can _not_ stream over anything but a high speed connection since, on a 56K modem connection for instance, the effective rate of play exceeds the rate of transfer by a substantial margin. I would not expect any browser to try to do this. The mozilla/plugger combination _used_ to work properly in this regard. I'm perfectly willing to lay this bug on the plugger folks if that's where it belongs, however from the comments above, I'm not persuaded that I've really communicated the problem to the people who've posted on it. In the first place, this is a bug report, not a complaint. I'm reporting an improperly truncated file and a prematurely aborting process resulting from this truncation. Technical responsibility for this lies either with mozilla or with plugger. If it lies with mozilla, then run with it. If it lies with plugger, then please provide a decent techncial explanation of why it belongs elsewhere, and we can mark this bug INVALID and move on.
> I'm reporting an improperly truncated file I had the impression that you had reported that mp3 files are streaming rather than downloading and then playing. as the downloading/playing is all driven by plugin code, this would be a plugger problem/bug/feature. For the > prematurely aborting process Please see bug 89270 comment 10
(In reply to comment #5) > I had the impression that you had reported that mp3 files are streaming rather > than downloading and then playing. (My impression is consistent with "expected results" from comment 0)
(In reply to comment #5) > > I'm reporting an improperly truncated file > > I had the impression that you had reported that mp3 files are streaming rather > than downloading and then playing. as the downloading/playing is all driven by > plugin code, this would be a plugger problem/bug/feature. Because I have a good high speed connection it's hard to tell if the problem is an improper attempt to stream, followed by a failure, or if the download is being truncated for some other reason and the too-short file is playing almost immediately thereafter. It's the fact that the process is being truncated that's the bug, and the streaming issue was speculation on my part. I'll report this as a bug on plugger and see where it goes. Thanks.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.