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

[AmaZim20]

Well, I don't care. That's the only version that I trust and works properly for me since long time and I'm happy with it

Originally Posted by AmaZim20

Well, I don't care. That's the only version that I trust and works properly for me since long time and I'm happy with it

I don't know why I'm bothering to reply to this...

ALL you have to do is "customise" your nVidia driver installation package, (with the info I mentioned in a previous post) then download RB from the link provided, and you've got the latest build which has quite a lot of new features (compared to 1.26.0).

You can have it in a separate folder so it won't interfere with what you're using, and once you've got it running, then you can use it as the main.

Entirely up to you.

Good luck.

I am noticing that I'm getting pixelation & glitches in some of my encodes.

The originals are good.

Any ideas ??

[Atak_Snajpera]

Encode again and check if glitches appear again in the same frames. If yes Then encode once again but this time without your fancy filters using cuda and so on.

Originally Posted by Atak_Snajpera

Encode again and check if glitches appear again in the same frames. If yes Then encode once again but this time without your fancy filters using cuda and so on.

Yeah, well that's basically a no brainer, but that takes a lot of time

One thing I did try, as I still had all the chunks, etc, I ran the combine.cmd, and one glitch disappeared, the larger one remained.

I will also try using a different drive for the muxed encodes, maybe there's some problem with the drive I'm using (nVme)

You may be correct with the CUDA based scripts, I don't think CUDA plays well with DE, and using differently spec'd GPU's, in each PC.

It might be OK using DE on a single PC, and just the one nVidia GPU.

What's this ???

Don't think I've seen this before, it is a little random, but once it's shown up, the chunks just keep trying to restart, to no avail

Basically, need to reboot the PC to rectify.

[LigH]

My guess: Console output may get transmitted in blocks of a fixed size instead of line-per-line (probably cached output). So when a thread locks up, the communication is interrupted and this is the end of the last transmitted cache block...

Originally Posted by LigH

My guess: Console output may get transmitted in blocks of a fixed size instead of line-per-line (probably cached output). So when a thread locks up, the communication is interrupted and this is the end of the last transmitted cache block...

How well do you know RipBot, if at all ??

Do you think it might be the app, avisynth, ffmpeg....

Could it be the avisynth script ??

[LigH]

RipBot264 specifically: Not at all. But I do know similar results when network communication gets interrupted. When I tested PHP script output in a web browser, I noticed that the text output did not get updated line by line. Network packets are probably collected until a cache is filled before transmitting a packet. So when the remote x26? encoder or RipBot's encoder controlling background app crashes, the cache is not flushed and not transmitted to the central RipBot UI application, which ends up missing the last packet of the encoder's console output.

Originally Posted by LigH

RipBot264 specifically: Not at all. But I do know similar results when network communication gets interrupted. When I tested PHP script output in a web browser, I noticed that the text output did not get updated line by line. Network packets are probably collected until a cache is filled before transmitting a packet. So when the remote x26? encoder or RipBot's encoder controlling background app crashes, the cache is not flushed and not transmitted to the central RipBot UI application, which ends up missing the last packet of the encoder's console output.

OK, well, if I'm understanding you, then it's some network problem...

Either NIC's, cables, switches or maybe even drivers.

Would socket errors have any connection (pardon the pun) to these problems ??

[LigH]

I do not mean unreliable network connections in the first place. There can be several reasons why the last packet of a console output relay might go missing. Like, a CPU thread finishes before the cache gets flushed (here an explicit flush of the console output before the termination of the application might help). Only guessing.

Originally Posted by LigH

I do not mean unreliable network connections in the first place. There can be several reasons why the last packet of a console output relay might go missing. Like, a CPU thread finishes before the cache gets flushed (here an explicit flush of the console output before the termination of the application might help). Only guessing.

I have to say I really have no idea what you're talking about, your knowledge is so much more than my poor old brain can comprehend.

So if you don't think its network related, but you mention CPU threads, could "working" the processor too hard cause it, like 100% for extended periods ??

[LigH]

As far as I understand RipBot: You have a central management server application, and you have encoder controlling services spread across your local network (or maybe just one on your local PC). The encoder controlling service captures the console output from the encoder and sends its output via network to the management server. But the console output is not sent on every line break. It is sent when there is enough output to fill a buffer. That can be somewhere in the middle of a text output line. The rest of the console output will be sent from the encoder controlling service to the management server application with a next network packet, either when the buffer is full again, or when it gets flushed because the encoder finished its job and there is no more text output to be captured.

