Bugzilla – Bug 6344
hiccup 2 seconds into next playlist song if browser running
Last modified: 2009-09-08 09:26:48 UTC
similar problem reported in bug 3610 --- hiccup 2 seconds into next playlist song if and only if browser is running. All songs were uncompressed 1.41Mbit/sec on a SB1 hardwired ethernet. The problem ONLY occurs if the web browser is running. It doesn't matter whether I run the browser from a remote machine to access the server, or if the server has the browser up. No browser running, no problem. Running IE Win 2k PRO.
(In reply to comment #0) > similar problem reported in bug 3610 --- > hiccup 2 seconds into next playlist song if and only if browser is running. All > songs were uncompressed 1.41Mbit/sec on a SB1 hardwired ethernet. > The problem ONLY occurs if the web browser is running. It doesn't matter > whether I run the browser from a remote machine to access the server, or if the > server has the browser up. No browser running, no problem. Running IE Win 2k > PRO. One more clue, the buffer empties between songs if a browser is up, but remains nearly full as the next song is cued. It seems the browser momentarily stops/slows? the stream?
Jim: what's the specs of the server machine? Memory/CPU? It's likely that this problem is due to the small buffer in the device. Consider using MP3 encoding/transcoding or upgrading to a newer device or faster computer.
The machine is an athlon running at 1.5GHz clk, with 1.5GB of memory. There is plenty of memory available. It seems that the SB1 is the thing lacking in buffer memory, and SB2 and SB3 likely don't see this problem. I tried another browser (firefox) with the same result. I have a feeling the web page is not incrementally updated, but completely reloaded, which is just enough stuff to cause the tiny 1.8MB buffer to empty while SqueezeCenter is busy dealing with the page reload. I'm not interested in compressing my collection and listening to it thru a tin can (lower bit rate). I guess SB1 wasn't designed to run with the new interface at high bit rates. I always wondered why the old interface always displayed the wrong song and needed manual refresh. Have you tried to duplicate this with a SB1 or is that product "obsolete" w.r.t. the new software? I really do like the new interface, but I'm not that interested in learning Perl. Most of the time I'm not interested in looking at the browser, so I guess I'll just live with it, but it would be nice to have an optional selectable gap between songs in which the browser could update to the next song before refilling the buffer on SB1 so the next song doesn't hiccup. That is allow the SB1 buffer to empty, update the browser, then fill the buffer with the next song. This would only be needed for high bit rates (uncompressed audio) on SB1 and conditionally enabled in the presence of the browser. Then again, SB3 is the future I suppose, then again, WONTFIX == WontRecommend + wontupgrade == fixitmyselfandmaybebuildabetterboxandputyouguystoshamesincetherealsecrettodesignistheprecisionlinearhardwareandthissoftwarestuffisawasteoftime By the way, 50ps of jitter is nothing to brag about. OK, so I'm a little annoyed.
Indeed it sounds like that machine should be plenty fast enough. The real problem here is that the SB1 has less than two seconds of buffer memory when playing uncompressed audio. What that means is that when a track transition happens and the web server gets busy updating the web interface and slows down for even two seconds you'll hear it. I'll reopen this bug to be reviewed after we ship 7.0, and we'll gladly accept patches to fix this performance issue with older players, but it's not going to make it into the next release.
Thanks, My faith has been restored.
Not sure if you've done anything to address the problem but the problem has mysteriously disappeared. Possibly after many of the never ending microsoft updates, something changed. I noticed that the SC7 interface no longer "highlights' the next song entry, but rather displays a "note' next to the song and all works perfectly now. Apparently the browser update goes much quicker now, and the buffer doesn't empty. ---Somehow I can't help but believe life would be easier if I converted all my machines to Linux and go Debian. My EEE PC doesn't require all the junk that plagues my win2k server in the basement.
There is probably little we can do about this problem overall. Quite a bit of work went into optimizing the data traffic for the new WebUI, so this may have helped. Album-art can be the killer when time is very tight. I'm glad you like the new skin but note that the old skin is still available (classic). I also hear what you say about a 'tin can'. 128kbs MP3s can be pretty terrible. But at higher bitrates (240 or even 320kbps) and with a good encoder (lame) it is a different story. On-the-fly transcoding has to be an option. As you say that the problem has gone away for you now, I'll close this again.