View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
Atak_Snajpera
19th November 2018, 14:13
More problems:-
I am still getting the odd server stall, and not restarting, even tho I have that covered in the command line instructions....and not only doesn't it restart, you can't stop it...the only option is to abort that job, and try again.
Does title in EncodingServer say "NOT RESPONDING"? Can you close encodingserver by clicking X button or you have to kill it via task manager?
dracore
19th November 2018, 20:18
i have just upgraded too the 2990wx - does ripbot support upto 32 cores or to use my cpu better would running ripbot 2 or 3 times help with speeds .... thank you :)
dracore
19th November 2018, 20:51
i have setup 5 servers for encoding and they all just say idle, waited a while and still nothing happening - can anyone help with this please
Atak_Snajpera
20th November 2018, 14:29
i have setup 5 servers for encoding and they all just say idle, waited a while and still nothing happening - can anyone help with this please
Let me guess you just manually ran EncodingClient.exe and then you clicked ON buttons?
By the way. Why did you use such weird number of servers? 2990WX has four numa nodes so you should use 4 or 8 servers (1-2 servers per numa node).
byteshare
20th November 2018, 16:57
Strange thing is, I don't get any error pop up windows (using either W7, W10, or Windows Server 2019).
If I click on the taskbar server icon, it does not respond (I guess because it's stalled/errored).
If I use the X to close, there are "ghost" icons left in the taskbar, eg:- the main Ripbot icon, and a couple of server icons.
And yes, the only option is to "kill it" (Ripbot.exe, and whatever instances of Encoding Server that are showing), with Processhacker/task manager.
And btw, when I went to start the job queue, today (that I set up yesterday), without adding a thing, it would not start encoding the job's, UNTIL I aborted, and backed out of Ripbot, and restarted it, then it was fine....:confused:
I've had that too but not very often. I find it more stable than killing it to just restart Windows. Using Windows 10 only these days for encoding.
dracore
20th November 2018, 18:29
Let me guess you just manually ran EncodingClient.exe and then you clicked ON buttons?
By the way. Why did you use such weird number of servers? 2990WX has four numa nodes so you should use 4 or 8 servers (1-2 servers per numa node).
i used that many just to try and test - i added the ip adress ect to each server section and just sits at idle, ive also granted access through my firewall?
Atak_Snajpera
20th November 2018, 19:48
Strange thing is, I don't get any error pop up windows (using either W7, W10, or Windows Server 2019).
If I click on the taskbar server icon, it does not respond (I guess because it's stalled/errored).
If I use the X to close, there are "ghost" icons left in the taskbar, eg:- the main Ripbot icon, and a couple of server icons.
And yes, the only option is to "kill it" (Ripbot.exe, and whatever instances of Encoding Server that are showing), with Processhacker/task manager.
And btw, when I went to start the job queue, today (that I set up yesterday), without adding a thing, it would not start encoding the job's, UNTIL I aborted, and backed out of Ripbot, and restarted it, then it was fine....:confused:
Killing just EncodingServer.exe is not enough? You have to kill EncodingClient.exe and RipBot264.exe as well?
byteshare
21st November 2018, 00:01
Killing just EncodingServer.exe is not enough? You have to kill EncodingClient.exe and RipBot264.exe as well?
For me I have to kill Ffmpeg.exe, which is the part that seems to get stuck and locks everything else up since I believe the Encoding Client and RipBot are waiting for that to end task.
Atak_Snajpera
21st November 2018, 13:18
Come on Atak, I was summarizing. I kill everything that is used by the Ripbot process.
And I have to thank bytshare for his comment, good to know that I am not the only one getting this random hiccup.
And yes, as a last resort, a Windows restart is a good option.
I need precise description what application is causing problems not some "summarization". You are not helping with that kind of bug report.
Atak_Snajpera
21st November 2018, 13:27
For me I have to kill Ffmpeg.exe, which is the part that seems to get stuck and locks everything else up since I believe the Encoding Client and RipBot are waiting for that to end task.
add /restart-if-no-progress to EncodingServer.exe commandline.
This command will restart encoding on server if ffmpeg.exe and x264.exe/x265.exe are not using cpu cycles for 1 minute.
Basically I'm checking USER TIME for specific process. This value increases if application is working.
https://i.postimg.cc/SKf2n6VJ/Untitled-1.png
Atak_Snajpera
21st November 2018, 14:53
So, I have this command in the commandline, set for 2 minutes...so how come it doesn't restart these random stall's that can't be stopped ??
You can easily check if that switch works by suspending ffmpeg.exe process in Process Hacker. After one minute EncodingServer will automatically restart encoding.
However I suspect that your issue is completely different. In your case whole EncodingServer.exe for some unknown reason hangs.
I would have to write additional small application to just monitor EncodingServer.exe in this case. That's why I need to know precisely what hangs.
byteshare
21st November 2018, 17:18
Interesting !!
So just out of interest, do you get the pop up window when a server stalls ???
I think I have only seen it on my W7 machine.....
Windows 7 display's it from the Taskbar, and W10 displays it from the bottom right hand corner (if memory serves me correctly)
I'm not 100%, I thought I do, but I'll keep an eye out for when it happens next so I can give accurate information.
add /restart-if-no-progress to EncodingServer.exe commandline.
This command will restart encoding on server if ffmpeg.exe and x264.exe/x265.exe are not using cpu cycles for 1 minute.
Basically I'm checking USER TIME for specific process. This value increases if application is working.
https://i.postimg.cc/SKf2n6VJ/Untitled-1.png
Thank you. I'll get that set and see how it goes...might be a while before I report back on this because I wasn't having this issue very often.
therealjoeblow
22nd November 2018, 01:14
I used RipBot v1.23.1 to convert a 2160p HDR x265 video to a 1080p SDR x264 using the BT.2020->BT.709 Tonemap option, and while it did correct the HDR and remap the colors/levels, the end result still looks a bit too bright. Whites in very light scenes look a bit blown out, and during the end credits where the background should be pure black, it's not quite, its dark grey.
Almost like it needs TV->PC level conversion, but not quite - when I ran a second encode and added that option, then it was too dark, with blacks being crushed and losing all detail in dark parts throughout.
So it needs a tweak in-between.
Does anyone know if this is normal, and in that case, are there "standard" additional changes I would need to the brightness and contrast settings to get the levels correct? Or do I need to just keep doing test encodes until I find the right balance?
therealjoeblow
22nd November 2018, 02:13
I've had this happen a couple of times...it can actually be the movie itself, does the original play "nice" ??
Are you forcing the BT.2020->BT.709 settings ?
I don't have a HDR TV so I don't know for sure if the source is correct.
I selected BT.2020->BT.709 in the Avisynth options, not sure what you mean by "forcing" it, but the encoded file appears to have correctly converted the HDR to SDR.
When I play the encoded x264 file back with MPCHC, if I go into the options under "video"..."color correction" and set brightness to -5, then the black levels are perfect - the credits are pure black as they should be, and the blown out light scenes look correct.
So I'm assuming that I need to set brightness to whatever the equivalent is in RipBot. In MPCHC, the brightness range is -100 to +100.
RipBot lets me change the brightness from -255 to +255 in the "Tweak Colors" setting. So would I set it for 5/100*255=-13??
Atak_Snajpera
22nd November 2018, 12:36
I used RipBot v1.23.1 to convert a 2160p HDR x265 video to a 1080p SDR x264 using the BT.2020->BT.709 Tonemap option, and while it did correct the HDR and remap the colors/levels, the end result still looks a bit too bright. Whites in very light scenes look a bit blown out, and during the end credits where the background should be pure black, it's not quite, its dark grey.
Almost like it needs TV->PC level conversion, but not quite - when I ran a second encode and added that option, then it was too dark, with blacks being crushed and losing all detail in dark parts throughout.
So it needs a tweak in-between.
Does anyone know if this is normal, and in that case, are there "standard" additional changes I would need to the brightness and contrast settings to get the levels correct? Or do I need to just keep doing test encodes until I find the right balance?
Tweak settings directly in DGHable plugin.
Help
Hable Usage
--------------
DGHable(clip, float exposure, float a, float b, float c, float d, float e, float f, float w)
exposure default: 2.0
a default: 0.15
b default: 0.50
c default: 0.10
d default: 0.20
e default: 0.02
f default: 0.30
w default: 11.2
Input must be CS_RGBPS, see z_ConvertFormat() in the script below.
If 'clip' is omitted, then as usual implicit last is used.
Meaning of Hable coefficients:
exposure: Gain to apply.
a: Shoulder strength
b: Linear strength
c: Linear angle
d: Toe strength
e: Toe numerator
f: Toe denominator
w: Linear white point
hable(x) = ((x*(a*x+c*b)+d*e) / (x*(a*x+b)+d*f)) - e/f
output_pixel = hable(exposure * input_pixel) / hable(w)
Default exposure value is 2.0
https://i.postimg.cc/4xLmd5nQ/Untitled-1.png
Click preview script to verify your new settings before encoding.
Atak_Snajpera
22nd November 2018, 12:45
Hi Atak, OK, so I did a fair bit of testing so I could give you as much info as I can, so here goes :-
I started an encode, and only had one server going, to make it a little easier to find in Process Hacker.
I suspended Encoder Client, and of course the encoding stopped immediately, after the allotted time (1 minute), it did NOT restart !
Once I got it going again, I then suspended Encoder Server, same result.
Then I suspended ffmpeg (that was in the Encoding Server "tree"), and that stopped the encoding, but it restarted in the allotted time :)
I then suspended x264.exe, same result as ffmpeg, test :)
Also, with Server suspended, the taskbar icon does not "Show", and that's what happens also, when it stall's on it's own, you can't access the properties of that particular stalled server to "see" what it's not doing.
So, maybe a resume command needs to be added for at least Encoding Server, if not Client as well.
Would this have any thing to do with the few comments I've made about the Job Queue not starting on the 1st startup of Ripbot ?? (which is equally annoying)
Hopefully, that's enough info for you, but I know you'll tell me if it's not :)
Cheers
I clearly said that /restart-if-no-progress switch will ONLY work for stalled ffmpeg.exe and x264.exe/x265.exe. EncodingServer.exe is constantly monitoring those processes. If you suspend EncodingServer.exe then how you expect this feature to work? The same with suspending EncodingClient.exe.
For suspended EncodingServer.exe you would need additional precess monitoring in the same way how EncodingServer.exe is monitoring own spawned processes.
ReinerSchweinlin
22nd November 2018, 22:53
Hey Atak,
any chance of supporting OPENCL on XEONs? I got Support for OPENCL1.2 via Intel OpenCL Drivers for Xeon, works with luxmark. Ripbot recognizes it, butI canīt select it as a device for filters.
Yes, itīs slow, but better than nothing and 24 Threads are better than nothing :)
Atak_Snajpera
23rd November 2018, 13:07
Hey Atak,
any chance of supporting OPENCL on XEONs? I got Support for OPENCL1.2 via Intel OpenCL Drivers for Xeon, works with luxmark. Ripbot recognizes it, butI canīt select it as a device for filters.
Yes, itīs slow, but better than nothing and 24 Threads are better than nothing :)
Since when Xeons have iGPU?
ReinerSchweinlin
23rd November 2018, 13:18
Since when Xeons have iGPU?
AFAIR the newer ones even have iGPU, but I am talking about some older Models (Dual X5650)... Intel and AMD have Support for CPU-based OPEN CL. I tryed Staxrip with NLMEANS-CL, which works fine only on CPUs...
Since X264 doesnīt scale very good over 24 threads, I use the remaining for Filtering - having the opportunity to run OPENCL Filters gives me a nice option:
Sure itīs slow... But the Xeons are working in a swarm with more recent i5, i7, etc... All of them which have GPUs - so here I can use OPENCL Filters... Since the XEONs keep cyrcling in a dead loop as soon as an encode with opencl filters starts, I have to manualy take them out of the swarm (6 servers)... Would be lovely, if they participate, even if its a little slow...
The OPENCL Performance with NLMEANS plus X265 "very slow" encoding of 1080p of one of these XEON Servers is around the same as a Kaby-lake i5 with the iGPU doing the openCL encoding..
Atak_Snajpera
23rd November 2018, 14:06
Would be lovely, if they participate, even if its a little slow...
OpenCL only makes sense on GPU. I also tried KNLMeansCL on CPU but it was extremely slooooow on my E5-2690. KNLMeansCL is very demanding even on modern GPUs so I doubt that you will save alot of time running xeons in "ultra slow opencl emulation mode". You will basically create huge bottleneck in DE mode. It would be better if another i7 in your encoding team would take this job instead of those old xeons.
ReinerSchweinlin
23rd November 2018, 15:10
of course, getting bigger CPUs and GPUs always is the best way :)
I picked Ripbot because of the distributed encoding mode in order to include all PCs at hand. Instead of spedning hunderts of euros for new gear, the PCs sitting around can do the same task "for free"...
Adding all the XEON Servers here in the office gives me a plus of aorund 30fps in the pool with the mentioned settings.
Iīd have to spend around 800 Euros to get a euivalent of speed in new hardware.
Since Staxrip and others are able to use the CPU OPENCL in the Xeon Servers - and since ripbot is recognizing them - maybe itīs just a small change in the programm ?
Platform 0.
Name : Intel(R) OpenCL
Vendor : Intel(R) Corporation
Version : OpenCL 1.2
Profile : FULL_PROFILE
Extensions : cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_depth_images cl_khr_3d_image_writes cl_intel_exec_by_local_thread cl_khr_spir cl_khr_dx9_media_sharing cl_intel_dx9_media_sharing cl_khr_d3d11_sharing cl_khr_fp64 cl_intel_vec_len_hint
Platform 1.
Name : AMD Accelerated Parallel Processing
Vendor : Advanced Micro Devices, Inc.
Version : OpenCL 2.0 AMD-APP (1800.8)
Profile : FULL_PROFILE
Extensions : cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices
Atak_Snajpera
23rd November 2018, 15:21
I will see what I can do...
ReinerSchweinlin
23rd November 2018, 15:36
:thanks:
byteshare
23rd November 2018, 15:46
add /restart-if-no-progress to EncodingServer.exe commandline.
This command will restart encoding on server if ffmpeg.exe and x264.exe/x265.exe are not using cpu cycles for 1 minute.
Basically I'm checking USER TIME for specific process. This value increases if application is working.
https://i.postimg.cc/SKf2n6VJ/Untitled-1.png
I checked and I have /restart-if-no-progress already in my command line. I haven't had FFMPEG stall out like I mentioned before but I was just going over my command line.
/port xxxx /minimize /priority low /restart-if-no-progress 8
To be clear...I changed the port to xxxx, but they are all the same 1000, 2000, 3000, etc...
I'm still waiting for it to happen again so that I can take more notes.
byteshare
23rd November 2018, 17:07
HEVC stable got another bump:
2.9+8-27d8424
http://msystem.waw.pl/x265/
Looking at the notes here: https://x265.readthedocs.io/en/default/releasenotes.html
New features
Support for chunked encoding
--chunk-start and --chunk-end Frames preceding first frame of chunk in display order will be encoded, however, they will be discarded in the bitstream. Frames following last frame of the chunk in display order will be used in taking lookahead decisions, but, they will not be encoded. This feature can be enabled only in closed GOP structures. Default disabled.
Not sure this can be used for DE mode but if so it would help encodes be slightly better, no?
Ryushin
27th November 2018, 14:51
So I'm still encountering this issue.
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine. Only caveat seems to be Ripbot throws and error when pulling in a mkv file that has a TrueHD stream in it.
Decoding Error
FFAudioSource: No audio track found
(D:\Temp\Ripbot264temp\Job1023\getinfo.avs, line 4)
So I create two MKVs, one with AC3 which Ripbot pulls in fine and is processed, and the other with TrueHD, that I mux in the TrueHD audio stream after the Ripbot finishes with the first file.
dracore
27th November 2018, 15:51
is there a read me for distibuted encoding ive tryd all ways i can think of and i either get - IDLE - or just nothing - any help would be greatful .... thank you all for your time
ReinerSchweinlin
27th November 2018, 15:52
Could you provide a little more info about your setup?
byteshare
27th November 2018, 16:38
So I'm still encountering this issue.
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine. Only caveat seems to be Ripbot throws and error when pulling in a mkv file that has a TrueHD stream in it.
Decoding Error
FFAudioSource: No audio track found
(D:\Temp\Ripbot264temp\Job1023\getinfo.avs, line 4)
So I create two MKVs, one with AC3 which Ripbot pulls in fine and is processed, and the other with TrueHD, that I mux in the TrueHD audio stream after the Ripbot finishes with the first file.
Have you tried using sources TimeCodes in your encoded file to see if that fixes the problem?
Ryushin
27th November 2018, 20:38
Have you tried using sources TimeCodes in your encoded file to see if that fixes the problem?
Why no I have not. Where would I find that option?
The audio is in sync up to a certain point towards the end of the movie, then it is no longer in sync. I don't have this problem with Blu-ray sources, only Ultra Blu-ray. And the problem with Ultra Blu-ray is those discs that have seamless branching. In Incredibles 2, there are three different movies for each language. So lots of seamless branching going on. Also had this happen for discs that have the theatrical and extended cut in one disc using seamless branching.
mdchaser
28th November 2018, 07:08
I've got an interesting problem on one of my machines. All of a sudden I can't load the encoding server. I run encodingserver.exe and it flashes in the taskmanager for a fraction of a second then disappears (no logs anywhere I can find). I can run the encodingserver.exe from the old tools folder (from late 2017 I believe) and it loads just fine. I did a refresh of the system and have the same issue even though it's a "blank" machine! Any thoughts?
Thanks!
mdchaser
28th November 2018, 08:45
A quick update. I built a second machine from scratch and had the same issue. encodingserver.exe loads for a fraction of a second then unloads. The old version works fine on this machine as well.
ReinerSchweinlin
28th November 2018, 10:24
@mdchase
Check the following:
- Firewall open for the used port of the servers and ripbot client?
- All versions up to date on all machines? (Run ripbot on all machines and check, if it updates.)
- SMB reachable? Try opening the network share manualy
Atak_Snajpera
28th November 2018, 12:25
A quick update. I built a second machine from scratch and had the same issue. encodingserver.exe loads for a fraction of a second then unloads. The old version works fine on this machine as well.
Does this fix this issue?
http://www.mediafire.com/file/x5zaot1j7kji7ld/EncodingServer.exe/file
dracore
28th November 2018, 13:22
Does this fix this issue?
http://www.mediafire.com/file/x5zaot1j7kji7ld/EncodingServer.exe/file
thank you very much this fixed my issues - i will be sending a donation later today as a thank you
byteshare
28th November 2018, 16:42
Why no I have not. Where would I find that option?
The audio is in sync up to a certain point towards the end of the movie, then it is no longer in sync. I don't have this problem with Blu-ray sources, only Ultra Blu-ray. And the problem with Ultra Blu-ray is those discs that have seamless branching. In Incredibles 2, there are three different movies for each language. So lots of seamless branching going on. Also had this happen for discs that have the theatrical and extended cut in one disc using seamless branching.
I've posted on this before here:
https://forum.doom9.org/showthread.php?p=1849546&highlight=timecodes#post1849546
Official information:
https://mkvtoolnix.download/doc/mkvextract.html#mkvextract.description.timecodes_v2
mdchaser
28th November 2018, 18:33
Does this fix this issue?
http://www.mediafire.com/file/x5zaot1j7kji7ld/EncodingServer.exe/file
Thanks for uploading a new version! Unfortunately I have the same symptoms with the new one, it unloads silently and almost immediately. The old version still runs and seems to encode fine but neither machine likes the newer versions. I have run ripbot on both to make sure it runs and everything seems fine, I've also shut off the firewall but I can't imagine it has an effect on the program loading normally.
Thanks!
Jeff R.
ReinerSchweinlin
28th November 2018, 18:47
did you check the SMB network if your machine has access to the ripbot directory?
Atak_Snajpera
28th November 2018, 18:57
Thanks for uploading a new version! Unfortunately I have the same symptoms with the new one, it unloads silently and almost immediately. The old version still runs and seems to encode fine but neither machine likes the newer versions. I have run ripbot on both to make sure it runs and everything seems fine, I've also shut off the firewall but I can't imagine it has an effect on the program loading normally.
Thanks!
Jeff R.
Post detailed PC spec (CPU , windows version (fully updated or not) and so on)
mdchaser
28th November 2018, 19:14
did you check the SMB network if your machine has access to the ripbot directory?
I did but ripbot is being run locally.
mdchaser
28th November 2018, 19:19
Post detailed PC spec (CPU , windows version (fully updated or not) and so on)
First machine:
Win10, 1809, fully patched, "refreshed" back to factory. Ripbot/encoding client was the first thing I loaded. 44 Cores, 16GB RAM, lots of storage.
Second machine:
Server 2019 DC, fully patched. Fresh install, 44 cores, 6GB RAM, lots of storage.
Third machine (works great on this one):
Win10, 1809, fully patched. TONS of software installed besides ripbot. 44 cores, 16+ GB RAM.
I've also tried toggling windows defender real time virus protection to make sure that's not an issue. Toggled the firewall off on all of them as well. The two machines it's failing on are both fresh installs so I wonder if there is some dependency I'm missing? I've installed AviSynthPlus-MT-r2728-with-vc_redist.exe which is all I've needed before...
Thanks!
Atak_Snajpera
28th November 2018, 19:31
Let me guess you have DUAL xeons running in UMA mode? If yes then It is known issue which I'm currently trying to fix. What happens if you activate NUMA mode in bios?
can you also show me how cpus are detected in Task Manager? Are they grouped or ungrouped like in this example example?
https://i.postimg.cc/1XF8VzTG/Untitled-1.png
slalom
28th November 2018, 20:02
So I'm still encountering this issue.
I rip a 4K disc to the hard drive that has seamless branching, such as Incredibles 2. I then use Ripbot to pull in the movie and process it. The output will have out of sync audio towards the end of the movie. I think this only happens on 4K discs that are towards 2 hours or longer.
The work around I've been doing is to use MakeMKV to create a video file from the same source and then pull that into Ripbot to process it and it comes out fine. Only caveat seems to be Ripbot throws and error when pulling in a mkv file that has a TrueHD stream in it.
Decoding Error
FFAudioSource: No audio track found
(D:\Temp\Ripbot264temp\Job1023\getinfo.avs, line 4)
So I create two MKVs, one with AC3 which Ripbot pulls in fine and is processed, and the other with TrueHD, that I mux in the TrueHD audio stream after the Ripbot finishes with the first file.
I have the same error when there are over 30 subs in the mkv file, check that
mdchaser
28th November 2018, 21:24
Let me guess you have DUAL xeons running in UMA mode? If yes then It is known issue which I'm currently trying to fix. What happens if you activate NUMA mode in bios?
can you also show me how cpus are detected in Task Manager? Are they grouped or ungrouped like in this example example?
https://i.postimg.cc/1XF8VzTG/Untitled-1.png
They are actually a single NUMA node, I'm using a single E5-2699V4 CPU in each so everything should be stuck to the single NUMa node. In taskmanager it is detecting all 44 threads. The machine that is working is also on a 2699 without issue.
byteshare
29th November 2018, 01:21
I have the same error when there are over 30 subs in the mkv file, check that
Have you tried TimeCodes?
https://forum.doom9.org/showthread.php?p=1849546&highlight=timecodes#post1849546
Atak_Snajpera
29th November 2018, 11:25
They are actually a single NUMA node, I'm using a single E5-2699V4 CPU in each so everything should be stuck to the single NUMa node. In taskmanager it is detecting all 44 threads. The machine that is working is also on a 2699 without issue.
First machine:
Win10, 1809, fully patched, "refreshed" back to factory. Ripbot/encoding client was the first thing I loaded. 44 Cores, 16GB RAM, lots of storage.
Second machine:
Server 2019 DC, fully patched. Fresh install, 44 cores, 6GB RAM, lots of storage.
Third machine (works great on this one):
Win10, 1809, fully patched. TONS of software installed besides ripbot. 44 cores, 16+ GB RAM.
You said 44 cores so I assumed that you have dual E5-2699V4.
ReinerSchweinlin
29th November 2018, 11:30
I can't believe it's been just over a month since the last auto update :(
With exception of a newer version of Encoding Server, posted a couple of days ago, which I'm yet to try.
This is free Software. Atak is giving a lot of support for free.
So be patient. Updates come when they come and the only response then should be "Thank you"...
Atak_Snajpera
29th November 2018, 11:54
Thanks for uploading a new version! Unfortunately I have the same symptoms with the new one, it unloads silently and almost immediately. The old version still runs and seems to encode fine but neither machine likes the newer versions. I have run ripbot on both to make sure it runs and everything seems fine, I've also shut off the firewall but I can't imagine it has an effect on the program loading normally.
Thanks!
Jeff R.
And now?
http://www.mediafire.com/file/1btksnqw32of8b9/EncodingServer.exe/file
Atak_Snajpera
29th November 2018, 12:56
I think it is time to get rid of hqdn3d denoise filter. I really do not like how this filter shifts content of the frame. KNLMeansCL does better job here. Open images in separate tabs and you will see what I mean.
Original frame
https://i.postimg.cc/ZK4dGfSc/nodenoise.png
MDegrain2 + KNLMeansCL (strength=2)
https://i.postimg.cc/RCctpkjh/mdg2-knlmeanscl2.png
MDegrain2 + hqdn3d (strength=8)
https://i.postimg.cc/ZRYkttwm/mdg2-hqdn8.png
Another my conclusion is that KNLMeansCL is not very useful as standalone filter.
Original Frame
https://i.postimg.cc/JnR8rB49/org.png
MDegrain2
https://i.postimg.cc/brdKr0XF/mdegrain2.png
KNLMeansCL (default settings)
https://i.postimg.cc/PrgBf8S2/knlmeanscl.png
hqdn3d (Strength=8)
https://i.postimg.cc/7hy2Y9Tq/hqdn8.png
ReinerSchweinlin
29th November 2018, 13:19
About "shiftin content": Are you sure this is the same frame? Maybe its a little movement in the picture, since only lower parts of the picture seem to shift, the boots stay where they are... Maybe hgdn3d takes previous and following frames into account and therefore shifts frames in the time-domain - so the shown fram actually is the frame number +1... ?
KNLMeansCL: Whats Default Setting? In Ripbot, default here is "0" which seems to do nothing at all... "2" and above on the other hand shows clear load on the GPU and very visible noise removal in preview.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.