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

[mparade]

Thx! + ok.

[byteshare]

BIG changes in Encoding Client for server "control" :)

Can't wait to check this out :)
Ah, I see what you mean now. You can suspend or shutdown a server.
Not sure if anything else changed.

[Dhry]

There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry

[osgZach]

Atak,

I don't recall if I've ever asked this before, although I get the feeling I may have broached the subject in years previous. I'm curious about what method you are employing to split the files (I don't see anything "obvious" in the tools directory except an executable called vjoin, which I assume is for joining). I'm trying to do some research on the best way to accomplish splitting/joining accurately and efficiently without any glitches. I've seen references online to using ffmpeg to split on keyframes (and ffprobe to acquire an index of keyframes to help with this) but haven't really found any real turnkey solution, outside of something like DVE https://github.com/nergdron/dve



slightly related, do you have any plans to ever expose ffmpeg for use by the user (as opposed to x264/x265)? I'm mainly interested in targeting and accelerating VP9 (libvpx for now) across multiple cores/machines, but down the road when Intel's SVT libraries become more mature this could be useful to a lot of people as well, especially with AV1

[Atak_Snajpera]

There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry
What happens If you run ripbot264 on other machine? Do you still see the same issue? Record you desktop with some software (fraps or other) and upload somewhere. I would like to see that weird behaviour with my own eyes.

Ps. I also have win7 on all my machines and everything just works.

[guest]

There seems to be something wrong with the latest 1.25 of Ripbot and the 1.16 EncodingServer. I had reported issues with trying to get a batch to start properly (adding a file via Add worked, though), however as of today, even adding a file via that method did not work with distributed encoding. What happens is that the file demuxes and this and that fine, then the dist encoding master window pops up for pass1 and nothing happens. None of the server farm responds. Their encodingserver instances literally do not receive the TCP command at all. Nothing appears in the logging console. I switched out for 1.15.1.0 of the encodingserver and THEN they started to receive commands but were unable to open the file for writing to my shared folder. It's only when I went back to Ripbox 1.24 and used IT'S encoding client, and encodingserver 1.15.1.0 on all of my boxes, that everything started working again. INCLUDING batch processing! Some weird networking change has evidently been done in the code which breaks connectivity. I disabled my firewall and tested pings between the machines, no problem at all. The problem now is that using RB 1.24 I get the old error stating that video.265 file could not be opened. Are there any known distributed encoding connectivity issues that others have experienced with RB 1.25 and EncodingServer 1.16? Using Windows 7 SP1.

--Dhry

What happens If you run ripbot264 on other machine? Do you still see the same issue? Record you desktop with some software (fraps or other) and upload somewhere. I would like to see that weird behaviour with my own eyes.

Ps. I also have win7 on all my machines and everything just works.

I concur...

I only just got around to "testing" the latest update (08-11-19), and it's completely ruined DE !!!

Not using DE works fine !!

