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

Conversation

Projects
None yet
2 participants
@ribbons
Copy link
Contributor

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?

Persist False value for defeat_cache correctly
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

This comment has been minimized.

Copy link
Collaborator

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

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@ribbons ribbons deleted the ribbons:defeat-cache-config branch Jan 1, 2017

@ribbons

This comment has been minimized.

Copy link
Contributor Author

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
You can’t perform that action at this time.