how to capture with dvrescue CLI and rewind-count

[Elaci0]

I wanted to capture about 30 miniDV tapes and I am (still) trying to find a nice-smooth way for doing it.
I'm using an old macmini 2010 with some hardware improvement and Monterey (tried High Sierra, very fast, but dvrescue did not play well) connected to a miniDV Sony camera via firewire.
At the moment dvrescue's project seems to be the all-in-one helper to me, at least for obtaining a clean capture, but I am "fighting" for three weeks trying to understand how it works and why it often crashes (the GUI, the CLI, on HighSierra, on Monterey, on Ventura)

I find the "retake" feature interesting but I don't know if/how it works. Using the example at the documentation dvrescue device://0x0x80458280022265 -y --rewind-count 3 -m filename.dv -m - | ffplay -

• what the -m - stands for? the documentation says it merges all retries and I GUESS its piping the result to ffplay, but I am not sure. I tried to remove the | ffplay - but I get garbage on screen. Anyhow I don't get a final filename.dv with all merged frames. Should I pipe this to something else?
• where is the "-y" switch coming from? is it a short for something?
• using only the "-y --rewind-count 3 -m filename.dv" it sometimes capture until the end of the tape but what I get is a very short "filename.dv" and hundreds of "filename.dv.dvrescue.takeN.framesNUMBER-NUMBER.dv" files. What should I do with them?
• I don't know if the XML output is needed for something. If I add the -x filename.xml option I don't see anything on stdout
  Anyhow, I found that the simpler dvrescue device://0 -v 9 -m filename.dv works fine and I usually, not often, get a file from the miniDV and a lot of informations on screen and at the moment I am capturing that way.

I whish I could ask other questions about how to use dvrescue and all its switches but I don't know if "issues@github" is the right place. Do you have a sort of forum?

alessio

[dericed]

These are all good questions.

• -m is the merge output but even if there's only one input the output is still consider merged (just against no alternatives) so -m for dvrescue is similar to what -o (for an output) would be in other apps. Still it's difficult to get the right alignment between multiple inputs to merge them so it's a rather experimental feature that sometimes is completely amazing and sometimes produces weird results.
• Hmm, I see that -y is undocumented. IIRC it means to answer 'yes' to any subsequent prompt but i can't at the moment remember if it ended up in the final code or not. ping @JeromeMartinez
• The presence of the "filename.dv.dvrescue.takeN.framesNUMBER-NUMBER.dv" is mostly for debugging. If the merged output is good it's okay to trash them. They are basically the non-unique, rejected sequences of frames. If they are there it's because a better set of frames was selected and your seeing what's left "on the cutting room floor" so to say.
• The presence of the 'xml' helps the analysis part of the gui plot how the capture went and the xml helps the packaging process in wrapping the file. For a lot of dvrescue processes, if the xml doesn't exist, it will make it so that it has that knowledge to continue.

Also, YES, issue tracker IS the right place to ask all this. Just be patient as this is, at the moment, an all volunteer project, but we can't help it, we still love DV. If you're up to it, feel welcome to contribute documentation.

[Elaci0]

Hello, thank you for your answers.
Ah-ha, so "-y" it's useful, e.g., for auto-overwrite filenames in case of scripting.
I understand the intent of "-m" switch but I don't understand the usage of "-m -" (with a dash at the end) before the "| ffplay -". The documentation says that "-m -" merges all the retakes (if I understood correctly) but I don't get where all these merges goes: the final output is a very short filename.dv. Shorter in terms of space and time against the whole file I would capture without any retakes.

The presence of the "filename.dv.dvrescue.takeN.framesNUMBER-NUMBER.dv" is mostly for debugging. If the merged output is good it's okay to trash them.

Does it mean that these hundreds of frames could not be merged at all and this is the reason why I get a short final filename.dv? This is bad :( Maybe a DVcamera is not the right device for retaking frames with error.
I see that at the end of capture from 4 different tapes I always get more or less this output:

105810 frames in total.

How frames are merged:
 88133 =  83.2936% of frames are recovered from full frames.
    26 =   0.0246% of frames remain with errors.
 17651 =  16.6818% of frames are still missing.

Usage of input files:
158686200 =  83.3182% of blocks from file 0     used.

Input files summary:
File 0:  31777389 =  16.6847% of blocks have errors, in  17677 =  16.7064% of frames

Result:
         31777389 =  16.6847% of blocks have errors, in  17677 =  16.7064% of frames

I don't know if with these values I am just wasting time trying to capture those old tapes.
Thank you
alessio