macmpi

FWIW, one trick to check connection status is to check [`/sys/class/udc/*/current_speed`](https://stackoverflow.com/questions/73404932/how-to-detect-disconnection-of-usb0-device-usb-gadget-aka-g-ether/77487456#77487456) for relevant port: it reports `UNKNOWN` when disconnected.

Also noticed that _repeat_ status is changed (i.e. not restored) after play single file. If it was ON before, it becomes OFF after.

Thanks for the quick fix: works a treat! Beside _repeat_ & _consume_, I assume _random_ & _single_ are left untouched too (did not check)?

Hi, There still seem there are some erratic commands sequence management happening. I can reproduce it with a mpd server having a playlist of internet radio streams (repeat on, random...

Yes indeed. Thanks Note, entries to queue are very long (infinite) in case of radio streams, so no chance they go to next without explicit mpc command interventions.

Hi. Did you have a chance to replicate the issue, or do you need some more info? I noticed the volume fix in the meantime, which was indeed another issue...

Thanks for feedback. Actually my server app can be installed on any platform, and I also made some tests on x86 PCs. There may be a specific issue when using...

Yes possibly. Do/can you protect those playlist manipulations & command queuing from eventual other concurrent MPD clients (may not be other Maximum MPD instances) which may intervene at any time...

> 1. When an autoplay song has completed and is removed from the queue Wouldn't temporarily setting `consume on` (and restoring after) achieve the same thing? Though it might be...

seems like MPD will provide a ["one-shot" consume mode](https://github.com/MusicPlayerDaemon/MPD/blob/master/NEWS#L17) with v0.24: it may ease things... (relevant [merge](https://github.com/MusicPlayerDaemon/MPD/commit/512cd7b0dea47883e54245122171a0178678e178))