RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY [Archive] - Page 362

guest

19th December 2019, 01:08

I also had a failure in encoding where the Encoding Client is saying Encoding and the Encoding Server is doing nothing.

Please see below screenshots and log files.

Screenshots
https://pasteboard.co/ILQi7td.png
https://pasteboard.co/ILQijVx.png

Log Files
Command Recieved From Client: http://gofile.me/6GaFo/qjNpDO7o
Command Send To Client: http://gofile.me/6GaFo/WdvkqLJC

I hope it can help identify the issue.

Hey GZZ, I have a sneaking suspicion that your are not using the latest version (not an Auto-update), if you have a look at my screenshot from yesterday, and pay particular attention to the green circled item, and also you should be on at least v1.17.0 of Server.

https://www.mediafire.com/view/br45iwkjg7bvu93/latest_client_screen_%2819-12-19%29.jpg/file

GZZ

19th December 2019, 07:29

Hey GZZ, I have a sneaking suspicion that your are not using the latest version (not an Auto-update), if you have a look at my screenshot from yesterday, and pay particular attention to the green circled item, and also you should be on at least v1.17.0 of Server.

https://www.mediafire.com/view/br45iwkjg7bvu93/latest_client_screen_%2819-12-19%29.jpg/file

I didnt, downloaded the latest, normally i use auto update, but it didnt gave an error (expected it to work, so didnt read log). On latest now, so hopefully it has been fixed, will report back if it fails again.

guest

19th December 2019, 07:34

I didnt, downloaded the latest, normally i use auto update, but it didnt gave an error (expected it to work, so didnt read log). On latest now, so hopefully it has been fixed, will report back if it fails again.

Ah ha...

Yes, if you grab coreV4.7z, I don't think you'll have any more problems...I've been using it all day, and the only hiccups I've had are not related to the most recent problem.

Copy the 3 files onto every RB pc you have...

I'm sure auto updates will be enabled again, soon.

guest

19th December 2019, 07:41

@Pauly Dunne
https://www.mediafire.com/file/6an2rvp7qqn7nvt/CoreV4.7z/file

I hope this solves that issue with ENCODING/IDLE status. Update all encodingserver.exe (version number [v1.17.0] for now is frozen till official release)

Well as I mentioned in my reply to GZZ, I have been using coreV4 all day, no related problems or errors.

The file that gave me that chapter error yesterday, must be full of problems....I DID manage to get it thru RB, and I wanted to run the encoded one thru again, but it just kept throwing up annoying errors, so I'll scrap that one.

The Encoding/Idle problem didn't present itself, either.

So hopefully this all behind us now....

GZZ

19th December 2019, 08:35

Well as I mentioned in my reply to GZZ, I have been using coreV4 all day, no related problems or errors.

The file that gave me that chapter error yesterday, must be full of problems....I DID manage to get it thru RB, and I wanted to run the encoded one thru again, but it just kept throwing up annoying errors, so I'll scrap that one.

The Encoding/Idle problem didn't present itself, either.

So hopefully this all behind us now....

Its been running 8 hour straight on some South Park Episode with the lastest coreV4. I think it manage to reencode 70 episode, so alot of chunks. But then again I didnt have that big issue with previous, so I wont say its ok until it has been doing some more encoding.

guest

19th December 2019, 10:24

Its been running 8 hour straight on some South Park Episode with the lastest coreV4. I think it manage to reencode 70 episode, so alot of chunks. But then again I didnt have that big issue with previous, so I wont say its ok until it has been doing some more encoding.

Well, that's certainly a good start, that's probably more chunks than I did.

ReinerSchweinlin

19th December 2019, 13:55

I had occasional stalls, too... Downloaded Core4, testing now..

jfisher1740

19th December 2019, 14:11

Had an encode stall overnight (same issues) at 83% completed on encodingserver v1.16.0. Updated to v1.17.0 and the encode completed successfully. Have 2 more encodes in process and will report back.

2 4k x265 encodes ran to completion overnight with no issues!

GZZ

19th December 2019, 16:41

