So I've noticed that especially with large groups, the players tend to sometimes get completely out of sync.
However, Slim::Player::StreamingController::_CheckSync doesn't report a different offset than before.
[19-10-05 13:48:27.3185] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:28.3159] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:29.3160] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:30.3172] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:31.3164] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
In this example, 00:04:20:1e:9a:0c skipped over 30 seconds ahead somewhere around 13:48:29.
To fix this situation, the song has to be manually skipped to an arbitrary timestamp. This way, all players sync again.
Maybe the mp3 decoder receives broken frames and just skips them?
Affected devices are all Squeezebox Boom
Github Issue: https://github.com/Logitech/slimserver/issues/283
However, Slim::Player::StreamingController::_CheckSync doesn't report a different offset than before.
Quote:
[19-10-05 13:48:27.3185] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:28.3159] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:29.3160] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:30.3172] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
[19-10-05 13:48:31.3164] Slim::Player::StreamingController::_CheckSync (534) playPoints: 00:04:20:1f:2b:37: 1570276083.741, 00:04:20:1e:b4:d6: +0, 00:04:20:1f:6f:7c: +0, 00:04:20:1f:90:e5: -3, 00:04:20:1e:9a:0c: +0, 00:04:20:10:0b:5d: +1
In this example, 00:04:20:1e:9a:0c skipped over 30 seconds ahead somewhere around 13:48:29.
To fix this situation, the song has to be manually skipped to an arbitrary timestamp. This way, all players sync again.
Maybe the mp3 decoder receives broken frames and just skips them?
Affected devices are all Squeezebox Boom
Github Issue: https://github.com/Logitech/slimserver/issues/283