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

Whipper attempts to rip with no CD inserted #81

Closed
BoBeR182 opened this issue Dec 2, 2016 · 6 comments
Closed

Whipper attempts to rip with no CD inserted #81

BoBeR182 opened this issue Dec 2, 2016 · 6 comments
Labels
Accepted Accepted issue on our roadmap Bug Generic bug: can be used together with more specific labels

Comments

@BoBeR182
Copy link

BoBeR182 commented Dec 2, 2016

Expected result:
Error message saying empty drive and whipper ejecting it for me.

What happened:

whipper cd rip
Using configured read offset 6
Checking device /dev/sr0
WARNING:root:cdrdao read-toc failed: return code is non-zero: 1
Traceback (most recent call last):
  File "/usr/sbin/whipper", line 11, in <module>
    load_entry_point('whipper==0.4.0', 'console_scripts', 'whipper')()
  File "/usr/lib/python2.7/site-packages/morituri/rip/main.py", line 27, in main
    ret = c.parse(sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/morituri/rip/main.py", line 94, in parse
    logcommand.LogCommand.parse(self, argv)
  File "/usr/lib/python2.7/site-packages/morituri/common/logcommand.py", line 62, in parse
    command.Command.parse(self, argv)
  File "/usr/lib/python2.7/site-packages/morituri/extern/command/command.py", line 401, in parse
    return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/site-packages/morituri/common/logcommand.py", line 62, in parse
    command.Command.parse(self, argv)
  File "/usr/lib/python2.7/site-packages/morituri/extern/command/command.py", line 401, in parse
    return self.subCommands[command].parse(args[1:])
  File "/usr/lib/python2.7/site-packages/morituri/common/logcommand.py", line 62, in parse
    command.Command.parse(self, argv)
  File "/usr/lib/python2.7/site-packages/morituri/extern/command/command.py", line 363, in parse
    ret = self.do(args)
  File "/usr/lib/python2.7/site-packages/morituri/rip/cd.py", line 86, in do
    self.device)
  File "/usr/lib/python2.7/site-packages/morituri/common/program.py", line 136, in getFastToc
    t = cdrdao.ReadTOCTask(device)
  File "/usr/lib/python2.7/site-packages/morituri/program/cdrdao.py", line 61, in ReadTOCTask
    return read_toc(device, fast_toc=True)
  File "/usr/lib/python2.7/site-packages/morituri/program/cdrdao.py", line 33, in read_toc
    raise e
subprocess.CalledProcessError: Command '['cdrdao', 'read-toc', '--fast-toc', '--device', '/dev/sr0', u'/tmp/tmph89lFh.cdrdao.read-toc.whipper']' returned non-zero exit status 1
@JoeLametta
Copy link
Collaborator

Expected result:
Error message saying empty drive and whipper ejecting it for me.

Thanks for the bug report.

The regression was introduced with d7f8557.
The way it's currently implemented is that cdrdao.py just checks for a non-zero exit status, otherwise it throws the exception you've seen.

@RecursiveForest Do you know if there is a simple way to improve this?

@RecursiveForest
Copy link
Contributor

My apologies, missed this until just now. There is a simple fix for this I can implement shortly.

@RecursiveForest
Copy link
Contributor

https://github.com/RecursiveForest/whipper/tree/cdrdao-nodisc should fix this (it doesn't eject, though, although we could if we wanted to after I look around some more to understand when whipper does/does not eject), but it depends on the argparse & logging PR, so I'm waiting until that's merged to PR this. By then I may have a comprehensive solution to when to eject or not.

@RecursiveForest
Copy link
Contributor

RecursiveForest commented Dec 19, 2016

This raises an important question I'd like other people to weigh in on: When should whipper eject the CD tray? Right now it ejects only during whipper cd rip: either on successful rip or if the metadata can't be retrieved.

I can see a strong case for ejecting after a successful rip, but if the metadata can't be retrieved (or any other error occurs that can be solved without replacing the CD, in this case by passing -U...) I don't see ejecting as warranted. I do see this case of if there is no (detectable) CD in the drive (or the drive is open), for calling eject. There are probably others. What do you think?

@ArchangeGabriel
Copy link

@RecursiveForest I totally agree with you on all those points. ;)

@RecursiveForest
Copy link
Contributor

#93

@JoeLametta JoeLametta added Bug Generic bug: can be used together with more specific labels Accepted Accepted issue on our roadmap and removed enhancement labels Nov 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Bug Generic bug: can be used together with more specific labels
Projects
None yet
Development

No branches or pull requests

4 participants