I finished the 82 Episode of South Park with no issues, no stalls, no hang and so on. So I would think Core4v is good and stable.

But the issue I posted here is still there. The RipBot application freeze on shutdown after end of encoding. See my post and screenshot: https://forum.doom9.org/showpost.php?p=1893009&postcount=18023

Wishbringer

19th December 2019, 18:56

@Atak_Snajpera:
is you online-updater offline?
get 404 error for http://atak-snajpera.5v.pl/ripbot264update/update.zip
manually only found a "update.zip_"

guest

20th December 2019, 01:03

@Atak_Snajpera:
is you online-updater offline?
get 404 error for http://atak-snajpera.5v.pl/ripbot264update/update.zip
manually only found a "update.zip_"

Hey Wishbringer,

Have you not been following the forum for the past week or so ??

There has been some major "testing" to fix a problem that RB had, and Atak has been posting limited updates, manually.

If you want the latest "fix", please go here,

https://forum.doom9.org/showthread.php?p=1893378#post1893378

OR

https://www.mediafire.com/file/6an2rvp7qqn7nvt/CoreV4.7z/file

and download "CoreV4.7z", and overwrite the files in the RB directory.

I'm sure auto updates will be back online shortly, once Atak is happy with the outcome.

Wishbringer

20th December 2019, 09:15

yep, wasn't here since a month or more.
(vacation an timelines in my job)
Thanks for info.

guest

20th December 2019, 09:34

yep, wasn't here since a month or more.
(vacation an timelines in my job)
Thanks for info.

That long...

OK, well if the version you have is working OK, I wouldn't use the "special" fix's, as it's only to fix the version that came out a week or so ago.

What build are you on ?? (eg:- core version).

Wait 'til auto updates are back, unless you have a problem.

guest

21st December 2019, 11:28

Well, I had a lot of weird problems with a certain server today, it just didn't want to co-operate, so I turned it off, and used another one...

I was using a different client today...any way, not related to the recent problem, I'm sure.

One particularly bizarre happening was at one stage, there was 2 chunks trying to use the same IP/port address, needless to say, one didn't do anything, I had to abort, and have a second go at it, and it didn't do it again.

And one other thing, I had 2 chunks processing very slow, every so often.

And I learn't & used something in RB, that I don't think I've ever used before...

Any way, it was a very hot here today, over 40 Celsius.

Atak_Snajpera

21st December 2019, 12:08

One particularly bizarre happening was at one stage, there was 2 chunks trying to use the same IP/port address, needless to say, one didn't do anything, I had to abort, and have a second go at it, and it didn't do it again.
Screenshot would be more helpful.

guest

21st December 2019, 13:15

Screenshot would be more helpful.

yeah I know but if you can just picture.... two different chunks, the same IP and Port number, one processing, one not. lol

Never seen it before and probably not likely to see it again.

GZZ

21st December 2019, 13:59

Had this issue where it started up a Server on an inactive netcard.

Screenshot
https://imgur.com/JiYGV4M

Atak_Snajpera

21st December 2019, 14:11

Had this issue where it started up a Server on an inactive netcard.

Screenshot
https://imgur.com/JiYGV4M

EncodingServer.exe by default uses first available detected IP [ADAPTER0]. In this case you have to manually specify other ip [ADAPTER1]
https://i.postimg.cc/fLhjg9MN/Untitled-1.png

EncodingServer.exe /ip 192.168.1.102

god_md5

21st December 2019, 17:18

i get this error ,the ts file is HLG hdr format.

C:\>"C:\Users\godmd5\Desktop\RipBot264v1.24.0\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "C:\Temp\RipBot264temp\job3\job3.avs" -strict -1 -f yuv4mpegpipe - | "C:\Users\godmd5\Desktop\RipBot264v1.24.0\tools\x265\x265_x64.exe" --colorprim bt2020 --transfer hlg --colormatrix bt2020nc --pass 1 --bitrate 8192 --stats "C:\Temp\RipBot264temp\job3\job3.stats" --fps 60000/1001 --min-keyint 60 --keyint 600 --frames 146577 --sar 1:1 --profile main10 --output-depth 10 --ctu 32 --no-slow-firstpass --y4m --output NUL -
x265 [error]: invalid argument: transfer = hlg

