--all command with --no-accept-gaps not failing gappy sequences #362
Comments
|
I understand that this is not what is expected, so I'll change the behavior to something like that:
|
|
Thanks Jérôme!
Sorry for wasting time, I twigged this today and was waiting for gappy sequence to test again. Thank you for confirming.
Happy to close this!
… On 4 Feb 2022, at 18:35, Jérôme Martinez ***@***.***> wrote:
--no-accept-gaps currently provides a warning and a question to the user if it is wished, and the -y automates the answer "yes" (-n would reject the processing).
I understand that this is not what is expected, so I'll change the behavior to something like that:
if --no-accept-gaps, it is rejected,
if --accept-gaps, it is accepted,
if --ask-accept-gaps (which would be the default), question to the user or obey -y / -n.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.
|
Don't, I think it is relevant to avoid such surprise. Developers may have an idea in mind which makes sense to them but does not make sense to users, and a tool is for users o they have priority, so here current behavior needs to be changed if there is a better method. If the proposal makes sense to users, I'll try to implement some options this way. |
|
Just an idea, as I know you're busy. Would it be better perhaps to default to '--no-accept-gaps' from the '--all' command? Interested to hear from other users, but after speaking with colleagues here I know there was interest in RAWcooked failing gaps in sequences from business as usual workflows, as it may indicate fault in scanning or copying that we need to know about. At present we have three servers processing in house scans where we definitely want gaps to fail an encoding, and one server processing externally supplied legacy scans from LTO tape that frequently suffer from gaps. |
|
I’m a bit torn on this one. I’m leaning towards Joanna’s suggestion, as I’d
imagine most gaps would indicate an error? I’m trying to think of an
example where a gap is preferred and expected.
K
…On Mon 7 Feb 2022 at 12:27, Joanna White ***@***.***> wrote:
Just an idea, as I know you're busy and this may be time consuming. Would
it be better perhaps to remove '--accept-gaps' from the all command?
Interested to hear from other users, but after speaking with colleagues
here I know there was interest in RAWcooked failing gaps in sequences from
business as usual workflows, as it may indicate fault in scanning or
copying that we need to know about.
At present we have three servers processing in house scans where we
definitely want gaps to fail an encoding, and one server processing
externally supplied legacy scans from LTO tape that frequently suffer from
gaps.
—
Reply to this email directly, view it on GitHub
<#362 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAITFPUZL7PJ3TEREXO3RWTUZ63BTANCNFSM5NJJWOHA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hi there,
A colleague reported successful encoding of a sequence with a gap in it today, despite the use of the --no-accept-gaps flag. I may have misunderstood proper use of this flag so grateful for feedback. Details below, and I'm happy to supply the complete log if needed.
Using RAWcooked v21.09, command used within shell script was formatted:
rawcooked -y --all --no-accept-gaps -s 9000000 ${DPX_PATH}{} -o ${MKV_DEST}mkv_cooked/{}.mkv &>> ${MKV_DEST}mkv_cooked/{}.mkv.txtThis is the warning received for the missing dpx before encoding started but after first analysis completed:
Warning: incoherent file names (gap in file names). N_246024_2_01of01/2048x1556/Scan01/R01of01/N_246024.95791.dpxEncoding was from RAWcooked supplied concat, and passed closing analysis.
Thanks very much,
Joanna
The text was updated successfully, but these errors were encountered: