Bugzilla – Bug 13967
On Boom: Short podcasts (and perhaps other media types?) repeat bits.
Last modified: 2009-10-05 14:27:10 UTC
The last 30 seconds or so of a podcasts are replayed before moving tracks and going to the next. I see this on Boom, but I assume this is true of all ip3k players. I don't know about linux based players. To reproduce: * Add this feed to your podcasts: http://www.theonion.com/content/feeds/radionews * Add the first 3 or 4 items from that feed to your playlist. * Listen * Laugh * Then... you should hear the last 30 seconds or so of the podcast repeated before it goes to the next one. It's not as funny the second time. My Boom was on the Dallas (Test) Squeezecenter.
This is a weird one, I can reproduce it using SbS 7.4. Alan, can you take a look? Will attach a log.
Created attachment 5833 [details] player.streaming.direct,player.source=INFO log OK there are 2 bugs here I think. There may be a bug in Audio::Scan as this file is detected as 34kbps when it should be 64kbps, this leads to the wrong duration being used. Then, I see this in the log, I'm not sure what the code does in this case, but this is probably why it does the strange repeat/seek thing. Slim::Player::StreamingController::_AutoStart (1404) autostart possibly short track ... Slim::Player::StreamingController::_RetryOrNext (866) Attempting to re-stream http://www.theonion.com/content/files/radionews/09-171_Bail_Money_Th.mp3, duration=85.3978823529412 at time offset 63.2687129518474
== Auto-comment from SVN commit #420 to the opensource repo by andy == == https://svn.slimdevices.com/opensource?view=revision&revision=420 == Bug 13967, fixed Xing bitrate calculation for MPEG 2.0 files
I fixed the bitrate calc (not checked in yet) but there is still another bug here.
I'm not sure that there is another bug. The incorrect duration calculation will have had SC think that the track ended prematurely, and therefore restarted it at the point of the apparent failure.seek That is what the _RetryOrNext is doing.
There's no way to guarantee we'll get the duration right for all types of remote files like podcasts. I wonder if the auto-restart code should not be used on files with a defined length (Content-Length header).
Agreed, dont try to restart if fixed duration.
== Auto-comment from SVN commit #28542 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=28542 == Fixed bug 13361: Napster always repeats the same track Fixed bug 13967: On Boom: Short podcasts (and perhaps other media types?) repeat bits. Reopen bug 11888: Player should reconnect to a remote stream if the connection ends before the known duration bug 3161: Need more aggressive auto-retry for internet radio Revert change which attempts to resume fixed-length remote streams that appear to end prematurely, and which attempts to reconnect to remote streams that appear to be radio. The algorithms for detecting whether a stream has indeed ended prematurely are not sufficiently accurate in either case.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.