C:\>"C:\Users\godmd5\Desktop\RipBot264v1.24.0\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "C:\Temp\RipBot264temp\job3\job3.avs" -strict -1 -f yuv4mpegpipe - | "C:\Users\godmd5\Desktop\RipBot264v1.24.0\tools\x265\x265_x64.exe" --colorprim bt2020 --transfer hlg --colormatrix bt2020nc --pass 2 --bitrate 8192 --stats "C:\Temp\RipBot264temp\job3\job3.stats" --fps 60000/1001 --min-keyint 60 --keyint 600 --frames 146577 --sar 1:1 --profile main10 --output-depth 10 --ctu 32 --y4m --output "C:\Temp\RipBot264temp\video.265" -
x265 [error]: invalid argument: transfer = hlg

C:\>"C:\Users\godmd5\Desktop\RipBot264v1.24.0\tools\mkvtoolnix\mkvmerge.exe" -o "C:\Users\godmd5\Desktop\av\TWICE NHK20191021_1080.mkv" --compression 0:none --title "TWICE NHK20191021_1080" --default-duration 0:60000/1001fps "C:\Temp\RipBot264temp\video.265" --compression 0:none --language 0:und --sync 0:0 --aac-is-sbr 0:0 "C:\Temp\RipBot264temp\job3\1_audio_Undetermined.aac"
mkvmerge v35.0.0 ('All The Love In The World') 64-bit
Error: The file 'C:\Temp\RipBot264temp\video.265' could not be opened for reading: open file error.
-------------------------

Elapsed Time: 00h:00m:02s

Atak_Snajpera

21st December 2019, 17:58

Upload source sample because I do not have any file using HLG format.

GZZ

21st December 2019, 20:04

EncodingServer.exe by default uses first available detected IP [ADAPTER0]. In this case you have to manually specify other ip [ADAPTER1]
https://i.postimg.cc/fLhjg9MN/Untitled-1.png

EncodingServer.exe /ip 192.168.1.102

I though it tested if the network card was unplugged (as its not disabled) before using it. I havent seen this error before, so thats was why I reported it. I restarted Encoding Server and it detected the correct network card (no other change) and started encoding.

GZZ

21st December 2019, 20:09

Upload source sample because I do not have any file using HLG format.

Have a look here for HLG samples: https://4kmedia.org/travelxp-4k-hdr-hlg-sample/

guest

22nd December 2019, 01:30

I am sure you're aware that auto updates has been "offline", well, it is online, but it hasn't done anything "normal" since around the 12th.

I've been thinking that it's due to the problems you were fixing, but now that CoreV4 is working well, it would be nice to have it (or the next iteration) as an update, so it can be officially incorporated into RB.

Up 'til recently, we've only been getting this:-

https://www.mediafire.com/file/82pharlkixeem3b/update_log.txt/file

god_md5

22nd December 2019, 04:26

if change to sdr (bt2020 to bt709) it work , but color like Incorrect
,this file play with mpc-hc madvr is Incorrect color ,but smplayer with mpv is ok.

GZZ

22nd December 2019, 07:50

if change to sdr (bt2020 to bt709) it work , but color like Incorrect
,this file play with mpc-hc madvr is Incorrect color ,but smplayer with mpv is ok.

You should post the link you send me in a PM. (Dont know why you send it to me)

ReinerSchweinlin

23rd December 2019, 13:21

While reading up on the discussion about turing hevc encoding vs x264/x265, I encountered the advantage of x264 veryslow mentioned by Atak over here:
https://forum.doom9.org/showthread.php?t=176889

So I started encoding tests with x264 very slow in ripbot.

I noticed, that encoding speed in ripbot differs a lot compared to hybrid:

ripbot (with 20 cores in total, using two xeons, kaby lake i5 and some others)
x264 very slow: 2 hours
x265 default: 1,3 hours

