Bugzilla – Bug 4738
22khz and 11khz songs no longer play with 6.5.1 or sound poor
Last modified: 2008-12-18 11:11:58 UTC
A customer reported that when trying to play the attached file he hears static, and the player freezes and must be rebooted. I wasn't able to reproduce this, however I was unable to get his file to play in 6.5.1.
Created attachment 1805 [details] music file that doesn't play
What happened when you tried to get his file to play, Ross? Were you able to scan it correctly? Did it display an error message? Did the player crash? Thanks.
Sorry about that Chris. Friday I was seeing something different. Now the song simply doesn't play, verified this behavior on 2 different SlimServers with 2 different SB3s. Simply stays at 0:00.
Created attachment 1807 [details] MP3 files at 8, 11, 16, 22, 24, 32, 44.1 & 48 KHz I created a set of MP3 files at each of the MP3 supported sample rates. Attempting to play an MP3 on SB3 or Transporter with a sample rate of 24 or less results in the player output stopping. The player will attempt to play the file however the time display does not change and no sound is generated. The player remains responsive and it is possible to select another file for playing but will not play. Holding down the power button to reset or unplugging and replugging power will allow the player to function normally again. Note to self: This sounds familiar. Attempting to create a log of the problem I set "(player.source)" to "Debug" in Home/Server Settings/Debugging. Making this change however caused the symptoms I was experiencing to go away and I was able to play all sample rates without problems. Chris, suggestions? SlimServer Version: 7.0a1 - 11354 - Windows XP - EN - cp1252 Server IP address: 192.168.1.105 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt
Richard, does this make any sense to you? Steven was testing this on 7.0 and found that if he turned debugging 'on' all the files played correctly!
No, this does not make much sense. But if enabling debug in the slimserver makes it work then it's a slimserver not a firmware problem. Unless of course that was just coincidence.
Just wanted to note that Bug 4639 & Bug 4743 exhibit the same behavior.
If it's possible, it would be preferable to fix this in 6.5.2. Wallace I'm going to start cc'ing you on bugs that contain sample data that we need to add to automated testing. However, please continue to work on implementing the tests from Subversion in your framework as your highest priority. We can work together on the sample data tests later.
Just a note. The test files I created were meant to be used to determine playback ability only and not for content.
This appears to be fixed in fw75 which I am currently testing. I'll make a note when this makes it into a nightly build.
Heh well that makes no sense as I've not fixed anything that should effect this. oh on second thoughts the fix in Bug #4750 might have made all the difference. Yes that makes a lot of sense, thanks for spotting the fix Chris :)
Props to my new guy Steven for suggesting I test this bug against FW75!
is this then considered fixed along with bug 4750? should we update changelog and mark it off?
Ross could you try to figure out who in support owns your old ticket, and make sure the customer is aware that there is a fix in the nightly? KDF, do you have the power to update the changelog? This bug is officially fixed.
I've passed this along to support. Thanks!
Fixed in 6.5.2, which is now released and available for download at http://www.slimdevices.com/su_downloads.html If you're still experiencing this bug, please re-open it!