Bugzilla – Bug 1972
Playback incorrectly skips to next track
Last modified: 2009-09-08 09:29:16 UTC
Some tracks play to a particular point part way through and then skip to the next track. 1) Browse to album with faulty track 2) Play 3) Listen! 4) SB skips end of faulty track e.g., 2:30 through 4:39 track SB moves to next track System details: 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. Problem has been reproduced on SB and softsqueeze systems as detailed above. Playback works correctly using iTunes as the player. Server log output with --d_source option set gives the following around the point of skipping: 2005-08-14 18:18:30.9687 openSong: opening file C:\Documents and Settings\All Users\Documents\My Music\iTunes\Beth Gibbons & Rustin' Man\Out Of Season\02 Tom The Model.mp3 2005-08-14 18:18:31.0172 seeking in 2249 into C:\Documents and Settings\All Users\Documents\My Music\iTunes\Beth Gibbons & Rustin' Man\Out Of Season\02 Tom The Model.mp3 2005-08-14 18:18:31.0176 Streaming with format: mp3 2005-08-14 18:18:31.1091 c5:02:c8:b4:3b:6a New play mode: play 2005-08-14 18:18:31.1122 c5:02:c8:b4:3b:6a: Current playmode: play 2005-08-14 18:18:31.1172 We need to send 0 seconds of silence... 2005-08-14 18:18:31.1172 sending 0 bytes of silence 2005-08-14 18:18:38.9403 Setting maxBitRate for 127.0.0.1 to: 0 2005-08-14 18:18:38.9406 Setting maxBitRate for 127.0.0.1 to: 0 2005-08-14 18:18:51.2727 Got a track starting event 2005-08-14 18:18:51.2728 Song 0 had already started, so it's not longer in the queue 2005-08-14 18:18:51.2729 Song 1 has now started playing 2005-08-14 18:18:51.2732 Song queue is now 1 2005-08-14 18:18:58.2432 Backtrace: frame 0: Slim::Player::Source::playmode (/PerlApp/Slim/Control/Command.pm line 650) frame 1: Slim::Control::Command::execute (/PerlApp/Slim/Player/Client.pm line 1001) frame 2: Slim::Player::Client::execute (/PerlApp/Slim/Buttons/Common.pm line 255) frame 3: Slim::Buttons::Common::__ANON__ (/PerlApp/Slim/Hardware/IR.pm line 662) frame 4: Slim::Hardware::IR::executeButton (/PerlApp/Slim/Control/Command.pm line 603) frame 5: Slim::Control::Command::execute (/PerlApp/Slim/Player/Client.pm line 1001) frame 6: Slim::Player::Client::execute (/PerlApp/Slim/Hardware/IR.pm line 675) frame 7: Slim::Hardware::IR::processCode (/PerlApp/Slim/Hardware/IR.pm line 554) frame 8: Slim::Hardware::IR::holdCode (/PerlApp/Slim/Hardware/IR.pm line 475) frame 9: Slim::Hardware::IR::processIR (/PerlApp/Slim/Control/Command.pm line 603) frame 10: Slim::Control::Command::execute (/PerlApp/Slim/Player/Client.pm line 1001) frame 11: Slim::Player::Client::execute (/PerlApp/Slim/Hardware/IR.pm line 88) frame 12: Slim::Hardware::IR::idle (slimserver.pl line 613) frame 13: main::idle (slimserver.pl line 40) frame 14: PerlSvc::Startup (perlsvc.pl line 1481) frame 15: PerlSvc::_startup (slimserver.pl line 0) frame 16: (eval) (slimserver.pl line 0) In this case the end of the first track (song 0?) was skipped. More logging is available on request --- not sure whether this is the most useful section or not! Refer to: http://forums.slimdevices.com/showthread.php?p=48287 for other background. Nick.
vid, do you know what's up here?
Nick, could you attach a sample file to this bug. Also, your log would need to be a bit more complete. Specifically, I'd like to see when track 0 starts playing.
Created attachment 724 [details] Full SlimServer log This is the full log file generated from SlimServer with --d_source=1
Created attachment 755 [details] .mp3 file exhibiting skip Refer to http://forums.slimdevices.com/showthread.php?t=15726&page=1&pp=10 post #14 regarding my change of heart...
Created attachment 757 [details] Re-ripped .mp3 with no skip This mp3 is the same CD track as the other attached .mp3 file. The file has been ripped from the same CD, with the same software and the same settings. This file plays through to the end successfully and is provided to allow comparison of differences.
Nick, if you re-download these two sample files from there, do they still behave as you expect? I grabbed them both to take a look for differences and they are being reported as exact matches.
Umm... This is going to sound a little lame, but I can't find any instances of this bug showing itself any more... A little background: I have a number of CDs (about 50) in my collection and a few tracks (at least two that I was aware of) showed this skip-to-next-track problem. In an attempt to work around the problem I re-ripped all of the tracks from one of the problematic CDs, having first taken a backup copy of the faulty .mp3s. Having re-ripped the CD I instructed the SlimServer to re-scan my collection in order to update its records. After this, all worked well with the re-ripped tracks. This appears to have also fixed the problems in a different CD (where I have not re-ripped the tracks). Restoring my backup of the faulty .mp3s, and re-scanning, results in the track playing through to completion. Is it possible that this was, in fact, a problem with the SlimServer index? All I can suggest right now is that I'll carry out ripping more CDs and see if the problem ever reappears. Hmph. Just as a point of clarification: before this point I had never instructed SlimServer to rescan the available tracks. However, I do switch my machine off over night and understood that the server would rescan the next time it started up. Just thought I'd mention this in case there is any difference between a startup scan and a manually triggered scan.
I think you may be right that it was in the database. The DB stores the beginning and end point of the file so that we aren't streaming tags to the player. If it ever got confused on those points, then it may have the behavior you saw. Given that it's working now and we can't reproduce, I'm going to close this now. Reopen if you can figure out how to make it fail again.