hybrid (only using the i6 Kaby lake with 4 cores)
x264 very slow: 1,1 hours

I am not sure if I am doing something wrong here´... Is it normal that x264 very slow is slower than x265 default?

Atak_Snajpera

23rd December 2019, 14:49

Is it normal that x264 very slow is slower than x265 default?
Short answer...Yes! I get the same results.

ReinerSchweinlin

23rd December 2019, 16:29

Short answer...Yes! I get the same results.

Thank you, that answers one part of my question :)

I just did some more testing...
Hybrid and Handbrake encode almost as fast on the one i5 Kabylake as the whole network with Ripbot. Using the same settings (x264veryslow, no filter, no tune, no audio, simply passing through video..). I assume that there are different versions of x264 under the hood of each program, but this difference is huge. If I look at the encoding server on the i5, I have around 4 fps with ripbot, while hybrid and handbrake get up to 12fps...
What yould be causing this? I remember encoding some 1080p videos a while ago in Ripbot with x264veryslow and I had much faster fps... Running the latest Corev4 you posted above.

GZZ

23rd December 2019, 16:48

RipBot (CoreV4) still hang on end of encode and shutdown is selected.

See new image:
https://imgur.com/krrtpT1
https://imgur.com/sPq1gkv

Encoding server on my second computer shutdown without an issue. I think its an issue in RibBot and not the Encoding Server.

slalom

24th December 2019, 20:18

I've been running the program without the auto-restart button on the servers for a couple of days, and I think it's working better. I can complete stalled chunks without having to restart the job

guest

25th December 2019, 07:47

MERRY CHRISTMAS, everybody...(or is it)

So I discovered an interesting error today, when trying to start a 4K encode.

In the "Size" option, I chose 3840 x 2160, and when I started the job, it came up with the red text msg down the bottom of the screen.

So I backed out, and went back in an did a video preview, and that didn't like a few things, so I have a screen shot and an error message.

https://www.mediafire.com/file/tiuaxmui0dmw3ze/Size_Error_preview.rar/file

Haven't had that happen before....
-------------------------------------------------------------------------------

Now another question that might spark some discussion....IS NUMA all it's cracked up to be, for HEAVY x265 encoding ???

I have NUMA enable on ALL the PC I have that support it (mainly the SMC & TYAN server boards), so I use 2 DE Servers per server, each using the available NUMA 0 & 1, and that seems to load up the CPU's to 100%.

I have one SMC board that has a pair of E5 2690 v1 CPU's, each supports 2 NUMA cores, so to get 100% I run 4 DE Servers, 2 on NUMA 0, and 2 on NUMA 1.....

Most of the time that works a treat, but if I give it a 4K heavy filtered job, they all struggle quite a bit.

I know I'm asking a lot of them, BUT they just seem to hit the wall.

Not sure if this has anything to do with it, but if you sit there and watch all the chunks doing their thing, every so often, one or more will just stop, lose what's it's encoded, and start again....

I'm wondering if going back to no NUMA would make much, if any difference.

There was mention of this here, a little while back, and Googling it brings up some interesting comments on the pro's & con's, especially with x265 encoding.

So I just might try disabling NUMA, and see what it does.

Speaking of x265, I think there might be a newer build available..3.2+22.

Atak_Snajpera

25th December 2019, 10:55

Not sure if this has anything to do with it, but if you sit there and watch all the chunks doing thier thing, every so often, one or more will just stop, lose what's it's encoded, and start again....
Next time when you see this disconnect server from encondingclient and check log in TCP communication tab. This should explain why progress Had been reset. My wild guess is that encoder terminated prematurely ,encodingserver detected that number of encoded frames is not correct and sent ERROR command back to encondingclient.

guest

25th December 2019, 11:31

Next time when you see this disconnect server from encondingclient and check log in TCP communication tab. This should explain why progress Had been reset. My wild guess is that encoder terminated prematurely ,encodingserver detected that number of encoded frames is not correct and sent ERROR command back to encondingclient.

Do you have any ideas why the encoder might terminate prematurely ??

