I've been experimenting with running LMS in the Doliana Docker container. Everything appears to be working, except for a problem with Squeezelite.
After playing a track for around 8 minutes (the exact time may be random or dependent on the LMS version, not sure), the audio cuts out and the progress in the LMS web interface hovers at the point at which the audio stopped playing. About 20 secs later, it resumes and plays normally until the end of the track.
Running SqueezeLite and LMS with debugging reveals that about 10 secs prior to the cutout, audio stops being decoded on the client, the output buffer runs down and then the client sends Slimproto STMo and is apparently told to pause by the server. At the end of the break in music, strm-q (stop) is received from the server and then playback is started afresh. There is no spike in network or disc activity in the server (a Pi4) and the heartbeat STMt and strm-t are transmitted and received as normal between the client and server while the buffer is running down and during the pause.
Curiously, this doesn't seem to occur when I use a natively installed LMS on a Pi3 with the same Squeezelite player or when the Dockerised LMS is driving a hardware player (a Squeezebox Controller).
This occurs on LMS 7.92 and 8.0 (latest nightlies as of about 8th May 2020) with Squeezelite 1.9.6-1210 ("win" and "ffmpeg" builds) on Win 10. It is common to at least flac and aac (in an m4a container) locally stored audio.
Can anybody help me diagnose this problem? I'm not sure whether it's likely to be a problem with the client or server or why Docker should make a difference (or why, if it is Docker and therefor a server issue, it wouldn't affect hardware playback). I've turned up debugging on the client and server, but may have missed something, particularly on the server side as I haven't known what logging categories I should be concentrating on and have masses of logging data coming out. A suggestion for the relevant logging categories might be a good start.
Thanks for any help.
After playing a track for around 8 minutes (the exact time may be random or dependent on the LMS version, not sure), the audio cuts out and the progress in the LMS web interface hovers at the point at which the audio stopped playing. About 20 secs later, it resumes and plays normally until the end of the track.
Running SqueezeLite and LMS with debugging reveals that about 10 secs prior to the cutout, audio stops being decoded on the client, the output buffer runs down and then the client sends Slimproto STMo and is apparently told to pause by the server. At the end of the break in music, strm-q (stop) is received from the server and then playback is started afresh. There is no spike in network or disc activity in the server (a Pi4) and the heartbeat STMt and strm-t are transmitted and received as normal between the client and server while the buffer is running down and during the pause.
Curiously, this doesn't seem to occur when I use a natively installed LMS on a Pi3 with the same Squeezelite player or when the Dockerised LMS is driving a hardware player (a Squeezebox Controller).
This occurs on LMS 7.92 and 8.0 (latest nightlies as of about 8th May 2020) with Squeezelite 1.9.6-1210 ("win" and "ffmpeg" builds) on Win 10. It is common to at least flac and aac (in an m4a container) locally stored audio.
Can anybody help me diagnose this problem? I'm not sure whether it's likely to be a problem with the client or server or why Docker should make a difference (or why, if it is Docker and therefor a server issue, it wouldn't affect hardware playback). I've turned up debugging on the client and server, but may have missed something, particularly on the server side as I haven't known what logging categories I should be concentrating on and have masses of logging data coming out. A suggestion for the relevant logging categories might be a good start.
Thanks for any help.