Closed kuku5hka closed 6 years ago
How are you defining multiple progress entries? If you're duplicating the keys, this actually isn't allowed in JSON - you should define the value as an array instead, e.g "progress": ["tcp", "stdout"],
Yeah, --progress log
is broken in the current version (ref #23); I'm hoping to update the release soon.
You can output the progress to a file via command line redirection (e.g. the >
operator).
ah, thanks for the tip, i guess i should get a bit into some json studies
..oh, witnessed another strange issue: with default skip-errors my internet went down for a bit and then came back. and nyuu reposted the whole thing even verified articles. weird. didn't tried to reproduce it, changed it to "skip-errors connect-fail": true, - hopefully it won't come back cheers
JSON, unfortunately, isn't the most user friendly format to edit. It's convenient to use from Javascript though.
The reposting issue sounds weird. Are you re-running Nyuu? Nyuu has no resume functionality, so if you run it again, it will start from the beginning.
--skip-errors connect-fail
is likely not what you want. It just drops connections that it couldn't get working, and continues going with the ones that it could get working (by default, if a connection gets such a fatal error, the whole uploading process stops). If this causes all connections to be dropped, then uploading obviously stops.
Perhaps try increasing --connect-retries
to some large number so that it keeps retrying through the internet dropout until it comes back online.
yeah, --connect-retries works better, thanks. redirecting output with > don't really help, progress indicator indeed gets written to file while all meaningful information (posting/checking details) still gets its output to a console. what would be really helpful is to be able to output summary at the end of a job in a format that is on web server, like Total articles: 3 Articles read: 3 (100.00%) Articles posted: 3 (100.00%) Articles checked: 0 (0.00%) Errors skipped: 0 across 0 article(s) Upload Rate (raw|real): 1553.55 KiB/s | 20.79 KiB/s ...right now the only way to check if all went well as it seems is with errorlevel, i'm tweaking my .bat to output it after each job.. My global goal is to make nyuu settings rock solid so it will keep trying to upload and check no matter what and to be sure that at the end of the job everything was posted and checked fine.. As for weird reposting issue - idk, i'll probably try to reproduce it at some point but so far during "normal" operation couldn't get the effect again luckily
tried to make "log" more informative with sed.. while doing it, catched that sometimes progress can't update in time to reflect last change in status: last message Posted: 2+1/3 (83.33%) @ 41.41 KiB/s (raw: 1570.1 KiB/s) ETA 00:06
while in reality all 3 articles were checked
[2018-01-05 20:38:56.797][DBG ] NNTP connection ready [2018-01-05 20:38:56.890][DBG ] NNTP connection established [2018-01-05 20:38:57.023][DBG ] Post check successful for article [2018-01-05 20:38:57.086][DBG ] Post check successful for article [2018-01-05 20:38:57.133][DBG ] NNTP connection authenticated [2018-01-05 20:38:57.133][DBG ] NNTP connection ready [2018-01-05 20:38:57.628][DBG ] Post check successful for article [2018-01-05 20:38:57.628][DBG ] All article(s) processed [2018-01-05 20:38:57.628][DBG ] Closing connection... [2018-01-05 20:38:57.628][DBG ] Closing connection... [2018-01-05 20:38:57.628][DBG ] Closing connection... [2018-01-05 20:38:57.628][DBG ] Closing connection... [2018-01-05 20:38:57.737][DBG ] NNTP connection closed [2018-01-05 20:38:57.737][DBG ] NNTP connection closed [2018-01-05 20:38:57.737][DBG ] NNTP connection closed [2018-01-05 20:38:59.041][DBG ] NNTP connection closed [2018-01-05 20:38:59.041][INFO] Finished uploading 1283.61 KiB in
...not a real problem on big stuff for me, only saw it on small test job when nyuu was uber quick to quit on big stuff it goes ok 27589+12/27601 (99.98%) @ 0 B/s (raw: 9530.08 KiB/s) ETA 27600+1/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA - 27601/27601 (100.00%) @ 0 B/s (raw: 9530.08 KiB/s) ETA -
redirecting output with > don't really help
Make sure you're redirecting stderr (2\>
) instead of stdout (\>
). (alternatively, you can use --progress stdout
to get output sent to stdout)
what would be really helpful is to be able to output summary at the end of a job in a format that is on web server
In a way, the information is already there (in a less verbose way):
Were you looking to do something in particular with the output?
right now the only way to check if all went well as it seems is with errorlevel
That's actually the intention - the errorlevel (exit code) reports back the status of the run.
tried to make "log" more informative with sed.. while doing it, catched that sometimes progress can't update in time to reflect last change in status: last message
Yeah, because usually the end status just overwrites the progress indicator.
However, I can see the benefit in forcing the final progress be written before finishing if you're redirecting the output elsewhere, so I've made a change to do just that - hopefully that does what you need.
thanks for stderr 2> tip, but for the moment i'll hold on to "--progress stdoutx >" - this way i'm able to more or less see what is going on directly in console + receive information about amount of posted/verified articles in file. as for forcing final progress to be written, sorry, can't test it yet, but i'm afraid i'll have to open another issue topic :)
as for output - well, would be nice to have exact information that all articles were posted, verified and written no nzb successfully Total articles: 20420 Articles read: 9523 (46.64%) Articles posted: 9477 (46.41%) Articles checked: 8963 (43.89%) Errors skipped: 0 across 0 article(s) Upload Rate (raw|real): 10.53 MiB/s | 10.12 MiB/s this form from web seems very nice so it there would be a possibilty to write down its last state - it would be great
Fair enough, I've made a change so that it'll display exactly that if stdoutx/stderrx progress is specified. I think the 'compact' form of the data is fine usually, but if you're looking for more info, I suppose being more verbose is useful. Thanks for the suggestion.
i'm under windows if it makes any difference multiple progress entries within json config don't seem to work, only last entry is being processed. in cmd it works fine another issue - can't seem to get --progess log to work --progress log, --progress log:30 and --progress log:30s are all giving me smth like
nexe.js:815 progress.push({type: 'log', interval: parseTime(arg) || 60}); ^
ReferenceError: parseTime is not defined at nexe.js:815:43 at Array.forEach (native) at Object. (nexe.js:808:16)
at Object.__dirname.2.../ (nexe.js:1419:4)
at s (nexe.js:1:316)
at e (nexe.js:1:487)
at nexe.js:1:505
at NativeModule.compile (node.js:1036:7)
at Function.NativeModule.require (node.js:979:18)
at Function.Module._load (module.js:285:25)
ps would be nice to be able to specify log file location too whenever it will be back in action
pps many thanks!