Atak_Snajpera

25th December 2019, 11:36

Do you have any ideas why the encoder might terminate prematurely ??

First check TCP communication log and then we will speculate...

StainlessS

25th December 2019, 21:28

Atak,
Your update at bottom of post 1, is 404.

GZZ

25th December 2019, 22:38

Atak,
Your update at bottom of post 1, is 404.

Update is disabled because of issues in newest update. Will properly be back when fixed and new update is available.

StainlessS

25th December 2019, 22:51

Thanks, not a problem for me, I just clicked on it to see what it was.

guest

26th December 2019, 00:19

First check TCP communication log and then we will speculate...

OK, so that's part of my post answered, do you have an opinion on the NUMA situation ??

Enabled or disable, which is best, that is the question...:o

And the sizing / re-sizing issue ??

guest

26th December 2019, 00:24

Thanks, not a problem for me, I just clicked on it to see what it was.

Yeah, I don't think you're supposed to use that link, it's the link at the top of Post #1 !!!

Do you even use Ripbot264 ???

And were you sober when you posted this ??? (referencing your sig)

StainlessS

26th December 2019, 01:10

guest

26th December 2019, 07:28

Last version of Ripbot264 I have is from 2011 [dont know if I ever tried it, just downed current ver$ prior to that post.]

Yip, stone cold sober[maybe], is limit of 260 chars in sig, and I did not have enough space and so cut it short,
it dont make a whole lot of sense, but who cares, it wern't meant to be serious [Feisty2 was first to question it, and you knows what a pain he is :) ].

Well, it has changed a LOT since then, I can assure you.

And who is this Feisty2 you're referring to ???, never heard of him !!

Maybe you should go back "Over the rainbow", and have a drink :D

guest

26th December 2019, 07:35

First check TCP communication log and then we will speculate...

