PDA

View Full Version : Squeezebox skips end of track



Nick McGrogan
2005-08-14, 08:38
I've just started to use a Squeezebox (original model, not 2) and am having problems with players skipping the end of some tracks. Apologies if as a newbie I'm covering ground that has already been cleared elsewhere, but I've not been able to find any descriptions of quite this problem.

First a summary of kit:
1) Squeezebox player running firmware version 40
2) Slimserver 6.1.1 - 3774 - Windows XP - EN - cp1252 running on MS XP Pro SP2
3) Softsqueeze 2.0b9 running on java 1.5.0_04

Audio tracks are stored as 160kbps MP3 files ripped using iTunes.

I have at least three tracks (only just started transferring my CDs and haven't exhaustively checked everything) which play to a particular point part way through and then skip to the next track.

This is reproducible on both the Squeezebox and Softsqueeze players and happens at the same point in the same track on both.

Playback of the tracks using iTunes works fine.

Any ideas?

Thanks in advance,
Nick.

radish
2005-08-14, 09:28
I have a similar problem with FLAC files on an SB2 (http://bugs.slimdevices.com/show_bug.cgi?id=1434). May well be unrelated, but who knows!

Nick McGrogan
2005-08-14, 09:56
Looks like your problem is similar, but perhaps different enough to be separate.

In particular: my player is skipping minutes of the track, not just final seconds. e.g., in one 4:39 track the jump happens at approximately 2:30 in.

I'm also using a wireless connection for the SB, but I assume that since it also affects softsqueeze (running on the same machine as the server) the connecion mechanism is immaterial.

I don't know much about the client / server architecture of the devices, so I don't really understand whether this is likely to be a server or client problem.

1) Is there anything I can do (e.g., with the softsqueeze debug options) to provide any further information?

2) Should I try raising this as an official bug? If so, any opinions on which component it relates to?

Nick.

dean
2005-08-14, 10:09
On Aug 14, 2005, at 9:56 AM, Nick McGrogan wrote:
> Looks like your problem is similar, but perhaps different enough to be
> separate.
>
> In particular: my player is skipping minutes of the track, not just
> final seconds. e.g., in one 4:39 track the jump happens at
> approximately 2:30 in.
>
> I'm also using a wireless connection for the SB, but I assume that
> since it also affects softsqueeze (running on the same machine as the
> server) the connecion mechanism is immaterial.
>
> I don't know much about the client / server architecture of the
> devices, so I don't really understand whether this is likely to be a
> server or client problem.
>
> 1) Is there anything I can do (e.g., with the softsqueeze debug
> options) to provide any further information?
>
> 2) Should I try raising this as an official bug? If so, any opinions
> on which component it relates to?
Please do. If it only happens in SoftSqueeze, then mark it as a
SlimServer-SoftSqueeze bug, otherwise mark it as SlimServer-Audio.

One helpful thing would be to turn on the --d_source option and send
the log for the time when it skips unexpectedly.

Nick McGrogan
2005-08-14, 10:43
I've now entered this as bug #1972 together with some log output as requested. I've attached to this message a text file with the same section of the log file.

gorstk
2005-08-14, 13:22
Nick McGrogan wrote:
> Looks like your problem is similar, but perhaps different enough to be
> separate.
>
> In particular: my player is skipping minutes of the track, not just
> final seconds. e.g., in one 4:39 track the jump happens at
> approximately 2:30 in.

Do you have the web interface open whilst listening? Is it whilst
updating that the sounds skips?

Nick McGrogan
2005-08-17, 13:50
The problem happens in the same way whether the web interface is open or not.

I've not manually triggered a rescan, and I've not added any music since this problem became apparent --- I don't see the point in adding more until it is sorted out since I keep finding new tracks which trigger the skip.

