read-toc progress information

[anarcat]

the first stage of the rip is the cdrdao read-toc command which takes a few minutes to run here. it provides some output yet that is somewhat silenced by whipper and there's zero information something is going on.

it would be nice to show that output to the user to reassure them the process is not hung.

[anarcat]

i looked at the source and it seems this is deliberate:

https://github.com/JoeLametta/whipper/blob/cfcbfd56239d3c0c99ae029e40d8de6c3abdb6ce/whipper/program/cdrdao.py#L29-L42

it seems one of the reason the output is silenced is to handle gracefully a missing drive, but I would hope there are other ways of doing that. for example, we could loop over the output lines and parse that error message if present, while still keeping the output sane. another would be to duplicate the file descriptor to stderr and the pipe.

[JoeLametta]

Thanks for the issue report!
Will investigate whether not silencing cdrdao is the right way or if there's a better solution (as soon as I have enough time).

@MerlijnWajer, @RecursiveForest, @Freso Any suggestions about this?

Partially related to #106.

[Freso]

I'd say that it may make sense to show something (spinning something? could a meaningful progress indicator be added?), but maybe not the raw cdrdao output… Unless WHIPPER_DEBUG or a verbose flag is set.

[MerlijnWajer]

Can you see if you get any usable progress output by cdrdao? In my experience it can be reading a disk for minutes, and show almost no progress. It'd be good to first determine if it can show (sensible) progress.

[anarcat]

On 2018-10-10 09:06:34, Merlijn Wajer wrote: Can you see if you get any usable progress output by cdrdao? In my experience it can be reading a disk for minutes, and show almost no progress. It'd be good to first determine if it can show (sensible) progress.

it does show progress when it parses each track one by one. but it's true it can also get stuck before that.

[jtl999]

I forked whipper and added a feature to display the contents of the "Reading TOC" stage after it's completed, and if I can figure out how to multithread said stage so I can asynchronously display the raw output while it's running I'd be willing to add a flag for it.

[anarcat]

you mean 6d74686 ?

[jtl999]

Yes, but I'm not done yet.

[jtl999]

@Freso suggested I elaborate more of the comment I made on #320 here.

I finally figured out how to run the cdrdao process as a Task, which means I can parse the output asynchronously. Now the question is how should I parse and display the output to the user? I was thinking of displaying a readable version of the CD TOC (maybe just an excerpt of the output from cdrdao) and then after it's done reading each track printing Track %d read, found %d Q sub-channels with CRC errors.

[jtl999]

Made some more progress.

Anyone have some thoughts?

Using configured read offset 6
Checking device /dev/sr0
Track 1 finished, found 10 Q sub-channels with CRC errors
Track 2 finished, found 11 Q sub-channels with CRC errors
Track 3 finished, found 6 Q sub-channels with CRC errors
Track 4 finished, found 8 Q sub-channels with CRC errors
Track 5 finished, found 6 Q sub-channels with CRC errors