There might be different reasons for the last network packet not arriving: Maybe the encoder thread does not finish gracefully, or the encoder controlling service locks up for a reason I don't know. Or the network packet gets lost. I don't know the reason. All I see is: The console output of the encoder did not arrive completely in the management server application; something interrupted the transmission. And I could guess at least three different places where it could get interrupted: At the source (the x26? encoder), at the service which captures the output and passes it to the network, or somewhere in the network.

Originally Posted by LigH

As far as I understand RipBot: You have a central management server application, and you have encoder controlling services spread across your local network (or maybe just one on your local PC). The encoder controlling service captures the console output from the encoder and sends its output via network to the management server. But the console output is not sent on every line break. It is sent when there is enough output to fill a buffer. That can be somewhere in the middle of a text output line. The rest of the console output will be sent from the encoder controlling service to the management server application with a next network packet, either when the buffer is full again, or when it gets flushed because the encoder finished its job and there is no more text output to be captured.

There might be different reasons for the last network packet not arriving: Maybe the encoder thread does not finish gracefully, or the encoder controlling service locks up for a reason I don't know. Or the network packet gets lost. I don't know the reason. All I see is: The console output of the encoder did not arrive completely in the management server application; something interrupted the transmission. And I could guess at least three different places where it could get interrupted: At the source (the x26? encoder), at the service which captures the output and passes it to the network, or somewhere in the network.

Thank you for the easier to understand explanation, I guess the only person that would know for sure how things are processed, is the dev, Atak.

It seems to be mainly on the server PC, but when that errors, it passes the same error onto the any other clients that are encoding.

I might try a different x265 build, and check the NIC connections & drivers as well.

Maybe even flushing the network cache.

Like I said, I haven't seen this error ever before, and it's only just started in the past couple of days, so it may be the x265 build I'm running....

Thankyou again LigH, for your assistance & explanation.

[Atak_Snajpera]

Originally Posted by FTLOY

What's this ???

Don't think I've seen this before, it is a little random, but once it's shown up, the chunks just keep trying to restart, to no avail

Basically, need to reboot the PC to rectify.

Check TCP communication log. See if you also get this incomplete text.
Problem maybe also related to modded x265 version you are using.

[cypher007]

ok got an odd one. normally when i close a distributed encode then restart it later it will start from the last complete chunk but today it started from chunk 1 and im guessing will overwrite what ive already encoded. at the moment ive used the bat file for each chunk to do them one by one. im not sure if this will work but dont want to bin about 15 hrs work. any ideas why it restarted from chunk 1?

Originally Posted by cypher007

ok got an odd one. normally when i close a distributed encode then restart it later it will start from the last complete chunk but today it started from chunk 1 and im guessing will overwrite what ive already encoded. at the moment ive used the bat file for each chunk to do them one by one. im not sure if this will work but dont want to bin about 15 hrs work. any ideas why it restarted from chunk 1?

Not that odd, unfortunately , I know your pain, believe me.

So how do you actually close a DE encode ???

I've found the "safest" way is to sit there and watch each chunk as it's nearly 100%, then just as it's starting a new chunk, stop it.

Do this this every chunk !!

Once you've stopped ALL the chunks, then ABORT the job, if it closes down without issue, you should be good when you resume.

What do you mean by:- (is this an effort to recover ??)

at the moment ive used the bat file for each chunk to do them one by one

Unfortunately, it's so random when it's going to this, and there's a 100% chance that you have lost 15 hours of encoding.

[cypher007]

Originally Posted by FTLOY

Not that odd, unfortunately , I know your pain, believe me.

So how do you actually close a DE encode ???

I've found the "safest" way is to sit there and watch each chunk as it's nearly 100%, then just as it's starting a new chunk, stop it.

Do this this every chunk !!

Once you've stopped ALL the chunks, then ABORT the job, if it closes down without issue, you should be good when you resume.

What do you mean by:- (is this an effort to recover ??)





Unfortunately, it's so random when it's going to this, and there's a 100% chance that you have lost 15 hours of encoding.

err didnt say that but im wondering if it will be possible to once ivve done the chunks manually to join them and continue the encode?

[Atak_Snajpera]

Either way, I have "updated" x265 to 3.6+12-f3c5fba AVX (to be compatible with some AVX CPU's on older DE clients).

Is progress correctly visible in encodingclient window?

[cypher007]

Originally Posted by FTLOY

As far as I can tell, there's no issues with client.

The only strange thing that has been happening (and I think I've mentioned this recently), is a chunk can be happily progressing, and then "out of the blue", it re-starts, no errors msg's, just starts from 0%.

ive had something like this when ive changed networks on a PC even when im only DE on one PC.