So I have recorded my desktop (using OBS, Fraps doesn't like W10, apparently).

https://www.mediafire.com/file/aoz3zppgbcvrbia/2019-11-13_13-49-35.rar/file

I have shown most of RB screens in the capture...there's just nothing connecting.

Also, there needs to be a "flyout" of what the new buttons do, in the left column of Encoding Client do (you'll see what I mean in the capture)

Also, running W10 1903, and just because it works on W7, doesn't mean it will work on other versions...

You might also notice that when the Job is aborted, it kills RB, but leaves the Clients in the Task Bar.

I have had to return to the previous build.

And another thing I'd like to mention (which has been a problem for me for a long time), after you add a new Job, and then start that Job, it won't start processing....RB has to be re-started beforehand !!

[MCFish]

Same here. None of the encoding servers get any connection with latest update.

[ReinerSchweinlin]

I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Bevore, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?

[Ryushin]

I'm getting a error on the DE Server:
x265 [Error]: main10 profile not compatible with i444 input chroma subsampling

Brought a fresh job in of a 4K HDR mkv file, that Ripbot made from the original 4K source a few days ago. Changed the size down to 720p. Set 5.1 AAC, 21 CRF. X265 with the default options plus sar 1:1 (not sure why sar 1:1 is not the default as I've been bitten by stretching in 4x3 shows). Server Chunk fails with that error immediately as it tries to start it.

Also, older 4K jobs that I brought in from disc source from a couple of weeks ago just show "Starting...." and then nothing ever starts. Encoding client shows processor usage about 15%, but nothing ever starts.

Edit: Well, one of the older jobs eventually started running after about 30 minutes. However, the job before it had Starting... for six hours and never did anything.

[Atak_Snajpera]

I concur...

I only just got around to "testing" the latest update (08-11-19), and it's completely ruined DE !!!

Not using DE works fine !!

So I have recorded my desktop (using OBS, Fraps doesn't like W10, apparently).

https://www.mediafire.com/file/aoz3zppgbcvrbia/2019-11-13_13-49-35.rar/file

I have shown most of RB screens in the capture...there's just nothing connecting.

Also, there needs to be a "flyout" of what the new buttons do, in the left column of Encoding Client do (you'll see what I mean in the capture)

Also, running W10 1903, and just because it works on W7, doesn't mean it will work on other versions...

You might also notice that when the Job is aborted, it kills RB, but leaves the Clients in the Task Bar.

I have had to return to the previous build.

And another thing I'd like to mention (which has been a problem for me for a long time), after you add a new Job, and then start that Job, it won't start processing....RB has to be re-started beforehand !!

Win10 1909
https://i.postimg.cc/hG4r4968/Untitled-1.png

[byteshare]

I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Bevore, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?
Not the most recent update but maybe 2 versions ago (no version numbers for the changes so I can't recall)? There were some changes to RB and I saw the same effect of not needing as many servers to max out CPU. Had something to do with the multiple processing threads but I'm not sure exactly what was changed or what was the issue before hand.
For my encoding machines on Core version: 2019.10.15
I have a test machine for the latest builds and once they work how I like I change to a newer version.

[guest]

Win10 1909
https://i.postimg.cc/hG4r4968/Untitled-1.png

So, we're just posting screen shots now, are we ???

My crystal ball musn't be working today....

So this is either you showing that it works, or you've fixed it, or you're just rubbing our nose's in it !!!

I got a new update this morning, only "script's", updated the pc that I did that screen recording on yesterday, loaded a new job, and exactly the same scenario....NOTHING, no TCP connection !!!

Ran build 22-10-19, loaded the same job, started that job, and away she goes, not problem, on the same pc.

What's changed ???

PS:- Just tried it on another W10 (1909) pc, and the same result, further comments in my reply to Dhry.

POORLY DONE !!!!!

[Dhry]

The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.

[guest]

The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.

Thanks Dhry, I'm glad I'm not the only one pissed off about this.

I have just tested it on 2 different W10 (1909) pc's, with the same result...NOTHING, it's f*****.

I'm not sure what the idea of that screenshot is, with NO explanation.

The only way I can get RB to do anything after that last 2 updates is to NOT use DE, OR go back to the previous build (22-10-19).

[ReinerSchweinlin]

Not the most recent update but maybe 2 versions ago (no version numbers for the changes so I can't recall)? There were some changes to RB and I saw the same effect of not needing as many servers to max out CPU. Had something to do with the multiple processing threads but I'm not sure exactly what was changed or what was the issue before hand.
For my encoding machines on Core version: 2019.10.15
I have a test machine for the latest builds and once they work how I like I change to a newer version.
I noticed the CTU size smaller then usual when using RB with x265, which seems to help with many cores, maybe something changed here, too..

[guest]

I noticed one new thing:
After changing my Numa Settings in my proliant D380G7 (2 x Xeon X5650) to not use NUMA but instead treat the two CPUs as one - I get almost 96% CPU Usage when using one encodingserver with x265 slow settings - it is blazing fast now. Before, I had to use 4 servers to max out CPU (only de-interlacing used, nothing else).

Did anything change in recent x265 you use?

So you're saying that NUMA isn't an advantage, anymore ??

[Atak_Snajpera]

The screenshot seems to show that RB works with Win10 only. I'm pretty sure something's broken with the tcp connectivity on Win7 at least. It's literally not making a outbound connection at all.
I'll go back to the newest versions and try again.
Edit: it isn't updating. Could the first post in this thread be changed to link to 1.25 of RB please? Still linked to 1.24.

Like I said before. Everything just works
https://i.postimg.cc/kqc6K7VC/Untitled-1.png

[guest]

Like I said before. Everything just works

Godammit, so please explain to me why the previous build works, and then it gets updated with this mess, and it's useless !?!?!?

Something in the fairly major change to Encoding Client, has impacted the TCP connection !!

So you've clearly shown that it works for you on both W7 & W10, but you have to advantage over us, YOU know what you've changed, and we don't.

Did you view that desktop capture I posted ??? what else do you need ??

[Atak_Snajpera]

My theory is that your firewall Has detected that checksum for encodingclient.exe/encodingserver.exe changed and by default blocks again all outgoing connections.

[guest]

My theory is that your firewall Has detected that checksum for encodingclient.exe/encodingserver.exe changed and by default blocks again all outgoing connections.

Well, I doubt that's the problem, as I have ALL the Firewall's disabled.

But why would that change between RB builds ??

[Atak_Snajpera]

Use nmap to check If ports 1000,2000 and so on are open.

[guest]

Use nmap to check If ports 1000,2000 and so on are open.

I will get Nmap, and do what it does, and I will get back to you.

Nevertheless, you must have changed something, in the last update !!!

Update:- got Nmap, don't know what I have to do.....

[ReinerSchweinlin]

So you're saying that NUMA isn't an advantage, anymore ??
Well, I can´t be sure this is valid for every dual CPU configuration. I switched NUMA off because I can´t get any grafix card to run in my DL380, so I am using the CPU for OPENCL (which is slow, but in some of my cases is better than nothing). This way all of the cores are used for OPENCL Filtering, which gave quite a bosst.
I then tested Encodes without OPENCL usage and encountered the CPU Usage to bee much higher than before when using only one encodingserver. Same time some updates came from RB Update Server - so I can´t be sure what´s exactly the cause of this right now, would have to switch back to NUMA mode and compare. Didn´t have time for that, that´s because I was asking here, if something had changed within x265/RB (after all, maxing out more cores while encoding can be usefull for bigger multicore CPUs as well).

[guest]

Well, I can´t be sure this is valid for every dual CPU configuration. I switched NUMA off because I can´t get any grafix card to run in my DL380, so I am using the CPU for OPENCL (which is slow, but in some of my cases is better than nothing). This way all of the cores are used for OPENCL Filtering, which gave quite a bosst.
I then tested Encodes without OPENCL usage and encountered the CPU Usage to bee much higher than before when using only one encodingserver. Same time some updates came from RB Update Server - so I can´t be sure what´s exactly the cause of this right now, would have to switch back to NUMA mode and compare. Didn´t have time for that, that´s because I was asking here, if something had changed within x265/RB (after all, maxing out more cores while encoding can be usefull for bigger multicore CPUs as well).

OK, aside, have you got the very latest RB update ???

If so, are you have DE problems ??

[Atak_Snajpera]

https://forum.doom9.org/showthread.php?p=1889796#post1889796

[guest]

https://forum.doom9.org/showthread.php?p=1889796#post1889796

:thanks:

OK, did a simple scan on the laptop that has the latest RB on it, and here's the results...

Starting Nmap 7.80 ( https://nmap.org ) at 2019-11-15 00:01

Nmap scan report for DELL-XPS-M1330.gateway (10.0.0.132)

Host is up (0.00s latency).


PORT STATE SERVICE

1000/tcp closed cadlock
2000/tcp closed cisco-sccp
3000/tcp closed ppp
4000/tcp closed remoteanything
5000/tcp closed upnp
6000/tcp closed X11
7000/tcp closed afs3-fileserver
8000/tcp closed http-alt

Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds

So what does this mean ??

I will run some test on the one of my "proper" RB pc's tomorrow.

[Atak_Snajpera]

This is how it should look...
https://i.postimg.cc/Z5mFdKf2/Capture.png
All your ports are closed. Check anti-virus or other anti-malware software.

[Privateer5000]

Same Problem here with DE Mode not working on 2 machines. Used nmap and it says STATE open like in the picture above. Tried it on Win10 1903, just upgraded to 1909 but still nothing happens.

[guest]

This is how it should look...
https://i.postimg.cc/Z5mFdKf2/Capture.png
All your ports are closed. Check anti-virus or other anti-malware software.

Only using built in Windows Defender...

But it still MUST be something you've changed !!!!

[Atak_Snajpera]

But it still MUST be something you've changed !!!!
Yes I have added...
if PaulyDunnePC=true then BlockDEmode

[guest]

Yes I have added...
if PaulyDunnePC=true then BlockDEmode

Seriously...is that the best you can do !!

Its like beating your head against a wall, why does the previous build work, and the latest one doesn't ??

It's not just me !!!

[Donholio]

Hi, everyone!

I just want to calmly let everyone know that my corporate antivirus found an issue in the waitforprocess.exe file that is downloaded by the updater for RipBot264. The file is hosted here: http://atak-snajpera.5v.pl/ripbot264update/WaitForProcess.zip according to the update.ini file.

This is the entry from Cisco Umbrella:

o Event Type: Executed malware
o Computer: <REDACTED>
o Hostname: <REDACTED>
o IP: <REDACTED>
o Detection: W32.31A417AE41-85.LP.RET.SBX.TG
o File: WaitForProcess.exe
o File path: file:///<REDACTED>RipBot264v1.24.0/tools/WaitForProcess/WaitForProcess.exe
o Detection SHA-256: 31a417ae412e9e64799565f00ff1efbcd665caf2b8433e63af0a9c59653eaaf7
o Application SHA-256: 3685495d051137b1c4efde22c26df0883614b6453b762fa84588da55ed2e7744
o Severity: High
o Timestamp: 2019-11-14 12:26:18 +0000 UTC

The SHA-256 for the application shows very little detection information. When I run the Application SHA through Virustotal's search function, it shows clean. When I run the Detection SHA (the part of the file detected as "malware"), it shows detections by CrowdStrike Falcon, Panda, Microsoft, Trapmine, and Webroot. Anyone can check this themselves by copying the SHA256 values above, logging into VirusTotal, and clicking the Search function.

It looks like the detected malware might be adware-related or part of an SEO inflation scheme. It also looks like there might be a trojan that modifies windows firewall settings.

I want to scan the actual file through VirusTotal, but unfortunately, the application is blocked by Cisco Umbrella. I will test my home machine once I get home, but if the SHA values match, there should be no different information.

I love RipBot264 and want to continue using it. I've updated the update.ini and installed_tools.ini files in the Tools directory and the update.ini file in the Updates directory to set waitforprocess's AllowUpdate value to 0 for now. I'm not sure what the application is used for at this point. I'd be interested to know what I'm breaking by not having it around.

I think what I've found is credible and I feel it would be best to get this information out there ASAP. Please let me know if this is a known issue and a false positive.

Like I said to start, I'm not trying to cause a panic here and I'm a huge fan of the program.

Thanks

-Donholio

[Atak_Snajpera]

WaitForProcess.exe is just a helping tool I wrote to spawn multiple executables and aggregate percentage progresses into single percentage progress (which is then displayed in ripbot264). It is used during indexing and encoding audio. Some anti-viruses are VERY allergic to executables compressed by UPX. ( https://upx.github.io/ )
If you delete WaitForProcess.exe then indexing and audio encoding won't work.
https://i.postimg.cc/Zq4JTWh5/Untitled-1.png

It is obvious that it is false positive detection...
https://www.virustotal.com/gui/file/31a417ae412e9e64799565f00ff1efbcd665caf2b8433e63af0a9c59653eaaf7/detection

[byteshare]

Only using built in Windows Defender...
But it still MUST be something you've changed !!!!
Do you have exceptions for the RB folder and temp folders?

Same Problem here with DE Mode not working on 2 machines. Used nmap and it says STATE open like in the picture above. Tried it on Win10 1903, just upgraded to 1909 but still nothing happens.
Do you have Windows Defender with exceptions for RB and Temp Folder?
Does an older version work for you like Pauly?

On Core 2019.11.08 and Encoding Server 1.16.0.0 I have RB working in DE mode with two different Windows 10 computers, both 1903 (one Pro and one Home)

Yes I have added...
if PaulyDunnePC=true then BlockDEmode
I found this funny. :goodpost:

[guest]

Do you have exceptions for the RB folder and temp folders?


Do you have Windows Defender with exceptions for RB and Temp Folder?
Does an older version work for you like Pauly?

On Core 2019.11.08 and Encoding Server 1.16.0.0 I have RB working in DE mode with two different Windows 10 computers, both 1903 (one Pro and one Home)


I found this funny. :goodpost:

No, I don't have any exceptions....I've never had to before !!!

Why can't he just say that's he's changed something...

Just a sick IT sense of humour...it wouldn't have worked, anyway..

[Atak_Snajpera]

My last attempt to help you. Create virtual machine and then install fresh win10 1909. See If you can connect to servers within virtual machine. Virtual win10 also works on my pc. If still nothing then i give up.

[byteshare]

No, I don't have any exceptions....I've never had to before !!!

Why can't he just say that's he's changed something...

Just a sick IT sense of humour...it wouldn't have worked, anyway..
I had to add the exceptions and have had them for a while, so not sure what is causing your issue since your port is open.
RB is working on 4 Win10 machines for me right now after testing the newest version. I have Windows Fire Wall on, but with exceptions for RB and Windows Defender exceptions for RB.

[ReinerSchweinlin]

OK, aside, have you got the very latest RB update ???
Yes, at least the one from this morning which was the last time RB was started on all machines.


If so, are you have DE problems ??
No. Mixed WIN 10 and WIn 7 PCs, some over VPN, different CPUs/GPUs...

[guest]

My last attempt to help you. Create virtual machine and then install fresh win10 1909. See If you can connect to servers within virtual machine. Virtual win10 also works on my pc. If still nothing then i give up.

This is your software, and your update, so you need to help until this is resolved.

Not interested in VM nonsense, I just installed W10 1909 on another pc, left it all default, vanilla settings, installed what RB needs to work, it ask to do the exceptions it needed, loaded a new job, and exactly the same non starting, non connecting behaviour.

So I need some one to tell me exactly what they did, to get this latest build working in DE !!

I still don't understand why a working app, stops working after an update, and the creator of that update can't or won't tell us what he's done, or how to fix it.

I'll ask you again, did you view that screen capture I posted ???

That's what happens, just a lot of little boxes & icons flashing, not doing ANYTHING, no info in the TCP window..it's just dead !!!

So for now, I will just have to run with the previous working build, and turn off auto updates.

[howzz]

i noticed that with the latest update, "gathering information" is once again taking a lonnnnng time. except this time, regardless of choosing Lmash, FFmp2 or GPU makes it any faster. i noticed the update log says the script was updated. just exactly what changed made Gathering Information so much slower now.

i also noticed that it takes forever for the encode to begin now. from the time i click "start", to seeing all the cores loaded, it takes like 2 mins. before it used to be instant.

[guest]

i noticed that with the latest update, "gathering information" is once again taking a lonnnnng time. except this time, regardless of choosing Lmash, FFmp2 or GPU makes it any faster. i noticed the update log says the script was updated. just exactly what changed made Gathering Information so much slower now.

i also noticed that it takes forever for the encode to begin now. from the time i click "start", to seeing all the cores loaded, it takes like 2 mins. before it used to be instant.

Join the club, mate...

I can't DE to work at all, since last update, consider yourself lucky that it only take 2 minutes.

[Atak_Snajpera]

This is your software, and your update, so you need to help until this is resolved.

Not interested in VM nonsense, I just installed W10 1909 on another pc, left it all default, vanilla settings, installed what RB needs to work, it ask to do the exceptions it needed, loaded a new job, and exactly the same non starting, non connecting behaviour.

So I need some one to tell me exactly what they did, to get this latest build working in DE !!

I still don't understand why a working app, stops working after an update, and the creator of that update can't or won't tell us what he's done, or how to fix it.

I'll ask you again, did you view that screen capture I posted ???

That's what happens, just a lot of little boxes & icons flashing, not doing ANYTHING, no info in the TCP window..it's just dead !!!

So for now, I will just have to run with the previous working build, and turn off auto updates.

Stop using this free software. I owe you nothing. I'm done with you.

[slalom]

Seriously...is that the best you can do !!

Its like beating your head against a wall, why does the previous build work, and the latest one doesn't ??

It's not just me !!!
Download the file from first page. Run it and update
Replace your files except *.ini

open RipBot and run your jobs

[guest]

Download the file from first page. Run it and update
Replace your files except *.ini

open RipBot and run your jobs

Hi slalom,

I have actually thought of doing that....I have tried that a few months ago, when there was a weird problem.

Thanks for the tip :)

[guest]

Stop using this free software. I owe you nothing. I'm done with you.

Why am I not surprised by your response...

I know you probably won't reply to this, but there are some things I want to say, like it or not.

You're obviously a pretty intelligent person, I have been trying to figure out for years now, whether you're some young smart-arse, or a grumpy old man (I think the former), I doubt that an older person would post a reply/comment like that....but then what would I know, I'm just a grumpy old man.

All I was trying to do was help you diagnose a major problem with your "free" software, that other people were commenting on, I sent you a video capture (of which you asked someone else to provide) of the strange behaviour, on my setup, and all you could do was rub it in my face, by posting screenshots of it working on your setup, with NO explanation !!!

I also asked several times for an explanation on what you had changed in the auto update that ruined everything, and you simply didn't....you asked me to get specific app's to check things that I have no idea about what I'm doing, or what I'm looking for.

You seem to expect everyone out there to have the same level of expertise as you...well, we don't !!!

I gave you as much info as I could, but you simply didn't want to explain anything, all you did was say, "It just work's".

It has to be something to do with the changes you added for server control.

Are you going to help the others that are starting to comment on the same error's, are you going to ignore them, and tell them, "I'm done with you" ???

You can't stop me from using this software, I know some day, in hopefully the not too distant future, you WILL fix it, I WILL get the update's, and I'll be happy.

I WILL keep perusing this forum, and if I feel the need, I WILL post a comment.

Like I just did....

[byteshare]

Why am I not surprised by your response...
I've mentioned it before a while back. It isn't that you're asking for help. It is how you're asking for help (in my opinion). This is free software, so you can only expect limited support--if any. Unless the issue you're having is experienced by everyone it is possible to not get support, which has happened to me as well, but often it is something on my end that I eventually figure out.

[byteshare]

Yes, at least the one from this morning which was the last time RB was started on all machines..
Latest I can see is Core 2019.11.08, Scripts 2019.11.13, MKVtoolnix 40.0.0
(would be easier to tell if the point versions changed with each update)

i noticed that with the latest update, "gathering information" is once again taking a lonnnnng time. except this time, regardless of choosing Lmash, FFmp2 or GPU makes it any faster. i noticed the update log says the script was updated. just exactly what changed made Gathering Information so much slower now.

i also noticed that it takes forever for the encode to begin now. from the time i click "start", to seeing all the cores loaded, it takes like 2 mins. before it used to be instant.
As far as I understand it, no matter what the default decoder is you're still doing LSmash when adding a job so that if you want to switch decoders later it isn't super slow, which is why if you look in the job folder you'll still see a *.lwi file, also when starting a job it does the compression and such for being able to send the LSmash file (even if it isn't going to be used). So...I believe it is slow for you again because of something to do with LSmash.
--I could be wrong about the above, but that is how I understood it.--
I'm not sure who is switching their decoder all of the time but personally I would prefer if only the selected default decoder is run when adding a job to not waste CPU/electricity/time--adds up over time ;)

[slalom]

Hi slalom,

I have actually thought of doing that....I have tried that a few months ago, when there was a weird problem.

Thanks for the tip :)
Did you try it?
That solved my problem with LSMash some time ago

[Privateer5000]

Sry for the late response, but i got a really busy day. @byteshare i also use only Windows Defender, i already had an exception for the Temp Directory but not for the Ripbot Directory. I also excluded the Ripbot folder but it changed nothing. After Going back to Version 1.24 from the first post here DE Mode was working again but as soon as i allow Ripbot updating itself to 1.25 DE Mode is broken again. There is absolutely no TCP communcation between Encoding Server and Client.

[guest]

Sry for the late response, but i got a really busy day. @byteshare i also use only Windows Defender, i already had an exception for the Temp Directory but not for the Ripbot Directory. I also excluded the Ripbot folder but it changed nothing. After Going back to Version 1.24 from the first post here DE Mode was working again but as soon as i allow Ripbot updating itself to 1.25 DE Mode is broken again. There is absolutely no TCP communcation between Encoding Server and Client.

Hi Privateer5000,

I'm so happy that you've got the same problem I have....I have tried to supply as much info I can to the dev, and he's not responded well, in fact if you go back a couple of posts, you'll see what he said to me.

Because it works for him, he doesn't see a problem.

BTW, posting attachments on this forum isn't a very good idea, takes way too long for them to be approved.