I really need help to solve my problem. Hopefully someone out there can provide some insight.
I've been running Squeezebox for years, and my server is a Synology DS918+ running DSM 6.x.
I was running LMS 7.9.1 and recently upgraded to 8.0.1. My issue exists on either version of LMS.
I have used Squeezebox Duet without any issues, but now I no longer use the Squeezebox unit, and I listen on a couple of clients: SqueezeLite on Windows, and also piCorePlayer on Raspberry Pi. My issue is that when running a windows client (SqueezeLite-X and also SqueezeLite command line) the audio will stop for about a minute, and then resume.
Here is what I observe: (client side)
* SqueezeLite version 1.9.8 is run like this:
squeezelite-win.exe -d all=debug -s 192.168.0.60 -o 0
* With the 'debug' level, you see some activity in the console, which doesn't show much, but is helpful.
* I see some activity like this:
[18:59:29.781] connect_socket:158 connecting to 192.168.0.60:9002
[18:59:29.811] stream_sock:591 header: GET /stream.mp3?player=70:85:c2:a8:ce:68 HTTP/1.0
* This shows that it is getting an mp3 stream from the NAS server.
* I see activity about every 5 minutes:
[18:40:36.290] mad_decode:247 setting track_start
[18:40:36.290] _checkfade:287 fade mode: 1 duration: 3 track-start
[18:40:36.292] _checkfade:327 CROSSFADE: 132300 frames
[18:40:44.375] _output_frames:152 track start sample rate: 44100 replay_gain: 0
[18:40:44.375] _output_frames:180 fade start reached
[18:40:47.365] _output_frames:203 crossfade complete
[18:40:47.365] _output_frames:206 skipped crossfaded start
[18:45:38.698] decode_flush:236 decode flush
[18:45:38.698] output_flush:438 flush output buffer
[18:45:38.783] codec_open:264 codec open: 'm'
[18:45:38.783] connect_socket:158 connecting to 192.168.0.60:9002
[18:45:38.823] stream_sock:591 header: GET /stream.mp3?player=70:85:c2:a8:ce:68 HTTP/1.0
[18:45:38.908] stream_thread:325 headers: len: 116
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.1 - 1504317335)
Connection: close
Content-Type: audio/mpeg
[18:45:38.973] mad_decode:247 setting track_start
[18:45:38.973] _checkfade:287 fade mode: 1 duration: 3 track-start
[18:45:38.983] _output_frames:64 start buffer frames: 13295
[18:45:38.983] _output_frames:152 track start sample rate: 44100 replay_gain: 0
[18:45:39.324] stream_thread:398 end of stream
* From this we see that it is buffering the stream, and it appears that the client is getting music in chunks every 5 minutes.
* When the music stops, it is usually 5 minutes after the last logging activity seen. Then the music stops for about 1 minute, and the music resumes, and I immediately see some logging activity, similar to above. The activity is normal, and there are no errors, it just STOPs, and resumes again after 1 minutes.
* During this stoppage, I see on the browser-based page, the playback counter is looping. Let's say playback is at the 2:15 mark. The sound stops, and I see it count forward 5 seconds: 2:15, 2:16, 2:17, 2:18, 2:19, 2:20 then back to 2:15 again. It always goes forward 4 or 5 seconds, before looping back, and it always resumes at the place it stopped. This suggests it's some kind of 'buffering' issue. Due to some network-related delay, it just stops, but can resume when it is able to buffer more audio and continue.
* Looking around for some clues about what went wrong - first I look at the windows client machine - CPU, memory, disk, network - everything normal.
* Looking at the LMS running on Synology - CPU, memory, disk, network - everything normal.
* Looking at the Log files for LMS in /volume1/@appstore/SqueezeCenter/Logs but there is no server-side logging activity when this issue comes up.
* It only happens with the Windows client. It happens the same on 2 different windows computers. But I could not find any clues about why it is pausing, either on client-side or server-side. Everything seems 'normal' but of course, it's far from normal. This started happening more recently, like the last 1 year, but no issues before that.
* The Windows computer and Synology NAS are physically connected with wired ethernet via a router. I have not observed any network-related issues.
* I searched the web for some forum postings and discussions, but I could not find any discussion about this particular issue.
* I'm a technical user, I'm very familiar with administrator-level stuff on windows, and I can get around linux too. With all the technical knowledge I could muster, I simply cannot figure out what is going on with this Squeezebox. I realize all the tech is very old, and some is now end-of-life - Synology is no longer offering LMS, and I need to download it from Sourceforge, and even that is now no longer supported since 2015. The windows client is also old, and not updated since 2014. I get it. There might be no 'fix' and it might be time to retire the Squeezebox altogether.
Best wishes to all for a safe and happy new year.
I've been running Squeezebox for years, and my server is a Synology DS918+ running DSM 6.x.
I was running LMS 7.9.1 and recently upgraded to 8.0.1. My issue exists on either version of LMS.
I have used Squeezebox Duet without any issues, but now I no longer use the Squeezebox unit, and I listen on a couple of clients: SqueezeLite on Windows, and also piCorePlayer on Raspberry Pi. My issue is that when running a windows client (SqueezeLite-X and also SqueezeLite command line) the audio will stop for about a minute, and then resume.
Here is what I observe: (client side)
* SqueezeLite version 1.9.8 is run like this:
squeezelite-win.exe -d all=debug -s 192.168.0.60 -o 0
* With the 'debug' level, you see some activity in the console, which doesn't show much, but is helpful.
* I see some activity like this:
[18:59:29.781] connect_socket:158 connecting to 192.168.0.60:9002
[18:59:29.811] stream_sock:591 header: GET /stream.mp3?player=70:85:c2:a8:ce:68 HTTP/1.0
* This shows that it is getting an mp3 stream from the NAS server.
* I see activity about every 5 minutes:
[18:40:36.290] mad_decode:247 setting track_start
[18:40:36.290] _checkfade:287 fade mode: 1 duration: 3 track-start
[18:40:36.292] _checkfade:327 CROSSFADE: 132300 frames
[18:40:44.375] _output_frames:152 track start sample rate: 44100 replay_gain: 0
[18:40:44.375] _output_frames:180 fade start reached
[18:40:47.365] _output_frames:203 crossfade complete
[18:40:47.365] _output_frames:206 skipped crossfaded start
[18:45:38.698] decode_flush:236 decode flush
[18:45:38.698] output_flush:438 flush output buffer
[18:45:38.783] codec_open:264 codec open: 'm'
[18:45:38.783] connect_socket:158 connecting to 192.168.0.60:9002
[18:45:38.823] stream_sock:591 header: GET /stream.mp3?player=70:85:c2:a8:ce:68 HTTP/1.0
[18:45:38.908] stream_thread:325 headers: len: 116
HTTP/1.1 200 OK
Server: Logitech Media Server (7.9.1 - 1504317335)
Connection: close
Content-Type: audio/mpeg
[18:45:38.973] mad_decode:247 setting track_start
[18:45:38.973] _checkfade:287 fade mode: 1 duration: 3 track-start
[18:45:38.983] _output_frames:64 start buffer frames: 13295
[18:45:38.983] _output_frames:152 track start sample rate: 44100 replay_gain: 0
[18:45:39.324] stream_thread:398 end of stream
* From this we see that it is buffering the stream, and it appears that the client is getting music in chunks every 5 minutes.
* When the music stops, it is usually 5 minutes after the last logging activity seen. Then the music stops for about 1 minute, and the music resumes, and I immediately see some logging activity, similar to above. The activity is normal, and there are no errors, it just STOPs, and resumes again after 1 minutes.
* During this stoppage, I see on the browser-based page, the playback counter is looping. Let's say playback is at the 2:15 mark. The sound stops, and I see it count forward 5 seconds: 2:15, 2:16, 2:17, 2:18, 2:19, 2:20 then back to 2:15 again. It always goes forward 4 or 5 seconds, before looping back, and it always resumes at the place it stopped. This suggests it's some kind of 'buffering' issue. Due to some network-related delay, it just stops, but can resume when it is able to buffer more audio and continue.
* Looking around for some clues about what went wrong - first I look at the windows client machine - CPU, memory, disk, network - everything normal.
* Looking at the LMS running on Synology - CPU, memory, disk, network - everything normal.
* Looking at the Log files for LMS in /volume1/@appstore/SqueezeCenter/Logs but there is no server-side logging activity when this issue comes up.
* It only happens with the Windows client. It happens the same on 2 different windows computers. But I could not find any clues about why it is pausing, either on client-side or server-side. Everything seems 'normal' but of course, it's far from normal. This started happening more recently, like the last 1 year, but no issues before that.
* The Windows computer and Synology NAS are physically connected with wired ethernet via a router. I have not observed any network-related issues.
* I searched the web for some forum postings and discussions, but I could not find any discussion about this particular issue.
* I'm a technical user, I'm very familiar with administrator-level stuff on windows, and I can get around linux too. With all the technical knowledge I could muster, I simply cannot figure out what is going on with this Squeezebox. I realize all the tech is very old, and some is now end-of-life - Synology is no longer offering LMS, and I need to download it from Sourceforge, and even that is now no longer supported since 2015. The windows client is also old, and not updated since 2014. I get it. There might be no 'fix' and it might be time to retire the Squeezebox altogether.
Best wishes to all for a safe and happy new year.