Thank you for your reply, roobarb!.
roobarb! wrote: ↑Thu Nov 29, 2018 10:06 am
An under-run would indicate that the Joggler's not getting the data quickly enough, either due to the wifi network bandwidth or some overly intensive processing that's happening on the LMS server or the Joggler itself. In what format do you store your local media? Has it always done this? Does your LMS install transcode before sending the data? Is your server overloaded?
Nope, it has never done this, and it's not doing this for any other player but the joggler. I have a duet, a boom, a radio, several computers running SqueezePlay and a couple Android devices of different ages and perfomance capabilities, all running SqueezePlay, and none of them has ever shown this issue before, nor are any of them showing these symptoms now. It's only the joggler that is affected by this phenomenon. Except for the duet and some desktop computers, all devices connect to the LMS via wifi. The issue occurs no matter how many devices are currently actively used. I even shut all devices but the joggler explicitly down, and it still occurred.
Now to your question how I store the media: the music is stored on a file server running NetBSD with very fast hard disks. The music files are all mp3, some bought, some self encoded. It doesn't matter which I select, it happens erratically with all of them. The LMS is running on separate computer, a Geode machine running a Ubuntu 15.04 that is just serving as our LMS. It connects to the NetBSD file server via nfs.
I am not sure about the transcoding, at the moment, but I always configure all devices the same, so if transcoding on server-side is an issue, it should happen to all devices, not just the joggler.
Looking at the load average, I'm pretty sure that the LMS machine is not overloaded - this is how it looks, while it's serving the joggler and a Squeezebox radio with different local mp3s:
Code: Select all
$ uptime
10:56:42 up 9 days, 21:06, 1 user, load average: 0.05, 0.08, 0.07
$ uptime
10:58:29 up 9 days, 21:08, 1 user, load average: 0.12, 0.10, 0.07
roobarb! wrote: ↑Thu Nov 29, 2018 10:06 am
Content from the internet will be subject to pretty stringent bandwidth controls, so is likely to be as efficient as possible, hence not having any trouble over wifi or on the Joggler. Your home content could be anything...
Yeah, I know. However, the stuff I stream comes in as a 320 kbit/s mp3 or 128 kbit/s AAC stream. My own MP3s are usually 192 kbit/s average bit rate encoded MP3 files, and I am not sure what the MP3s are encoded in that you can buy on amazon and other places - I always wanted to check that, but never got around, yet. However, it doesn't matter much, as only the joggler has that problem, and it's annoying as I'm sure you can imagine. I'm very willing to provide more logging information or whatever, to get to the root of this problem - just tell me where to look, because right now I have no idea, and I'm no computer illiterate...
.
If it were all Squeezebox devices, it would be so much easier...but no, it's just the joggler, which is why I'm posting this issue here in this forum. I will keep experimenting with a few settings (like lame quality / bandwidth limitation, etc), may be I find something. It's also planned to merge the LMS and the file server into one single linux machine, but there's no date for that, yet. If, for some reason, it's a server side performance issue that only kills the joggler (hard to imagine, when the duet, boom and all the other devices are playing fine at the same time - right now as I am writing this text, actually), that should end the issues then, as that machine a lot more powerful than the Geode, and file access would be direct. But as I said - no date planned, yet. I'll keep you posted, and if you have any idea, please let me know.
Thanks.