Sorry this has to do with RightNow incident # 080612-001513

Created attachment 3497 [details]
Logfile

Hi People,

I'm the customer who has this problem.

Just for clarification - This fault also occurs when playing WAV files (16/44.1). Anoop, my test album D is WAV. So it is clear from the outset that this is occuring with another format as well as FLAC.

Regards

Rod

Sorry Anoop, its VISTA Ultimate (32bit) as well for the OS ;-)

Rod

Rod: Thank you for the information, what player are you using?

Can you attach a screen shoot or cut and past the data from SC > Settings > Status

Hi James,

I'm using a SB3.

FYI I'm on an overseas contract ATM in Malaysia (the SB3 is with me), so expect some time delays in replies to emails.

The data from the status page is,


     
SqueezeCenter StatusInformation on all identified devices connected to SqueezeCenter
 
Library statisticsTotal Tracks: 2,454

Total Albums: 151

Total Artists: 178

Total Genres: 39

Total Playing Time: 164:52:01

 
Music Scan Details   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


   (  of  )     


Progress information from the previous scan is not available.
 
SqueezeCenter InformationSqueezeCenter Version: 7.0.1 - 19705 @ Wed May 14 19:43:37 PDT 2008 - Windows Vista - EN - cp1252
Server IP address: 192.168.1.101
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt 

Platform Architecture: 586

Hostname: notebook2

Server Port Number: 9000

Total Players Recognized: 1

 
Player InformationName: 192.168.0.9

Model: Squeezebox v3

Firmware: 88

The IP address for this player is: 192.168.1.100:36112

The Ethernet MAC address for this player is: 00:04:20:12:36:52

 
Cache FolderC:\ProgramData\SqueezeCenter\Cache
Preferences FolderC:\ProgramData\SqueezeCenter\prefs
Plugin FoldersC:\PROGRA~1\SQUEEZ~1\server\Slim\Plugin, C:\PROGRA~1\SQUEEZ~1\server\Plugins
SqueezeCenter Log FileSqueezeCenter keeps a log file for all application related activities (Audio Streaming, Infrared, etc) here:
C:\ProgramData\SqueezeCenter\Logs\server.log (100, 500, 1000 lines) 
 
Scanner Log FileSqueezeCenter keeps a log file for all scanning related activities, including iTunes & MusicIP here:
C:\ProgramData\SqueezeCenter\Logs\scanner.log (100, 500, 1000 lines) 
 

Regards

Rod

QA needs to find out what may cause this to happen.  If all customers were having problems with FLAC and WAV this would be a huge problem.

only thing in log appears to be "timed out" failures (actually, player.source logging would be FAR less chatty for a first crack at tracking the problem).

Is f: a usb or network drive in this case?

F: is a usb drive (160GB iomega). We have tested copying the albums onto the internal c: of the notebook PC and played from there. The same problem occured. So we ruled out the drive as a problem.

Could the elevated levels of chatter between player and source be caused by a noisy signal from the network card? I only ask that because I have a noise issue in this new PC with the internal Sigma Tel high def sound card. There is drive noise interference through the audio signal itself. I know the sound card is not used by the SB3 but I wonder if the network card is copping the same problem? I did test the network speed in the old version of Slim Server and it tested at 5000kbs full 100% accuracy - so I assumed there was no problem with the network.

Still begs the question, why does this only manifest as a problem at the track change? Is it because the buffer has to empty from the "now playing" track before loading the next track - thus creating a fragile window where the SB3 audio stream can break down easily? Is it not possible to start loading the next track data while the now playing track's data is draining out of the buffer, 40 seconds from the end rather than only 10 seconds out? 

R

