Bugzilla – Bug 11266
Napster tracks not playing completely and restarting.
Last modified: 2009-10-05 14:37:45 UTC
Napster tracks often play approximately half way through, then restart over and over. Reported by a number of other forum users too. Seeing this happen via SC and & SN on my SB3. Please advise on any extra info that might help you diagnose.
Dominic, please don't change the importance when creating a bug, that will be set after review. Andy, does this sound familiar to you?
No I need a way to reproduce this, or a log from SC with plugin.napster and player.streaming.direct debug.
Dominic: Please link the forum listings in this bug. Can you also provide the logs requested?
Dominic: do you still have this issue using SC? can you provide the logs requested in comment #2
Sorry for the delay, i have been trying to reproduce the errors for a couple of days now. Yes, it appears to be working much better. But the problems do seem very intermittent; some days everything works fine, others i see all sorts of issues (including silent playback, tracks restarting after 20 seconds in a loop, tracks never advancing through to the next playlist item, albums/tracks not playing at all and connection timeouts etc). Many Napster problems where reported on the forums, but reports seem to have died down. Could be that people have given up after the trial, or could be that they have seen an improvement too. I will continue to try and log any issues. In the meantime, feel free to mark this closed, but dont lock it so i can reopen it when/if i see problems again if thats okay.
Created attachment 5104 [details] Crash log
Created attachment 5105 [details] Skipping
(In reply to comment #2) > No I need a way to reproduce this, or a log from SC with plugin.napster and > player.streaming.direct debug. Hi, I have the same or at least similar problem with Napster simply stopping, skipping to the nexz song or even crashing the Boom (some sound, then it restarts). It happens often, almost every song . My wired Receiver has absolutely no problems. Player Model: boom Firmware: 45 Player IP Address: 192.168.2.118 Player MAC Address: 00:04:20:1e:9f:92 Wireless Signal Strength: 89% Squeezecenter: Version: 7.4 - 25811 on Synology DS-209+ It happened on an 7.3.3 nightly and the 7.3.2 release as well A friend of mine uses Vista, SqueezeCenter 7.3.2 has the same problem. Streaming from the local music library works perfectly (even WMA songs) Attached is a log if boom crashing and one of the boom skipping to the next song. There is no log entry during the crash, the last one is at the start of the song. Rudolf
Andy notes the track names to try are in the logs. Andy also reminds us that this is not the first report where Boom crashes more often than Sb3, so do try repro this on the Boom.
The specific songs do not matter. I tried a random album from Staff Picks right now, EVERY song failed. There is one common thing, the problem most often happens around 1 minute into the song. I will setup my boom for ethernet and do more tests.
Ok, I think I found something helpful: I enabled the buffer fullness indicator on the now playing screen. This increases slowly from 0.0/0.0 to 50./10.0, then to 196.5/10.0 (after around 55 seconds) and now it often drops to 0.x/9.x then the first number increases again, the second number decreases and the boom crashes around 30/4.0 (a few times it seems to recover by skipping) For the record, wired Boom and wireless receiver seem to be stable. Rudolf
Good info. If you have no problems wired, and this issue wireless, you almost certainly have a wireless issue causing the player to run out of data. Try changing wireless channels, etc.
I noticed the "Best of Philip Glass" album in these logs is only in the German Napster library. Thinking maybe this was related, I switched to a German account but was able to play a few tracks from this album on a wireless Boom without any issues. QA: could you try Napster on a wireless Boom on the artificially bad network?
Dominic: do you know if you have QOS enabled in your Router? What brand / model Router do you have.
> QA: could you try Napster on a wireless Boom on the artificially bad network? My wireless network is very good, the boom is now only 1 m away from the router. Network Test is perfect upto 5000Kbps. One more observation, wired the maximum buffer fullness is 196.5 wireless it is 196.6 and this is then the crashes happen! (In reply to comment #14) > Dominic: do you know if you have QOS enabled in your Router? > > What brand / model Router do you have. I have an Speedport W701V, no QOS
I did one more test. The crashes/skips always happen at buffer fullness 195.6. Songs shorter than 5 minutes (most of songs) do not reach this level, so they work fine. The behaviour after reaching the 195.6 varies, either skipping, going silent or most of the time crashing. So this is most certainly a buffer overrun problem. Wired buffering seems to be constant compared to the wireless buffering, where the growth rate fluctuates. This could be an explanation why it only happens on wireless.
Can you set network.protocol.slimproto to DEBUG? That will have the raw buffer values listed.
Some more info, the wireless receiver crashes the same, I do not know why it worked last time(maybe did not test enough last songs). I increased the rate of the status updates to 100 per second, so I could get the real fullness at the time of the buffer overruns. THis is the statistic I got (Received is the difference in bytes received from the status update compared to the previous update): Fullness Before Received Fullness After 15:39:47.5893] 2FF7FF 904 103 15:40:42.5916 2FF7FF 16B0 AAF 15:42:04.6203] 2FFBFF 904 103 15:43:42.3295] 2FFBFB 9A7 1A2 15:44:51.1481] 2FF7FF 904 103 15:46:05.2833] 2FF7D7 1104 DB 15:47:45.5971] 2FF7FF 1104 103 15:49:31.0103] 2FF7FF 9A3 1A3 Normally the buffer only accepts as much new bytes as it has room, but sometimes it takes more and overfills the buffer. It can be at the same buffer fullness level for a while without crashing. COuld it be that this happens during the buffer wraparound (2FFFFF -> 0) the remaining buffer size is miscalculated? The maximum fullness of the wired boom (without pausing) is 2FFD45, I left it running for some hours (1s status updates) The maximum fullness is 2FFFFF on the wireless boom and it happens often, that it goes over 2FFBFF So the wired simply spends much less time in the critical region (the packets might be smaller, but I checked the MTU for wired and wireless seem to be equal)
The problem is still happening. I have found a workaround: after synchronizing the wireless Boom to my wireless Receiver there are no more crashes (I listened to the boom, but I think the receiver did not crash either). I tested it with playing a long song a couple of times and casual listening to Napster music for 20-30 hours. The workaround seems not to work for a friend. He has the same router (Speedport W701W) but a faster DSL line. BTW I tried the proxied streaming setting for the boom before, this did not make any difference, I guess it does not apply to Napster.
*** Bug 12490 has been marked as a duplicate of this bug. ***
*** Bug 12773 has been marked as a duplicate of this bug. ***
This appears to be a SP only bug now, as IP3K devices on test.sn are fine, but SP based devices still have buffering issues.
Richard should look at this.
== Auto-comment from SVN commit #6981 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=6981 == Bug #11266 Add additional debug support for buffer fullness in SP.
== Auto-comment from SVN commit #6320 to the player repo by richard == == https://svn.slimdevices.com/player?view=revision&revision=6320 == Fixed Bug #11266 WMA optimizations for SP. This change gets a nearly 50% increase in decoder speed.
== Auto-comment from SVN commit #6985 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=6985 == Bug #11266 Modified the debug for buffer fullness, this is now always shown in place of the time on the icon bar when 'audio.decode' debug is enabled.
*** Bug 13164 has been marked as a duplicate of this bug. ***
== Auto-comment from SVN commit #6989 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=6989 == Bug #11266 Need to turn off thumb for the decoders.
== Auto-comment from SVN commit #7053 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7053 == Bug #11266 Allow the decoder to run faster while the output buffer is not full, this was causing further problems with wma playback.
== Auto-comment from SVN commit #7054 to the jive repo by richard == == https://svn.slimdevices.com/jive?view=revision&revision=7054 == Bug #11266 Don't call the decoder after an error has occured.
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.