On DietPi, myMPD stops connecting to MPD after running for several hours #1209
Comments
jalsco
changed the title
jalsco
changed the title
|
Strange issue. Please provide MPD verbose logs and myMPD debug logs. |
|
Thanks for fast reply 🙏🏻😊 Now I will just let the music play and wait for next fail. I will send all the details from MyMPD's log/journal when that happens. Probably will be several hours later in my work day which is just starting now. By the way - MyMPD is awesome ! and everyone here loves it . Thank you 💖 |
|
Yes, this are the correct log settings. |
|
Here is the output after a day of playing. It seems like connections still active. Still monitoring. |
|
Is there a further mpdclient connecting to this MPD instance? |
|
several clients connect - 2 different windows machines, 2 iOS devices (14.5.1 and 12.5.7 ) via either Firefox or Safari on each device. Rarely other devices. It is still running now (2 days later). The only change I made was setting the logging. I am still expecting it to fail some time soon. Young daughter in the past has rebooted it when her music stops, but assures me that she has not in last 2 days. |
Was there an update for DietPi ? I also have ympd installed, but I may uninstall that as it is rarely used. |
|
I released myMPD 14.0.1 |
|
Any updates for this issue? |
|
It looks like the issue is resolved. It has been running now for several days without those symptoms that I reported . |
|
Problem is happening again 😢 Please re-open this Issue . Now that server, batopi (running dietpi) , is on myMPD 15.0.1
|
|
|
Yesterday, after few weeks of not using it, the messages and screenshots above were encountered. So did a I assume MPC is a console based operation of MPD ? It is not installed, I will check and find it (but I expect it would work) as Status of MPD and MyMPD are green. About "verbose logs" a few month ago when this reported, I did enable verbose logging. IT has been that way since then. Please direct me to where the log file will be (I have been searching) ? |
|
I think this 👇 is the logs. Please advise if the logs are different to that. |
|
For anyone else on DietPi reading this thread. Install mpc : Note also @MichaIng comment from July 2019: MPC is now installed and working 👇, but cannot draw immediate conclusions as (my assistant) rebooted DietPi and started some music using MyMPD before MPC was installed. Next time the sockets problem shows up I can test if MPC is still working at that time. |
This is the problem. The MPD socket is gone. It seems it is not a myMPD bug. |
|
The same problem recurred now. |
|
So, if myMPD is not cause of the problem, then which component is the one responsible for the problem ?? MPD ?? or DietPi ?? or something else ?? Until this problem we only using myMPD for our music. That's the client we like the best. Please advise what is next step for me to follow up, because it is a real problem ? 🤷🏻♂️ |
|
How does mpc connect to MPD? You should not start mpc with sudo, but with a normal user account. I need more information from the time the error occurs:
I think mpc connects to localhost:6600 if there is no socket. That could be the reason why mpc works and myMPD not. |
|
MPD is not running, obviously. Check: journalctl -u mpd |
|
I really think that MPD is running, as it has green "active (running)" status when checked with The problem seems to be that the socket drops out, and thus doesn't exist anymore, as shown by Also - restarting MPD - has no effect on the problem, but rebooting whole system fixes it. |
|
MPD def running and can play music via MPC, but the socket that myMPD was using doesn't exist 👇 |
|
As a workaround you can change the connection from socket to IP for myMPD. I have no idea why the socket disappears. It must be DietPi or MPD related. I suspect a |
|
The Generally, the grep bind_to_address /etc/mpd.confIf it is defined, but the socket is missing, there must be some related error in the logs, either at (service) start or e.g. before a(n automatic) restart after a some crash. |
I think No 🤷🏻♂️ it does seem to work. That surprises me too. I mean: when the problem happens, and the |
|
Just in case, the actual location does not exist either, does it? ls -l /run/mpd/socket
|
Hi @MichaIng 😊 A system restart ALWAYS fixes the problem. At this point in time I have found no other way to fix the problem. After a system reboot, the socket will be there, and so myMPD will run, for several hours. Then, often after a period (hours) when no music playing, come back to myMPD to load another playlist and will find this error and that the socket no longer exists: |
|
ls -l /run/mpdProbably something is wiping |
|
Right now, some songs playing by MPC, but the socket does not exist. I will soon do a system reboot , so myMPD works again . You want some logs from immediately after the reboot ?? |
|
|
Please check the full service logs for for any restart, crash or error message: journalctl -u mpdUse spacebar to scroll them til the bottom. |
|
Ah, the socket is not generated by MPD itself, but a dedicated systemd unit: systemctl status mpd.socketIn case: journalctl -u mpd.socket |
|
The ONLY reason this system has rebooted in last month is to make myMPD work again. I think the MPD log has recycled since the problem occurred (was probably last night, it is unpredicatble). So seems like no errors in there. When the socket drops out MPD still is happy, the paylist continues to play. Only myMPD doesn't work after that - but MPC does work. |
|
|
Some lines from an earlier log, in an earlier post in this thread : Can that that exception ☝ be part of the problem ? |
|
Does restarting that socket unit fix it? systemctl restart mpd.socketSince logs were truncated, check them again (for the socket unit) once you face the issue. The inotify error is unrelated. This is a kernel feature to monitor file changes in a directory, used here to check for changes in the music directory. Probably one of the files has an invalid character for this. |
|
|
Hmm, I guess it is an activation socket as well, but still strange that it refuses to start just because its activation service is running already. Please try it like that: systemctl stop mpd
systemctl restart mpd.socket
systemctl start mpd |
Ok. As the socket don't exist now, and only way we know to re-establish it is a system reboot, planning to do restart in next 30mins. As mentioned, the system has been restarted 10-15 times in last month, each restart was done only to make myMPD work again... IF not for this problem, then would have been no restarts. As soon as we detect the problem has happened, I will get the MPD logs. In order to do that I will tell the others "no long play lists, 3 or 4 songs max" . Because, when a long playlist (6+ hours) is loaded the socket can drop out any time and we wouldn't know about it because the music keeps playing. |
|
Ah, seeing the 2nd log entry, I guess it is systemd failing to listen on the socket, since MPD is listening on it already. So as long as MPD does not run yet, systemd listens on the socket, using it as activation socket. I.e. local MPD clients who try to connect through the socket will trigger the MPD start (the same even works for 6600 TCP port). But once MPD was started, of course it must listen on the socket instead, so systemd cannot do that anymore. But once you stop MPD, systemd automatically starts to listen on it again, as activation socket. This is what happened at ls -l /run/mpd |
|
|
Confusing. Please try to reinstall MPD, maybe there is something broken: apt install --reinstall mpd |
ok - working now. Same as like a restart. I will report back if/when it stops running ... usually takes many hours |
|
The problem is back 😥 So each time myMPD changes I need to do |
|
myMPD itself does not touch the MPD socket while installing. Upgrading myMPD could not be the root cause of your problem. |
I think it was this step ☝ that may have caused the problems. The myMPD user before was "mpd". Removing it seems like a big step. It just did all that automatically. Anyway - all that is unrelated. Because now is the next morning here. And, after non use of music overnight, SAME problem confronts me now. That is the socket doesn't exist and therefore myMPD wont work again 😥 Thanks to @MichaIng and his comment earlier in this thread - I will now just do yet another That is FAR better than doing a system reboot each time. BUT it is hardly desirable to be doing As a workaround, this is an improvement over |
|
It seems to be more a DietPi issue or an issue with you individual setup than a myMPD issue. Have you tried to reconfigure myMPD to connect to MPD by IP? Host localhost and port 6600 are the defaults. You can set this in the Connection dialog in myMPD. This does not fix the root cause but it could by a valid workaround for you. |
|
The (obsolete) "mympd" user is unrelated to the "mpd" socket. The warning about changed unit files during APT package upgrades is as well pretty common an unrelated, though could be muted with a However, not a myMPD issue for sure. Not a (general) DietPi issue either. But we need to find out what removes the socket why. Of course a package upgrade might be indirectly causing this, or also the systemd reload: ls -l /run/mpd/socket
systemctl daemon-reload
ls -l /run/mpd/socket
apt install --reinstall mympd
ls -l /run/mpd/socketIf the socket is missing after one step, check logs again: journalctl -e -u mpd -u mpd.socket
If not, maybe setup some loop check regularly check for the socket and store a timestamp once it is missing? So we check see apt install inotify-tools
inotifywatch /run/mpd/sockietProbably requires some CLI options, I'll have a look tonight: https://manpages.debian.org/inotifywatch |
|
Closing at is now myMPD issue. |
MyMPD runs great, from all web browsers on multiple devices (windows, iOS, etc) for "a while". By that I mean there is no specific pattern of how long it takes. It can be anywhere from a couple hours to a couple days. But then MyMPD stops running, even though MPD keeps running evidenced by fact that the music keeps playing until the queue is exhausted.
After this happens ALL web clients, on all devices, will see the red (!) message:
MPD connection error: No such file or directoryflashing up every few seconds in the bottom right corner of the screen. And red (!) message:MPD disconnectedelsewhere on the screen.On the DietPi machine the myMPD service shows:
Steps to reproduce the behavior:
Happens every single time - never takes longer than a day and a half.
Expected behavior
Runs forever without MPD becoming disconnected,
Screenshots
This from Windows , Firefox, bottom corner of Browser after a screen reload :
Some things tried
None of these make any difference. The problem just keeps on going exactly the same.
Something that works every single time to fix it
sudo reboot nowOf course that is impractical - but it is the only thing I have found that works. Some webpages are hosted on my machine, and also other services so that I cannot just be rebooting it each day (because the music menus stopped responding). After reboot the status shows as follows:
Even if there were some other way I could reload it , without rebooting the whole system, I'd be happy to do that... Like some way to reset a problematic socket ?? or mem leak or buffer overrun ?? I have no idea the cause 🤷🏻♂️
The text was updated successfully, but these errors were encountered: