-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error parsing status when playing DSD files #38
Comments
My bad, I was using So you can ignore the part that concerns matching against The result from probing MPD directly:
I'll have a look at the status parser later, but the And still I don't get it, why the next call to |
Investigating why the call to The first two calls to After those two I start getting Can you test it yourself? Play some DSD and run the following: use mpd::Idle;
fn main() {
let mut mpc = mpd::Client::connect("127.0.0.1:6600").unwrap();
for _ in 0..5 {
if let Err(e) = mpc.status() {
eprintln!("status error: {:?}", e);
}
// Do something
std::thread::sleep(std::time::Duration::from_millis(100));
let result = mpc.wait(&[mpd::Subsystem::Player]);
eprintln!("idle result: {:?}", result);
}
} I get:
|
Hi, I had a look at the parser and came up with the following which works for me: impl FromStr for AudioFormat {
type Err = ParseError;
fn from_str(s: &str) -> Result<AudioFormat, ParseError> {
let mut dsd = false;
let mut it = s.split(':');
let rate = it.next().ok_or(ParseError::NoRate).and_then(|v| {
if v.starts_with("dsd") {
dsd = true;
v.trim_start_matches("dsd").parse::<u32>().map(|v| v * 44100 / 8)
} else {
v.parse()
}
.map_err(ParseError::BadRate)
})?;
let bits = if dsd {
1
} else {
it.next().ok_or(ParseError::NoBits).and_then(|v| match v {
"f" => Ok(0),
"dsd" => Ok(1),
_ => v.parse().map_err(ParseError::BadBits),
})?
};
let chans = it
.next()
.ok_or(ParseError::NoChans)
.and_then(|v| v.parse().map_err(ParseError::BadChans))?;
Ok(AudioFormat { rate, bits, chans })
}
} I'm new to Rust so I've no idea if it's idiomatic or silly, or whatever, but that's the gist and it works. I found the info in the MPD user manual, it was missing from the protocol specs, here: Anyway, I've still no clue why the connection breaks down on parse error, haven't looked at it. Any idea? |
I've found these relevant bits in the MPD code base and I've put them together in a gist so I stop cluttering this feed with overly long snippets: https://gist.github.com/zhelezov/585e0dd20cce521f16cd46da00fa3f68 Basically Note that floating point PCM signal is defined with 32 bit resolution, not zero. Zero is defined as |
Not really sure where this problem comes from but I'll try my best to explain.
I've got a basic loop that idles in blocking mode waiting for
Subsystem::Player
events, matchesStatus.state
and sets the cover on song change, or unsets it if stopped. It all goes well with other types of files, but if I start playing a DSF file I have a surge of player events andStatus.state
is alwaysState::Stop
. Meanwhile CPU usage goes sky high while looping through those events. Is this possibly an issue with MPD itself? How can I provide more info? Any way to clear the idle events queue?Meanwhile
mpc
correctly reports state asplaying
Edit: I asked if I can clear the events queue because even if I change the song to a known working one, say FLAC, MP3, whatever, I continue getting the accumulated events and state continues being matched to
State::Stop
.The text was updated successfully, but these errors were encountered: