Unfortunately, this is *not* an issue with a particular external codec, although it could be a problem with an internal firmware codec. SQB uses its own codec in its firmware to decode mp3 and flac (and soon ogg vorbis/wma). You are just streaming the data file to the SQB from slimserver when you are playing an mp3 file. The SQB is actually decoding, so the lame version on your computer is not relevant. I have been experiencing sporadic but similar problems with song transitions for nearly two years. My library is entirely flac based. I am using linux.
I have seen no activity on my linux boxes when this event occurs. No alarming messages or traces. My 3 GHz CPU Celerons (no CPUFreq or speedstep so running full speed) are so completely bored by the whole thing that I'm almost embarrassed to be checking if the system might be overloaded. Memory is untaxed. Power management is disabled. Network bandwidth remains unchallenged. All systems are wired with new switches, routers and cables rated at CAT6. I do not use crossfade. I have verified my flac files using -t option to flac encoder supplied with slimserver. All performance statistics are in reasonable ranges. I have posted here in the past. I have captured the --d_select, --d_source, and --d_slimproto logs of the condition both prior to the stop and after the stop. You should add these flags to your debug efforts. You will see that the SQB and slimserver end up in a slimproto handshake that both agree is ok, but excludes any other protocol messages and leaves the SQB "playing" silence until some IR event wakes it up. The difficulty here is identifying whether it is slimproto in the server that is broken, or slimproto in the firmware. My analysis has shown that at the end of the track that plays forever, there is a small chunk (less than 1KB) remaining in the SQB buffer. I am settling on the opinion that a final UDP packet is lost or fumbled someplace, and that throws the protocol out of whack (UDP has no guarantee of delivery). A simple enough fix might be to check if the currently playing track has passed its duration with no final chunk received. The problem with synchronizing the protocol (provided this is even how it works) is that the SQB no longer respects slimproto based commands (SQB does not respond to web interface or CLI commands) and requires direct IR activity to correct the situation (a further indication that the protocol has been violated by one of the partners). Something I noticed from your list of tracks produced by the Now Playing plugin is that the request subsystem seems to be generating two identical callbacks for the same event (newsong event?). It seems to be doing it pretty regularly. I have seen that in the past, but have not seen a consistent correlation with an immediate transition state problem. Still, I've often wondered why the request subsystem would generate duplicate callbacks for notification requests. It kind of raises the question if it is possible for the request subsystem to generate *no* event. Some things that I have done to help minimize this problem are 1) static IP address on the server and on the SQB, 2) removal of all other player references from slimserver(.conf/.pref), 3) disabling unneeded formats, and 4) disabling unused plugins. Factory reset using power and plus button is a must after installation. Again, what seems to work is to make the server more available during song transition (so it does not miss that final UDP packet?). I go through a lot of SQBen as an A/V installer. I have many clients with varying levels of slimserver and SQB2/3. They are in all cases very happy (thank you slimdevices developers and friends). Instead of focusing on the behavior of one SQB, I have tried to focus on the behavior of many SQBen in a variety of configurations. I appreciate your dedicated effort to solve this problem. I am getting regular stops on a pair of squeezeboxes that were briefly connected to the squeezenetwork. These SQB3 were ordered recently, removed from the box, attached to squeezenetwork, tested with some radio streams and then permanently wired to a network with slimserver 6.5.1. Then trouble started with both of them failing to transition properly with 6 hours of activity. An obvious test will be to open two more SQBen to replace the first two (with no squeezenetwork or radio stream testing) and see if there is change. Philip, you are not alone with these transition problems. I believe your question about the versions of the codecs in the firmware is relevant. I hope that someone responds with that information. When trying to track down a problem as elusive as this one, even the smallest clue might be the one that leads to the answer. Please continue your efforts to identify the problem. Richard -- RichardG ------------------------------------------------------------------------ RichardG's Profile: http://forums.slimdevices.com/member.php?userid=801 View this thread: http://forums.slimdevices.com/showthread.php?t=33044 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
