Bug 4002 - Plays only part of an mp3 if mp3 is still being downloaded (podcast)
: Plays only part of an mp3 if mp3 is still being downloaded (podcast)
Status: RESOLVED WONTFIX
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: unspecified
: PC Fedora
: P2 trivial (vote)
: Future
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-25 09:00 UTC by udo
Modified: 2009-05-05 22:56 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description udo 2006-08-25 09:00:47 UTC
slimserver-2006_08_12-1.

While downloading the latest DSC I started playing the podcast and later found out the audio cuts out before the end of the show although the complete mp3 is on the harddisk.
Comment 1 Chris Owens 2006-08-25 09:32:48 UTC
Hi Udo, I would like to clarify the symptom you experienced please.  

1) You started downloading a podcast (an mp3 file).
2) Before the download was complete, you began playing the podcast.
3) During the playback, the download finished, so the whole file is not available on the hard drive.
4) The playback stopped part-way through, as though the file was not yet downloaded.

Is that correct?  Or is it something else?
Comment 2 Andy Grundman 2006-08-25 09:37:15 UTC
SlimServer sends as much data as it can to the player to fill it's buffer.  It most likely buffered the whole file (what it thought was the whole file) before it was fully downloaded.  I would not consider this a bug.
Comment 3 udo 2006-08-25 09:39:23 UTC
1) You started downloading a podcast (an mp3 file).
2) Before the download was complete, you began playing the podcast.

Both Correct.

3) During the playback, the download finished, so the whole file is not
available on the hard drive.

During playback the download finished. So the whole file was available on the HD before ending playback of the part that was available when the playback was originally started.

4) The playback stopped part-way through, as though the file was not yet
downloaded.

Correct.
Comment 4 udo 2006-08-25 09:40:12 UTC
In other words:

Don't look at the length of a file too much. Just start playing it and play it until EOF.
(simply put...)
Comment 5 udo 2006-08-25 09:46:19 UTC
Maybe not a bug then.

Additional info:
The MP3 was 30+ megs. 


Maybe a check could be added when the squeezebox's buffer is almost empty to see if the file really is EOF? (so it sees data was added to the file due to the download)
Comment 6 Andy Grundman 2006-08-25 09:48:10 UTC
You might also want to just use the Podcast plugin, and stream your podcast mp3 files directly from the source.
Comment 7 Chris Owens 2006-08-25 10:07:22 UTC
I adjusted the severity and target of the bug so that it won't hold up the next release, I added the string "podcast" to the summary so when we rework our podcast support and need to review pertinent bugs, this bug will be included.
Comment 8 Alan Young 2009-05-05 22:56:37 UTC
There are several reasons why SC takes trouble to check the length of a file, and the length of the audio therein at the start of streaming. This is used to determine when streaming will stop, and how seeking would work. It is not appropriate to reevaluate this while streaming.