oreillymj
2005-08-18, 06:43
I'm not sure that this issue is specific to the SB.
My in-car MP3 (Sony http://www.sony.co.uk/view/ShowProduct.action?product=CDX-T70MX&site=odw_en_GB&category=ICA+MD+-+CD+Changer+%26+Packages) changer has a problem with some MP3's

I have a mixture of Franhoffer & Lame encoded MP3's and some of them always end early during playback. Some of the Franhoffer encoded MP3's had audible clicks and drop-outs. One of them "crashes" the decoder in the Sony box entirely, forcing me to skip on to the next track.
I've never bothered going to the trouble of reporting it to Sony as I doubt they would be able to provide afirmware upgrade to correct the issue.


All of my MP3's play back fine in Winamp, so I think it's a question of bugs in the encoder at the time of encoding coupled with bugs in various ecoders in players.

I believe the Mp3 playback in the SB firmware is based on MAD player.

Nick McGrogan
2005-08-18, 06:51
All of my MP3's play back fine in Winamp, so I think it's a question of bugs in the encoder at the time of encoding coupled with bugs in various ecoders in players.

Does this imply that re-ripping the offending tracks might solve the problem? (Something that I probably should've tried before but didn't...)

fuzzyT
2005-08-18, 08:22
Nick McGrogan wrote:

> Does this imply that re-ripping the offending tracks might solve the
> problem? (Something that I probably should've tried before but
> didn't...)

i'd say it's worth a shot. if successful it would isolate the issue and
give you a workaround. try alternate software to rip and encode (EAC
and LAME recommended). you might also try a different bitrate setting
in iTunes. or a more recent release of iTunes.

--rt

Simon Still
2005-08-20, 03:58
On 8/18/05, ron thigpen <ron (AT) fuzzsonic (DOT) com> wrote:
> Nick McGrogan wrote:
>
> > Does this imply that re-ripping the offending tracks might solve the
> > problem? (Something that I probably should've tried before but
> > didn't...)

I've had a lot of this sort of problem. As suggested, try ripping
with a different encoder (i've reripped some stuff before and had the
same issue). My default encoder is Lame at alt-preset-extreme. If i
get problems i rip with iTunes at 256 or 320 constant bit rate - my
theory is that its VBR tracks that cause the most problems.

dean
2005-08-20, 07:41
I'd love a sample file that exhibits this problem attached to a bug
filed at http://bugs.slimdevices.com/

Thanks!


On Aug 20, 2005, at 3:58 AM, Simon Still wrote:

> On 8/18/05, ron thigpen <ron (AT) fuzzsonic (DOT) com> wrote:
>
>> Nick McGrogan wrote:
>>
>>
>>> Does this imply that re-ripping the offending tracks might solve the
>>> problem? (Something that I probably should've tried before but
>>> didn't...)
>>>
>
> I've had a lot of this sort of problem. As suggested, try ripping
> with a different encoder (i've reripped some stuff before and had the
> same issue). My default encoder is Lame at alt-preset-extreme. If i
> get problems i rip with iTunes at 256 or 320 constant bit rate - my
> theory is that its VBR tracks that cause the most problems.
>

Nick McGrogan
2005-08-22, 14:21
On 8/18/05, ron thigpen <ron (AT) fuzzsonic (DOT) com> wrote:
> Nick McGrogan wrote:
>
> > Does this imply that re-ripping the offending tracks might solve the
> > problem? (Something that I probably should've tried before but
> > didn't...)

I've had a lot of this sort of problem. As suggested, try ripping
with a different encoder (i've reripped some stuff before and had the
same issue). My default encoder is Lame at alt-preset-extreme. If i
get problems i rip with iTunes at 256 or 320 constant bit rate - my
theory is that its VBR tracks that cause the most problems.


Sure enough, on a sample size of one (!) re-ripping has sorted the problem out, even using the same iTunes software with the same settings. That gives me a work-around at least...

Nick McGrogan
2005-08-22, 14:39
I'd love a sample file that exhibits this problem attached to a bug
filed at http://bugs.slimdevices.com/

Thanks!


On the basis that this request is likely to get raised quite alot I guess I'd better publicise my previously private response.

Bug #1972 has been raised for this bug and assigned to Vidur Apparao. Vidur raised a request on that bug note for further log details and an example file illustrating the problem.

The log file I have provided with no problem. However, I also e-mailed Vidur to point out that I clearly couldn't legally attach a .mp3 file to a public-access site without owning the copyright in that file... which I don't.

I did, however, e-mail Vidur privately with the file, and have since come round to the idea that I'm being a bit prissy... I'll see if I can attach the file to the bug in a moment... I guess that although not strictly legal, the powers that be probably have better things to do than chase over one track... If I stop answering my e-mail though, you'll know what happened.

If anyone wishes to start a philosophical discussion about the problems of developing code when the buggy test cases can't be legally distributed, then they're welcome...

fuzzyT
2005-08-22, 15:08
Nick McGrogan wrote:

> Sure enough, on a sample size of one (!) re-ripping has sorted the
> problem out, even using the same iTunes software with the same
> settings. That gives me a work-around at least...

In addition to finding a work around, you've also isolated the data that
triggers the bug.

For at least one of these tracks, please do the following: make a copy
of the bug inducing track, re-rip the track, and confirm that the new
file doesn't trigger the bug.

Please provide these two files to the SD development team. A file
comparison between the two should yield a clue as to what is causing the
hiccup.

--rt

Nick McGrogan
2005-08-23, 07:34
Forgot to post here last night --- I've added a working .mp3 file to the bug report. I would, of course, be interested to know what the differences are between those files...