This line from the log is bothering me:
  frame 2: Slim::Player::Squeezebox2::failedDirectStream (/<C:\PROGRA~1\SQUEEZ~1\server\SQUEEZ~1.EXE>Slim/Networking/Slimproto.pm line 561

What that seems to indicate is a disconnect.  The server is registering that a player has lost connection while trying to play the song. One way to see more around that specific event would be to set network.protocol.slimproto to DEBUG in server settings->logging, along with player.source (so that we can have the same reference point as the current log).

Given the disconnect, I would personally try to find some way to reduce or eliminate the known noise issue on the network card.  That, or there is something else causing the player to drop off, despite the NetTest results.

to clarify - there is no known noise issue with the network card, I'm only guessing there may be, because of a noise issue with the sound card. Is there a way I can test for noise in the network card?

Also to clarify - there is no problem when playing a track (once started) the problem only occurs at the handover between tracks, the next track tries but fails to load. During the playing of tracks the buffer remains at 100% full with no hicups at all. What occurs at the track change to allow the player to drop off?

I will setup another log with the additional debug settings.

The log would have player.source and network.protocol.slimproto both set to debug. Any others you would also like set to debug?

I'll run the test tomorrow (Monday)as I'm busy this afternoon with priors. 

I'm sure we will get to the cause of this issue.

R

those two log options are good for a start.  thanks.

unable to load log file via bugzilla (http error 500).

Sent email to Annop and Deane-Freeman direct with log file attached. 

R

Created attachment 3541 [details]
snipped log

Attached is a snippet of the emailed log, with irrelevant sections removed.  The problem line is timestamped [08-07-07 07:06:29.8254].  This is where slimproto registers the player disconnect.  

Someone who knows the slimproto log info better than I will have to see if there is anything helpful in the slimproto log notes to explain why the player might be appearing to leave the network.

The original log was too big to attach (zipping may have helped) but it was very big as it appeared to still contain earlier logging. It can help to zip large files, but also helps to trim it down to the relevant test times.

My most humble apology for not reducing the size of the log file. I should have gone in and cut it down to size. I could not find a "clear log" function in SqueezeCentre, is there one?

FYI following the "possible noise in the internal network card" line of problem solving, I tried a USB to ethernet adapter running well away from the PC in a usb hub. The idea being to isolate the ethernet adapter away from any noise and bypass the internal network card. 

The SB3 still failed between tracks. The only difference was the buffer in the SB3 was slower to load (about 10 seconds instead of 1-2 seconds normally). Like before the fail was random.

I will also test to see if there is any relation between the internal HDD being active (source of sound card noise) at the time of track change over and the failures.

R

No, no correlation between the HDD being active and SB3 dropping that I could see. Using the usb network adaptor, the SB3 did manage to stay connected for an entire album even with the HDD being accessed during the change over. But the SB3 dropped off again between tracks 1-2 on the next album. 

R

Hi all,

Update from the trenches.

Having relegated the SB3 to a cupboard since the last email, the plan was to purchase a new Duet when I visted Singapore next. Remarkably I could not find a Duet anywhere in Singapore and only a single lonely SB3. As I wanted a Duet and the SB3 was selling for $520USD, it was not an option. SlimDevices is seriously missing out on the large tech-savy Asian market!

Anyway, I dragged my SB3 out again and managed to load up last nights beta of 7.1-22045. This version also included a firmware upgrade to V101 (from V88?).

This latest version initially was much more stable and robust. To give you an idea 
version 7.0 and older - fails at track change every 2-3 songs.
version 7.1-21008 - fails at track change every 7-10 songs
version 7.1-22045 (firmware101) - fails at track change every 15-20 songs (with limited testing so far).

Whatever is changing between each of these versions in relation to the way the data is being handled is nibbling around the edges of the solution and maybe the cause.

Is the new 7.1 version getting closer to a solution by stealth?

Regards  Rod

NB as I type - the SB3 has started to fail repeatably again. Sigh, will keep testing it to gain a better guage on the amount of failures.

Nope - with continued testing and with the same albums as previously tested, the new version is just as unstable as the 7.0. Even albums that played Ok this morning will not play now. 

Could it be a heat related hardware issue? The SB3 is now quite warm to touch especially above the power connection socket.

Looks like back to the cupboard with the SB3 for another 5 weeks before I can test it with a known to work Pc and network. :-(

Regards

Rod

Waiting on feed back from customer.

Have corresponded with Anoop this morning and the plan still is to wait till I'm able to test conclusively with a known PC system. This will be done when I'm back home in 3 weeks time.

R

Progress report.

I have now tested the SB3 with my home PC (old Dell 8300 hyperthreading, running windows XP SP2)) and Billion ADSL router with the following results.

Using the old known to work Slim Server V6.5.4-12568 and SB3 Firmware Version 81, the SB3 played 69 tracks (including those tracks which previously failed) in one playlist without a single failure.

The software on that PC was then upgraded to the latest 7.2-22900 SqueezeCentre with the firmware upgrade to V112 on the SB3. Again with a test of a 74 track playlist including those previously tested, the SB3 played all the tracks with any problem non stop.

From this testing we can rule out any fault with the SB3 itself or the new software. 

The problem appears to be in the new Dell notebook D830. I will now have that notebook repaired by Dell and test again when it comes back. 

Will let you know what happens then.

Many thanks to all those at Slim Devices who took the time to inspect this issue and attempt to resolve it.  At least SD now has an example of a problem which is created by a PC hardware fault which causes the networked device to drop off the network when a new track is cued up.

I will add the new 7.2 version runs very slow on this PC here compared to the old version 6.5.4.  But at least it works so I cannot complain.

Regards

Rod

Reduce number of active targets for SC