[arch-general] [mpd+ncmpcpp] mpd hangs when manually moving forward on track, or to nex track

[David Runge]

Hey Javier,

On 2017-03-26 20:22:58 (-0600), Javier Vasquez via arch-general wrote:
> Hi all,
> 
> If someone is familiar with mpd (user, non root) + ncmpcpp on Arch,
> perhaps can help me out...
> 
> Whenever I move forward/backward on the same playing track (f/b), mpd
> just hangs, usually so hard, that mpd needs to be restarted to do
> anything.  A workaround is to pause the track, and then move
> forward/backward, and then play again, most of the time that works...
> 
> When playing a track, and then moving to next/prior track (>/<), then
> mpd hangs.  To get it back alive, it's enough to stop mpd (s), and
> start any track (enter).  The pause work around for moving
> forward/backward on the same track doesn't work, mpd keeps hanging,
> but stopping mpd (s), and starting any track (enter) works.  Stopping
> mpd (s), to move to the next track as a work around doesn't work,
> given there's no current track playing, therefore mpd can find the
> next...
> 
> So it's sort of weird that moving around where to play mpd, kinds of
> makes it hang...
> 
> BTW, I have 2 mpd outputs, the pulse output but also a visual fifo,
> however by keeping only the pulse audio doesn't help, so It's not
> related to the visual fifo...
I basically have the same setup (all latest packages), but I'm not
experiencing your issues.  I'm using a custom service file [1] though, as I
sometimes have several mpd instances on different machines, that I like
to be able to use with pulseaudio.

Something I could think of related to your issue might be your
harddrive and machine (obviously).
Where do the files reside, that you want to play? What kind of hardware
are you using? Is it slow (e.g. connected through usb1, etc)?
You could use tools such as iotop [2] to see whether mpd creates crazy
amounts of I/O for your system (or maybe by proxy due to a slow drive).
Also check htop [3] while you try to go forwards/backwards.
I'm quite sure you'll see something spike.

After all, I don't think it's the software, but something hardware
related.

Best,
David


[1] https://git.sleepmap.de/software/uenv.git/about/
[2] https://www.archlinux.org/packages/community/any/iotop/
[3] https://www.archlinux.org/packages/extra/x86_64/htop/

-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20170327/bf09bb80/attachment-0001.asc>