That gdb catch is probably normal though — I’m guessing that the client side closed the connection before mt-daapd did, and that’s why the sigpipe.
sigpipe should be ignored, though, so except for the fact that it’s running under gdb, it would keep running.
I’ve been stressing this thing by beating on it while playing music, while attached to a gdb session, and I’m picking some stuff up, but not the thread status race, which is the breakage everyone is probably seeing, I think.
I’m going to keep banging away on it until I find everything. 🙂