RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY

[Atak_Snajpera]

Is it normal that x264 very slow is slower than x265 default?

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

[ReinerSchweinlin]

Originally Posted by Atak_Snajpera

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]

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]

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

[Pauly Dunne]

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/tiuax...eview.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]

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.

[Pauly Dunne]

Originally Posted by Atak_Snajpera

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]

Originally Posted by Pauly Dunne

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

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

[StainlessS]

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

[GZZ]

Originally Posted by StainlessS

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]

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

[Pauly Dunne]

Originally Posted by Atak_Snajpera

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...

And the sizing / re-sizing issue ??

[Pauly Dunne]

Originally Posted by StainlessS

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]

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 ].

[Pauly Dunne]

Originally Posted by StainlessS

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

[Pauly Dunne]

Originally Posted by Atak_Snajpera

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/6fjm8...shots.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]

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?

[Pauly Dunne]

Originally Posted by GZZ

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?

Yep, I've been getting a few of those, myself....

It just shows how random the errors are, atm...very hard to diagnose

[Atak_Snajpera]

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...

Originally Posted by Atak_Snajpera

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.

[Pauly Dunne]

Originally Posted by Atak_Snajpera

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