Bugzilla – Bug 16653
Audio from particular MP3s is hanging
Last modified: 2011-01-28 02:54:11 UTC
The MP3 podcasts from the following source do not play correctly: http://rss.dw-world.de/xml/podcast_fokus-europa These MP3s play for 13 seconds or so, then the audio playback stops. This is not just a Podcast Player bug, as I will demonstrate. On the SB Touch: The audio halts after 13 seconds. The 'seeking bar' keeps moving, but there is no audio. If I manually seek to another point in the track (past the 13 second point), then the playback works correctly. If I manually seek to before the 13 second point, then the error re-occurs. Using SqeezePlay: The audio halts after 13 seconds. After 18 seconds, the status changes from 'Now Playing' to 'Stopped'. Seeking to another point in the track works correctly as on the SB Touch as long as the I do the seek within the first 18 seconds. Downloading the MP3 to Squeezbox Server: When I download the MP3 to the Squeezebox Server, and attempt to play it with either the SB Touch or Squeezeplay, only the first 13 seconds are played. In fact the track length is only recognised as 13 seconds, whereeas via the Podcast Player, the entire track length was recognised. When I play the MP3 using VLC or Winamp, the entire track plays correctly. I believe that all the MP3s on this podcast feed are prefixed with a common 'introduction' MP3, i.e. the provider concatenates two MP3s. I believe that this is somehow causing the problems described. However, it should work - other MP3 players play these files correctly.
try running mp3val on them. it may indicate a problem with the mp3, which would then inform what SBS needs to handle better.
(In reply to comment #1) > try running mp3val on them. it may indicate a problem with the mp3, which > would then inform what SBS needs to handle better. Okay, I've done that, and you're right there is a problem with the mp3. The number of frames indicated in the header is not correct; this is probably to do do with their MP3 joining process. Here is the output: Analyzing file "BEF0E648_1-podcast-1692-6154424.mp3"... WARNING: "BEF0E648_1-podcast-1692-6154424.mp3" (offset 0x5bf6): MPEG stream error, resynchronized successfully WARNING: "BEF0E648_1-podcast-1692-6154424.mp3": Wrong number of MPEG frames specified in Xing header (508 instead of 35278) WARNING: "BEF0E648_1-podcast-1692-6154424.mp3": Wrong number of MPEG data bytes specified in Xing header (106369 instead of 7338633) INFO: "BEF0E648_1-podcast-1692-6154424.mp3": 35278 MPEG frames (MPEG 1 Layer III), +ID3v2, CBR Done! Are you able to workaround this?
*** This bug has been marked as a duplicate of bug 16233 ***