OK, well, another day, and another day of the same, but different :(

Server's that were working nicely yesterday, were acting up a LOT, and vice versa.

I have lot's of error log's, etc, etc for you to peruse:-

https://www.mediafire.com/file/6fjm8i30r0xcljs/error_logs_%26_screenshots.rar/file

At one point, on yet another Server, it was showing "Starting" for a long time (on the Client), but when I checked the Server, it was well into the encode.

The TCP window had stopped, so I restarted both servers, and away it went.

Random, random, random.

And then to top off the day, the client pc, did something while I was in the other room with the servers, it wouldn't let me open or Maximise the client from the taskbar. so I had to kill it, and hope for the best.

GZZ

26th December 2019, 08:37

I had some problems with a few episode from boardwalk empire that didnt create the info.txt file. I have no idea why it wasnt created. I pulled the getinfo.avs into mediaplayer classic and it created it. I also couldnt recreate the issue by adding the episode again.

Is there no check for the info.txt, as encoding fail with a “file not found: .....\info.txt” closing in 5 sec....

Was just wondering if there could be built in a check and maybe recreate it, if not found?

guest

26th December 2019, 09:56

Atak_Snajpera

26th December 2019, 11:31

At one point, on yet another Server, it was showing "Starting" for a long time (on the Client), but when I checked the Server, it was well into the encode.
Do not abort. Instead wait for encoding server to finish encoding. There is high chance that at the end progress on encondingclient side will immediatelly change to encoded ...

Like I predicted...
Next time when you see this disconnect server from encondingclient and check log in TCP communication tab. This should explain why progress Had been reset. My wild guess is that encoder terminated prematurely ,encodingserver detected that number of encoded frames is not correct and sent ERROR command back to encondingclient.

9085|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9086|CLIENT <- SERVER| OK
9087|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> [17.2%] 247/1434 frames, 0.21 fps, 65993 kbps, eta 1:33:42 ;CHUNCK=13;CPU=82;RAM=77;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9088|CLIENT -> SERVER| OK
9089|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9090|CLIENT <- SERVER| OK
9091|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> [17.2%] 247/1434 frames, 0.21 fps, 65993 kbps, eta 1:33:42 ;CHUNCK=13;CPU=82;RAM=77;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9092|CLIENT -> SERVER| OK
9093|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9094|CLIENT <- SERVER| OK
9095|CLIENT <- SERVER| ENCODING_FINISHED
9096|CLIENT -> SERVER| OK
9097|CLIENT -> SERVER| GET_ENCODING_SUMMARY
9098|CLIENT <- SERVER| OK
9099|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.1.41:1000 -> ERROR;CHUNCK=13;CPU=82;RAM=57;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9100|CLIENT -> SERVER| OK
9101|CLIENT -> SERVER| STANDBY
9102|CLIENT <- SERVER| OK
9103|CLIENT <- SERVER| SERVER_IDLE
9104|CLIENT -> SERVER| OK
9105|CLIENT -> SERVER| ENCODE_CHUNK_13=\\RIING-BIG-XEON\RipBot264temp\job8\Chunks\13.cmd
9106|CLIENT <- SERVER| OK
9107|CLIENT <- SERVER| ENCODING_STARTED
9108|CLIENT -> SERVER| OK
9109|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9110|CLIENT <- SERVER| OK
9111|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> ;CHUNCK=13;CPU=51;RAM=57;DECODER=0;ENCODER=0;OTHER=51;ENCODING_PRIORITY=normal;

Most likely ffmpeg.exe (decoder process) silently terminated prematurely because it couldn't get data from host machine.

guest

26th December 2019, 13:29

Do not abort. Instead wait for encoding server to finish encoding. There is high chance that at the end progress on encondingclient side will immediatelly change to encoded ...

OK, if that happens again, I will wait and see what happens.

Like I predicted...

9085|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9086|CLIENT <- SERVER| OK
9087|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> [17.2%] 247/1434 frames, 0.21 fps, 65993 kbps, eta 1:33:42 ;CHUNCK=13;CPU=82;RAM=77;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9088|CLIENT -> SERVER| OK
9089|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9090|CLIENT <- SERVER| OK
9091|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> [17.2%] 247/1434 frames, 0.21 fps, 65993 kbps, eta 1:33:42 ;CHUNCK=13;CPU=82;RAM=77;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9092|CLIENT -> SERVER| OK
9093|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9094|CLIENT <- SERVER| OK
9095|CLIENT <- SERVER| ENCODING_FINISHED
9096|CLIENT -> SERVER| OK
9097|CLIENT -> SERVER| GET_ENCODING_SUMMARY
9098|CLIENT <- SERVER| OK
9099|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.1.41:1000 -> ERROR;CHUNCK=13;CPU=82;RAM=57;DECODER=33;ENCODER=33;OTHER=16;ENCODING_PRIORITY=normal;
9100|CLIENT -> SERVER| OK
9101|CLIENT -> SERVER| STANDBY
9102|CLIENT <- SERVER| OK
9103|CLIENT <- SERVER| SERVER_IDLE
9104|CLIENT -> SERVER| OK
9105|CLIENT -> SERVER| ENCODE_CHUNK_13=\\RIING-BIG-XEON\RipBot264temp\job8\Chunks\13.cmd
9106|CLIENT <- SERVER| OK
9107|CLIENT <- SERVER| ENCODING_STARTED
9108|CLIENT -> SERVER| OK
9109|CLIENT -> SERVER| GET_ENCODING_PROGRESS;SET_ENCODING_PRIORITY=belownormal;
9110|CLIENT <- SERVER| OK
9111|CLIENT <- SERVER| ENCODING_PROGRESS=192.168.1.41:1000 -> ;CHUNCK=13;CPU=51;RAM=57;DECODER=0;ENCODER=0;OTHER=51;ENCODING_PRIORITY=normal;

Most likely ffmpeg.exe (decoder process) silently terminated prematurely because it couldn't get data from host machine.

OK, long story short...do you think this has been the problem over the last couple of weeks ?

Is that why it's so random ??

Is it a problem at my end, or is it something that you need to dig a little deeper into ??

edit:- I just had a look around, and there appears to be a very new version of ffmpeg..
Build: ffmpeg-20191224-287620f-win64-static