Skip to content
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

Persist False value for defeats_cache correctly #98

Merged
merged 1 commit into from
Jan 1, 2017
Merged

Persist False value for defeats_cache correctly #98

merged 1 commit into from
Jan 1, 2017

Conversation

ribbons
Copy link
Contributor

@ribbons ribbons commented Dec 31, 2016

If cdparanoia can't work around the audio caching of a drive, defeats_cache = False is written to the config. However, when it is read back the string 'False' ends up being converted to True (as it is not an empty string).

This PR corrects the behaviour when reading the value back and adds tests to make sure that both True and False can be correctly retrieved from the config.

What I'm not sure about is the impact of this bug - does the incorrectly retrieved value have an impact on rips completed? I wonder why it didn't get noticed before (unless I'm reading git blame wrong, it looks like it might have been in morituri since Dec 2012) - is it unusual for cdparanoia to be unable to work around the audio caching behaviour of a drive?

If cdparanoia can't work around the audio caching of a drive,
defeats_cache = False is written to the config.  However, when it is
read back the string 'False' ends up being converted to True (as it is
not an empty string).

This corrects the behaviour when reading the value back and adds tests
to make sure that both True and False can be correctly retrieved from
the config.
@ribbons ribbons changed the title Persist False value for defeat_cache correctly Persist False value for defeats_cache correctly Jan 1, 2017
@JoeLametta
Copy link
Collaborator

JoeLametta commented Jan 1, 2017

Good catch!

What I'm not sure about is the impact of this bug - does the incorrectly retrieved value have an impact on rips completed? I wonder why it didn't get noticed before (unless I'm reading git blame wrong, it looks like it might have been in morituri since Dec 2012) - is it unusual for cdparanoia to be unable to work around the audio caching behaviour of a drive?

I think the only thing impacted by this bug (as it looks like a mistake to me) is the status reporting (log and stdout messages).

Thanks for the PR.

@JoeLametta JoeLametta merged commit 17021a6 into whipper-team:master Jan 1, 2017
@ribbons ribbons deleted the defeat-cache-config branch January 1, 2017 18:57
@ribbons
Copy link
Contributor Author

ribbons commented Jan 1, 2017

Great - thanks. Glad it didn't have any effect on completed rips.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants