max2play dropouts and pauses

[middletonian premium]

middletonian premium

15. April 2020 at 18:01 #48502

Hi,
I have an intermittent problem with max2play running on a Raspberry Pi 3B+. This services three clients – two Raspberry Pi 3Bs running Squeezelite under Moode, and an RPi4 running Squeezelite within Kodi. I have all three clients synchronised. The server Pi has an attached USB HDD with a Y-cable and second PSU providing additional power to the drive.

The problem is that some days I get frequent dropouts and pauses. The music will stop, then (usually) immediately restart – sometimes where it left off, sometimes from the beginning of the track. I can tell there been a stop because the client players have a 5 second fade-in on resume. The system can run for a day or two without problems, but on other days it happens frequently: today was a bad day with multiple restarts within each song. Sometimes rebooting the server Pi cures the problem temporarily, but not always. I tried a complete reinstall of the max2play OS, but the problem came back. I also tried a 3A power supply for the Pi, but that didn’t help either. I have the problem with both music from the server and also with internet radio.

I’ve been running this system for a year, and the problem only started a few weeks ago. Can anyone help me diagnose and fix it?

Thanks in advance,
Andy (Middletonian)

[MarioM Moderator]

MarioM Moderator

16. April 2020 at 14:37 #48520

Hi Andy,

Did you change anything on your system before the problems occurred? For example an update to the latest Max2Play version? Which Max2Play version do you use on your server? Did you connect the server to the internet via LAN or WiFi? Did something change in the Health Checker at the „Settings/Reboot“ tab when the dropouts occurred?
Apart from that the log file from the Squeezebox server could help us to identify the problem. You can find it in the server settings under „Information“.

[middletonian premium]

middletonian premium

16. April 2020 at 15:29 #48527

Hi,
My memory is a bit hazy, but I suspect that this all started when I upgraded to the latest version of max2play – I’m now on v2.51. The server Pi is connected by LAN, as is one of the clients; the others are on a Powerline adapter and a wifi bridge.

As it happened, it’s been OK today, but as I was typing this reply I had another bad series of dropouts – this time with severe stuttering. Moving on to the next track seems to have cured it, probably temporarily. However, there is nothing in the debug log on max2play or on the LMS log file for that date & time – the last entry was at 06:18 this morning. Nor was there anything unusual in the Health Checker, other than the CPU load being at 40% when it’s usually nearer 10-20%. But there are some error messages from yesterday when I was having trouble. Here’s the relevant lines:

2020-04-15 06:09:02 squeezeboxserver_safe stopped.
2020-04-15 06:09:05 squeezeboxserver_safe started.
[20-04-15 06:09:11.0149] main::init (387) Starting Logitech Media Server (v7.9.2, 1578996832, Tue Jan 14 12:16:57 CET 2020) perl 5.024001 – arm-linux-gnueabihf-thread-multi-64int
[20-04-15 06:09:12.1006] Slim::Utils::Misc::msg (1255) Warning: [06:09:12.0999] DBIx::Class::ResultSet::update_or_create(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/perl5/Slim/Schema.pm line 1871
2020-04-15 08:38:07 squeezeboxserver_safe stopped.
2020-04-15 08:38:10 squeezeboxserver_safe started.
[20-04-15 08:38:16.0711] main::init (387) Starting Logitech Media Server (v7.9.2, 1578996832, Tue Jan 14 12:16:57 CET 2020) perl 5.024001 – arm-linux-gnueabihf-thread-multi-64int
[20-04-15 08:38:17.1591] Slim::Utils::Misc::msg (1255) Warning: [08:38:17.1584] DBIx::Class::ResultSet::update_or_create(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/perl5/Slim/Schema.pm line 1871
2020-04-15 15:23:55 squeezeboxserver_safe stopped.
2020-04-15 15:23:59 squeezeboxserver_safe started.
[20-04-15 15:24:05.1187] main::init (387) Starting Logitech Media Server (v7.9.2, 1578996832, Tue Jan 14 12:16:57 CET 2020) perl 5.024001 – arm-linux-gnueabihf-thread-multi-64int
[20-04-15 15:24:06.1883] Slim::Utils::Misc::msg (1255) Warning: [15:24:06.1875] DBIx::Class::ResultSet::update_or_create(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/perl5/Slim/Schema.pm line 1871
2020-04-15 16:28:43 squeezeboxserver_safe stopped.
2020-04-15 16:28:46 squeezeboxserver_safe started.
[20-04-15 16:28:51.9996] main::init (387) Starting Logitech Media Server (v7.9.2, 1578996832, Tue Jan 14 12:16:57 CET 2020) perl 5.024001 – arm-linux-gnueabihf-thread-multi-64int
[20-04-15 16:28:53.0858] Slim::Utils::Misc::msg (1255) Warning: [16:28:53.0851] DBIx::Class::ResultSet::update_or_create(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single at /usr/share/perl5/Slim/Schema.pm line 1871
[20-04-15 19:54:54.0123] Slim::Networking::Discovery::Players::_players_error (144) Unable to get players: Connect timed out:
[20-04-16 06:18:28.8764] Slim::Utils::Misc::msg (1255) Warning: [06:18:28.8752] Error: Unable to read at least 10 bytes from file.

I note that the „safe stopped…safe started“ message appears on multiple occasions in the past.

BTW, is there any way for me to upload the complete log?

Thanks,
Andy

[MarioM Moderator]

MarioM Moderator

17. April 2020 at 15:41 #48538

Hi Andy,

To narrow the problem down a bit further: Do the dropouts happen without the players being synchronized? For example when playing on only one player? Did the dropouts occur with the Internet streams even if no hard disk was connected to the server and you operated the server with a single power supply? I will pass your request on to our chief developer, maybe he has an idea how to solve this.

[middletonian premium]

middletonian premium

17. April 2020 at 16:47 #48539

Hi Mario,

I always have all three clients synchronized, even when I’m listening to just one – I turn the individual outputs off through the downstream audio amplifiers. Similarly, I always have the hard disk connected so haven’t tested the use of just one PSU. I can experiment with this, but the dropouts are very stochastic – I’ve had no problems today, even though I’ve been listening since 6am. It’s also possible that the interrupts of the internet stream are different from those I get from the hard disk.

I can’t believe that this is connected, but I normally play my music in Random Song mode by genre, and the CPU load is around 20% with the temperature at ~60C. Today I’m playing individual albums (currently Ziggy Stardust) but the CPU load is only 6% and the temperature is 53C. I probably need to collect more data points before I construct a hypothesis around this….

Cheers,
Andy

[MarioM Moderator]

MarioM Moderator

21. April 2020 at 16:04 #48571

Hi Andy,

Please keep us informed about your tests. Please consider testing only with one player and switching off the others in the meantime. Especially the players connected via WiFi could cause problems. I also don’t think it depends on whether you’re on random playback or listening to individual albums. The difference in CPU usage is strange, but can again have all sorts of reasons.

[middletonian premium]

middletonian premium

1. Mai 2020 at 14:12 #48679

Hi,
Sorry about the long gap since my last post, but I’m happy to say that we haven’t suffered any dropouts in the last two weeks of more or less constant use during lockdown. This is despite the fact that I still have all three clients sync’d and have the HDD connected to the server Pi. I’ll report in if anything changes.
Many thanks,
Andy