17. August 2021 at 19:11 #51573
I thought a new audio top went bad.
About every 2 sec. audio stop for a split sec. keep on doing that. I reloaded fresh max2play but did not help. I installed another OS that plays audio and it did the same. But streaming audio on it from the WWW it played good.
So I rebooted my server did not help.
Got about 7 Max2play players all different names. But it keeps switching a name like I showed on another post here in a short video.
The cutting the audio out some times I had to turn off the „SqueezeLite“ and „SqueezeLite 2“ I guess named them that because it don’t get it’s host name even though I can type in the host name to get to the max2play settings. The name it shows is not Squeezelite ether.
But when I turn the power off to squeezelite both them the audio started to play good again no split sec stops about every 2 sec.
I hope you can fix this get some other max2play players running on your LAN. I guess me saying to play from one max2play to another long ago may of messed this up. To do that looks like you change the hostname and I think that is way have the problem. I guess put it’s mac address in and don’t change the hostname. Not sure if that why this happened.
I my just have to reinstall all the max2plays start over.
19. August 2021 at 10:29 #51575
- This topic was modified 1 year, 3 months ago by Raymond Day.
Hello Raymond Day,
your hostnames must not contain special characters or spaces. Otherwise the names will be corrected automatically, which can lead to duplicate names in the network (e.g. maxpläy -> max2ply ; max2plüy -> max2ply).
Did all players get a different IP address? You can see this in the Max2Play web interface „WLAN & LAN“ at the very bottom in the „Debug Info“.
If IPs and names are uniquely assigned, we would have to further narrow down the possible sources of error. How many and which players are needed to provoke the problem? Are there combinations with which the error does not occur?19. August 2021 at 16:22 #51579
Here is the WLAN & LAN text of both the players that in LMS keep switching the names. In the upper right to both of the ones I have this text too.
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.86.55 netmask 255.255.255.0 broadcast 192.168.86.255 inet6 fd0d:1ced:8d68:3:e592:c5c2:9104:652b prefixlen 64 scopeid 0x0<global> inet6 fe80::ea31:af53:8008:5c77 prefixlen 64 scopeid 0x20<link> ether 8a:c3:2e:bb:f6:25 txqueuelen 1000 (Ethernet) RX packets 46698 bytes 10853538 (10.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 17985 bytes 1926279 (1.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 47 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 28 bytes 2616 (2.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 28 bytes 2616 (2.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ### WLAN ###
eth0 Link encap:Ethernet HWaddr b8:27:eb:09:fb:06 inet addr:192.168.86.118 Bcast:192.168.86.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:48175 errors:0 dropped:1 overruns:0 frame:0 TX packets:18025 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12481334 (11.9 MiB) TX bytes:1844739 (1.7 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:716 (716.0 B) TX bytes:716 (716.0 B) ### WLAN ###
Do you see anything in them why LMS will switch between them? If I start to play it will pay out of both of them. While it’s switching there names in LMS.
-Raymond Day25. August 2021 at 12:30 #51601
Please excuse the late reply.
The debug info looks normal. Both players have their own IP and MAC address. So I think this is not the cause of the problem. Do both run the same Max2Play version? Which Pi are you using with the two players?
Please test the faulty sound cards on other Pis (and their working Max2Play images) to exclude a hardware defect. Please also test playing local audio files. Do the dropouts really only appear when you play music from your network storage? Are the two affected players connected to the network exactly the same as the working ones? Please delete the network entries in your router again and reconnect the players with a fresh image.
You must be logged in to reply to this topic.