Open digitensions opened 2 years ago
--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:
--no-accept-gaps
, it is rejected, --accept-gaps
, it is accepted, --ask-accept-gaps
(which would be the default), question to the user or obey -y
/ -n
.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.
Happy to close this!
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. Thank you!
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 https://github.com/MediaArea/RAWcooked/issues/362#issuecomment-1031413336, 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.txt
This 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.dpx
Encoding was from RAWcooked supplied concat, and passed closing analysis.
Thanks very much, Joanna