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

[slalom]

So, after I did that
I downloaded and extracted the files from the first page
I ran that to update to the latest files, checked the files with yours
I removed all jobs from previous version
I copied the updated folder everywere and added 5 jobs

Same thing, massive network usage
I've gone back to v1.24.0 for a couple of days

Then I read this post
It was to fix some issues with AC1 I think but other programs like staxrip uses lsmash so it isn't an issue by its self. Personally, all of my initial issues have been ironed out.
and I thought maybe I shouldn't have copied the old ini files

So, I re-extracted the zip from the first page and updated it. Changed my settings and added 3 jobs.
Now it looks waaaay faster than before, but

I used my stopwatch to count the time between finishing and re-starting of a server (the next chunk).

That was just over 5 minutes, and the network usage to the roof, again
Anyone else has that problem?

[george84]

Are you running Logitech Software. See post here: https://forum.doom9.org/showpost.php?p=1879997&postcount=17029

Alternatively update Logitech Software here: https://forum.doom9.org/showpost.php?p=1880045&postcount=17034

Hope this helps..

Thank you. I don't have Logitech, but Wacom Tablet software installed. However table is not in use. After aborting these processes, RipBot264 will do an exit when requested.

I hope that a Wacom driver update will correct this.

[slalom]

Ok, second job is going faster, just a few seconds between chunks, don't know why

First two jobs completed with an error. Combining chunks didn't run

Error: The file 'E:\Temp\RipBot264temp\video.264' could not be opened for reading: open file error.

But I can manually run CombineAllChunks.cmd & jobX_MuxFiles.cmd and get my file

[nekrosoft13]

Hey Atak

About week (maybe two) there was a update that is started causing weird issues on my system.

I'm using DE.

I don't know how to describe the, issue, in few places in a file, the video turns in a flashing slideshow with bunch of random frames from previous scenes. Its weird.

here is the sample

https://www.mediafire.com/file/woqlu9wmfw2ufnb/sample.mkv/file

[byteshare]

Ok, second job is going faster, just a few seconds between chunks, don't know why

First two jobs completed with an error. Combining chunks didn't run

Error: The file 'E:\Temp\RipBot264temp\video.264' could not be opened for reading: open file error.

But I can manually run CombineAllChunks.cmd & jobX_MuxFiles.cmd and get my file

What is the source filename exactly?
I recall having that issue with some characters in a filename.

Hey Atak

About week (maybe two) there was a update that is started causing weird issues on my system.

I'm using DE.

I don't know how to describe the, issue, in few places in a file, the video turns in a flashing slideshow with bunch of random frames from previous scenes. Its weird.

here is the sample

https://www.mediafire.com/file/woqlu9wmfw2ufnb/sample.mkv/file

That looks like the same issue I was having with a few files. I don't really understand what is causing it since not all files have that issue.
I noticed it with a new file. Going to see if I get the same issue rerunning the file as I tried encoding just the part with issues in isolation and didn't have an issue. The video had frames randomly from the end of the file well before the end of the video.
Here is the source (00), the encode with the issue (01), and the re-encode from the source once I cut it down to the 8s clip (02): https://mega.nz/#F!UhIHTSzK!WziTOfYZYG80sLYHlu-DHg
I've been going through and not every file has this issue so I'm not sure what is causing it. Seems to be very common on my videos over 30min.
At this point encoding doesn't seem stable to me.

[george84]

Thank you. I don't have Logitech, but Wacom Tablet software installed. However table is not in use. After aborting these processes, RipBot264 will do an exit when requested.

I hope that a Wacom driver update will correct this.

Unfortunately this didn't help. Temporary solution remains to abort Wacom processes or prevent their autostart.

[slalom]

What is the source filename exactly?
I recall having that issue with some characters in a filename.
No special characters on the filename.
Anyway I closed and started Ripbot and the next encode completed successfully

I need to check network usage today. I suppose the usual are short spikes about 30% network usage when completing chunks, but I saw higher and longer usage at some point. I need to see that again today

[duffbeer]

Hey Atak

About week (maybe two) there was a update that is started causing weird issues on my system.

I'm using DE.

I don't know how to describe the, issue, in few places in a file, the video turns in a flashing slideshow with bunch of random frames from previous scenes. Its weird.

here is the sample

https://www.mediafire.com/file/woqlu9wmfw2ufnb/sample.mkv/file

I have had the same problem too. Seems like some files have frames that jump around like your example and some files have kind of the opposite, a very slow choppy playback at about 2fps.
I've gone back to 1.24.1 and everything is spot on. I don't see why we needed LSmash when everything was working fine with FFMS.
There seems to be no advantage to LSmash so why go through all the problems??

[slalom]

The normal is on the left

https://i.ibb.co/3kPcXJg/image.jpg (https://imgbb.com/)

[Atak_Snajpera]

Regarding flashing frames. What codec is used in source file? Mpeg2,avc,hevc?

[nekrosoft13]

Regarding flashing frames. What codec is used in source file? Mpeg2,avc,hevc?

it doesn't happen in short files, 20-30 minutes

it happens a lot in longer files.

it all started about 1-2 weeks ago

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 26 min
Bit rate mode : Variable
Bit rate : 5 150 kb/s
Maximum bit rate : 25.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.099
Stream size : 3.04 GiB (87%)
Writing library : x264 core 135 r2345 f0c1c53
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=5150 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=25000 / vbv_bufsize=25000 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 47 min 12 s
Bit rate mode : Constant
Bit rate : 9 322 kb/s
Nominal bit rate : 10 000 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.188
Stream size : 3.07 GiB (94%)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

[byteshare]

Regarding flashing frames. What codec is used in source file? Mpeg2,avc,hevc?
Source is x264 (AVC). I saved 6 files that I'm testing on now. 5 are AVC L4.0 and one L4.2
I added the media info files here:
https://mega.nz/#F!UhIHTSzK!WziTOfYZYG80sLYHlu-DHg
So far I've only managed to get through one file and it repeated the issue with the frames.
---Update: I also confirmed this issue with another AVC L4.0 file NOT using DE mode, so it doesn't seem exclusive to DE mode.
...besides the flashing frames the slowness of creating index files for every chunk is a major issue since it makes some encodes overall very, very slow even when the actual encode times are fast. Is there a way to speed this up by using the .lwi file we create when we're adding jobs?

it doesn't happen in short files, 20-30 minutes

it happens a lot in longer files.

it all started about 1-2 weeks ago
You were able to confirm this too? At least we're narrowing it down.

The normal is on the left

https://i.ibb.co/3kPcXJg/image.jpg (https://imgbb.com/)
Network usage, yes? At what point is that happening for you? I have two encoding servers but they are local so that might be why I'm not seeing those spikes?

[byteshare]

Just noticed the update from 8/20. Updated core from 8.17 to 8.20 (please consider changing the release number in the main window: 1.25.x)
Re-added the problem source videos as jobs.
Realized that my encoding servers never started.
I see the "Select SuperviseProcess.exe
In the window I see this:
[2019-08-22 11:21:04] C:\RipBot\EncodingServer.exe /start /restart-if-no-progress /minimize /ip 0.0.0.0 /port 2000 (PID:3268) executed.
[2019-08-22 11:21:05] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:06] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:07] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:08] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:09] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:10] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:11] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:12] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:13] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:14] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:15] EncodingServer.exe (PID:3268) is NOT responding.
...etc until the server restarts and keeps looping like that.
I've tried a reboot. I've tried killing my startup processes, I've tried closing everything I know to close.
I can't get the encoding server to start.
Non-DE mode starts and will try that in a bit. Running a StaxRip test since it uses the same filter to see if I get the flicker issue.
Update: Stax only got 20% through the file before giving up. RB in non-DE mode is still going and over 50% through.

[slalom]

Network usage, yes? At what point is that happening for you? I have two encoding servers but they are local so that might be why I'm not seeing those spikes?
I think it's random. I have four encoding servers

[nekrosoft13]

Source is x264 (AVC). I saved 6 files that I'm testing on now. 5 are AVC L4.0 and one L4.2
I added the media info files here:
https://mega.nz/#F!UhIHTSzK!WziTOfYZYG80sLYHlu-DHg
So far I've only managed to get through one file and it repeated the issue with the frames.
---Update: I also confirmed this issue with another AVC L4.0 file NOT using DE mode, so it doesn't seem exclusive to DE mode.
...besides the flashing frames the slowness of creating index files for every chunk is a major issue since it makes some encodes overall very, very slow even when the actual encode times are fast. Is there a way to speed this up by using the .lwi file we create when we're adding jobs?


You were able to confirm this too? At least we're narrowing it down.


Network usage, yes? At what point is that happening for you? I have two encoding servers but they are local so that might be why I'm not seeing those spikes?

Yes I was able to confirm it.

[FuzzyNutz]

Are you running Logitech Software. See post here: https://forum.doom9.org/showpost.php?p=1879997&postcount=17029

Alternatively update Logitech Software here: https://forum.doom9.org/showpost.php?p=1880045&postcount=17034

Hope this helps..

This worked for me. Starting in December of 2018, RB would not close cleanly. Today I exited my Logitech gaming software, which I use for my G602 mouse and usually have running in the background, to my amazement, RB closes cleanly. I've downloaded the recommended alternative software "G Hub", but have not tried it yet. Fortunately, the problematic software, "Gaming Software", does not need to run in the background, cuz the settings are saved to my mouse's internal memory.

Thank you.

[FuzzyNutz]

Regarding flashing frames. What codec is used in source file? Mpeg2,avc,hevc?

AVC for some; maybe all. (1080p 23.976fps H264 blu-ray sources)

[FuzzyNutz]

Can a modern solid-state drive endure daily use of blu-ray size projects with RipBot264? If so, it would be a way to reduce wait times for demuxing/muxing and job loading.

[byteshare]

Can a modern solid-state drive endure daily use of blu-ray size projects with RipBot264? If so, it would be a way to reduce wait times for demuxing/muxing and job loading.
I use an SSD for my temp drive and for remuxing files afterwards with audio/subs. So far put over 20TB of writes on it in about a year and it is doing well.
For sure speeds up some of the work.

[byteshare]

Just noticed the update from 8/20. Updated core from 8.17 to 8.20 (please consider changing the release number in the main window: 1.25.x)
Re-added the problem source videos as jobs.
Realized that my encoding servers never started.
I see the "Select SuperviseProcess.exe
In the window I see this:
[2019-08-22 11:21:04]
C:\RipBot\EncodingServer.exe /start /restart-if-no-progress /minimize /ip 0.0.0.0 /port 2000
(PID:3268) executed.
[2019-08-22 11:21:05] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:06] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:07] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:08] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:09] EncodingServer.exe (PID:3268) is responding.
[2019-08-22 11:21:10] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:11] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:12] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:13] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:14] EncodingServer.exe (PID:3268) is NOT responding.
[2019-08-22 11:21:15] EncodingServer.exe (PID:3268) is NOT responding.
...etc until the server restarts and keeps looping like that.
I've tried a reboot. I've tried killing my startup processes, I've tried closing everything I know to close.
I can't get the encoding server to start.
Non-DE mode starts and will try that in a bit. Running a StaxRip test since it uses the same filter to see if I get the flicker issue.
Update: Stax only got 20% through the file before giving up. RB in non-DE mode is still going and over 50% through.
Update:
- Okay in DE mode & non-DE mode, I got the flickering in Core 2019.08.17.
- StaxRip 2.0.3 doesn't seem to have the issue but playback (FPS) is wrong and it can't complete the whole file (~20% of the total frames)
+/- Non-DE mode (since encoding servers won't start for me) I'm not seeing the flickering in Core 2019.08.20...so it might be fixed (need more testing to feel confident)
+ In Handbrake I don't have the issue.

If Core 2019.08.20 is fixed that is great. Not sure if the index slowness issues was fixed as well since I can't get the encoding server to start.

Update-Update....I don't know why but the servers are starting now...I'll try DE mode in Core 2019.08.20
-NOT seeing the lwi indexes being created for chunks! :D

[FuzzyNutz]

I use an SSD for my temp drive and for remuxing files afterwards with audio/subs. So far put over 20TB of writes on it in about a year and it is doing well.
For sure speeds up some of the work.

What SSD are you using? I'm considering either a 2 or 4 Terabyte SSD to increase longevity.

[LigH]

Video conversion will mainly write large files with linear access. An SSD should like this kind of access with little wear.

[FuzzyNutz]

Video conversion will mainly write large files with linear access. An SSD should like this kind of access with little wear.

I hope you're correct. I'm concerned that the large amount of writing would reduce a SSD's lifespan faster than typical usage.

[Atak_Snajpera]

I hope you're correct. I'm concerned that the large amount of writing would reduce a SSD's lifespan faster than typical usage.

Typical MLC SSD has 3000 P/E cycles. After that number data retention in room temperature drops below 1 year.
https://www.anandtech.com/show/9248/the-truth-about-ssd-data-retention

I have already used all 3000 P/E cycles and my SSD still works
https://i.imgsafe.org/fe/fe6dee4d4d.png

[FuzzyNutz]

Update:
- Okay in DE mode & non-DE mode, I got the flickering in Core 2019.08.17.
- StaxRip 2.0.3 doesn't seem to have the issue but playback (FPS) is wrong and it can't complete the whole file (~20% of the total frames)
+/- Non-DE mode (since encoding servers won't start for me) I'm not seeing the flickering in Core 2019.08.20...so it might be fixed (need more testing to feel confident)
+ In Handbrake I don't have the issue.

If Core 2019.08.20 is fixed that is great. Not sure if the index slowness issues was fixed as well since I can't get the encoding server to start.

Update-Update....I don't know why but the servers are starting now...I'll try DE mode in Core 2019.08.20
-NOT seeing the lwi indexes being created for chunks! :D

My RB core date is 2019-08-17 and the flickering is still happening.

[FuzzyNutz]

Typical MLC SSD has 3000 P/E cycles. After that number data retention in room temperature drops below 1 year.
https://www.anandtech.com/show/9248/the-truth-about-ssd-data-retention

I have already used all 3000 P/E cycles and my SSD still works
https://i.imgsafe.org/fe/fe6dee4d4d.png

My rig runs 24/7. I move completed RipBot264 projects to mechanical hard drives. Retention when my system isn't running was not my focus, but thanks for the info.
I used the formula found here to estimate lifespan based on write usage: https://www.compuram.de/blog/en/the-life-span-of-a-ssd-how-long-does-it-last-and-what-can-be-done-to-take-care/

[byteshare]

My RB core date is 2019-08-17 and the flickering is still happening.
Update! At the very least 8.20 Core doesn't have the index rebuild issue for each chunk. I was going to run more test but fell asleep. Doing that now. At least 1 of 6 didn't get the flickering when on 8.17 it was getting it each time (ran test 3 times).

What SSD are you using? I'm considering either a 2 or 4 Terabyte SSD to increase longevity.
Correction, 30TB written. I have 4 different SSDs but I recommend the Samsung EVO line since they have one of the best warranties if you're really worried. I still use a physical drive for storage of source files.

[FuzzyNutz]

Update! At the very least 8.20 Core doesn't have the index rebuild issue for each chunk. I was going to run more test but fell asleep. Doing that now. At least 1 of 6 didn't get the flickering when on 8.17 it was getting it each time (ran test 3 times).


Correction, 30TB written. I have 4 different SSDs but I recommend the Samsung EVO line since they have one of the best warranties if you're really worried. I still use a physical drive for storage of source files.

I've tried deleting the "updater" and "update_log" files with hopes of nudging to the newest available update, but my core date is still 08-17 according to Windows Explorer. It shows as version 1.25.0.0.
When and if I do get RB to update the core beyond 08-17, will I need to reload projects that were loaded while the core was 08-17?

My OS and other software are on a 500G 970 EVO Plus NVMe M.2 and my RipBot264 projects are on an HDD. I'm considering using an 860 EVO 2.5" 4TB SATA III for RipBot264 projects. My completed RipBot264 projects are on HDD's.

[brumsky]

I've tried deleting the "updater" and "update_log" files with hopes of nudging to the newest available update, but my core date is still 08-17.
When and if I do get RB to update the core beyond 08-17, will I need to reload projects that were loaded while the core was 08-17?

My OS and other software are on a 500G 970 EVO Plus NVMe M.2 and my RipBot264 projects are on an HDD. I'm considering using an 860 EVO 2.5" 4TB SATA III for RipBot264 projects. My completed RipBot264 projects are on HDD's.

I have several SSDs that are very old, one is an OCZ Vertex2 which came out 6+ years ago. It was back before SSDs were maxing out the SATAIII bus - that just shows you how old it really is!

https://imgur.com/rw39jSj

Both of the 850 evos are 250GB SSDs. I used them for a year or two to run a DB that had a ton of writes. Then for past few years I've been using them as a temp dir for ripbot and Plex DB.

The OCZ drive is still going strong. it is currently my ISO store on a PVE cluster. It just won't die... lol

I really want to get a MyDigitalSSD BPX Pro. The 1TB version is warrantied for 1,660TBW. Yes you read that right 1.6PBs of writes. It normally sells for 110-120 USD. They are hard to find now though, my guess is they are going to release a new SSD line soon. the BPX Pro isn't the fastest but you have to love that TBW warranty!!


EDIT:
By the way everything is working perfect now!! Thank you all for the hard work to fix this!

[FuzzyNutz]

I've tried deleting the "updater" and "update_log" files with hopes of nudging to the newest available update, but my core date is still 08-17 according to Windows Explorer. It shows as version 1.25.0.0.
When and if I do get RB to update the core beyond 08-17, will I need to reload projects that were loaded while the core was 08-17?

How can I force RB to update to the newest version?

[byteshare]

How can I force RB to update to the newest version?
Edit the update.ini in the RipBot folder. Change the LastCheck= to something from last year, save, reopen RB, check the Updates folder and you should be seeing new files come in. I don't know the threshold but that works for me.

[FuzzyNutz]

Edit the update.ini in the RipBot folder. Change the LastCheck= to something from last year, save, reopen RB, check the Updates folder and you should be seeing new files come in. I don't know the threshold but that works for me.

Didn't work for me.

[nekrosoft13]

Edit the update.ini in the RipBot folder. Change the LastCheck= to something from last year, save, reopen RB, check the Updates folder and you should be seeing new files come in. I don't know the threshold but that works for me.

doesn't work

[nekrosoft13]

Typical MLC SSD has 3000 P/E cycles. After that number data retention in room temperature drops below 1 year.
https://www.anandtech.com/show/9248/the-truth-about-ssd-data-retention

I have already used all 3000 P/E cycles and my SSD still works
https://i.imgsafe.org/fe/fe6dee4d4d.png

Goodram, i see you buying local ;)

[nekrosoft13]

I hope you're correct. I'm concerned that the large amount of writing would reduce a SSD's lifespan faster than typical usage.

try to stick with MLC and TLC (at the worse) avoid the new cheap QLC drives.

QLC are becoming really popular due to cheap prices, which soon could be a problem and MLC and TLC could disapear from consumer products.

In eyes of consumer prices matters the most.

MLC right now is pretty much enterprise only.

[Atak_Snajpera]

Yeah! Avoid QLC like plague! They are very slow outside SLC cache (less than 80MiB/s!) and also P/E is around 100.
https://hardforum.com/threads/crucial-p1-1tb-brutally-slow-and-hot.1982110/

[byteshare]

Didn't work for me.
doesn't work
Huh, what I just did and I see another update today to the EncodingClient, EncodingServer, RipBot264, and update exes
Not sure what changed though...
Update: oh, new options in settings for default decoder (LSMASH or FFMS2)
Thank you for the update and being a great Dev.

[FuzzyNutz]

Huh, what I just did and I see another update today to the EncodingClient, EncodingServer, RipBot264, and update exes
Not sure what changed though...
Update: oh, new options in settings for default decoder (LSMASH or FFMS2)

I can't get RB to update on demand. Deleting the "update_log" and/or "updater" files won't work. Changing the "lastcheck" to an older date in the "updater" file won't work. Replacing the core to 1.24 won't work. Run RB as administrator won't work. I have "Use Auto-update" checked in the RB Advanced Settings. RB updates when it feels like it. Grrrr.

[byteshare]

I can't get RB to update on demand. Deleting the "update_log" and/or "updater" files won't work. Changing the "lastcheck" to an older date in the "updater" file won't work. Replacing the core to 1.24 won't work. Run RB as administrator won't work. I have "Use Auto-update" checked in the RB Advanced Settings. RB updates when it feels like it. Grrrr.
First, you should already be running RipBot as admin for it to work right in most cases.
I've been manually changing the last LastCheck in the updater.ini for years.
Try this:
Confirmed "Use Auto-update" is checked > Close RipBot > Open the updater.ini in notpad > Change the LastCheck from something like "LastCheck=2019-08-23 10:06:22" to "LastCheck=2016-08-23 10:06:22" > Save the file > open RipBot as admin > Check the update folder: \RipBot\Updates > once no new files come and and the files are there are no longer growing in size > Close RipBot > Open RipBot as admin and the update should start to install.
You might need to repeat those steps a few times to get completely up to date depending on your current version.

The above method does work, as I've used it for years on more than one machine. So, if it is not working for you than something is either being done wrong or something else is wrong on your setup.

If you are not seeing an update file quickly being made in the folder when you first open RipBot check that your settings are actually correct.

If you are not on Core 08.23 and you are not seeing files be downloaded you might check your firewall settings for RipBot (ie non-local connections are not blocked).

[FuzzyNutz]

First, you should already be running RipBot as admin for it to work right in most cases.
I've been manually changing the last LastCheck in the updater.ini for years.
Try this:
Confirmed "Use Auto-update" is checked > Close RipBot > Open the updater.ini in notpad > Change the LastCheck from something like "LastCheck=2019-08-23 10:06:22" to "LastCheck=2016-08-23 10:06:22" > Save the file > open RipBot as admin > Check the update folder: \RipBot\Updates > once no new files come and and the files are there are no longer growing in size > Close RipBot > Open RipBot as admin and the update should start to install.
You might need to repeat those steps a few times to get completely up to date depending on your current version.

The above method does work, as I've used it for years on more than one machine. So, if it is not working for you than something is either being done wrong or something else is wrong on your setup.

If you are not seeing an update file quickly being made in the folder when you first open RipBot check that your settings are actually correct.

If you are not on Core 08.23 and you are not seeing files be downloaded you might check your firewall settings for RipBot (ie non-local connections are not blocked).

What is the latest version of the core? I have 1.25.0.0.

[byteshare]

What is the latest version of the core? I have 1.25.0.0.
Core 2019.08.23 You have to look in the Settings > Tools > Installed Tools > Core
The RipBot version in the main window doesn't change with updates always, so it will still read 1.25.0
Personally the Window name should just be RipBotx264
and the version should be pulled from something else and shown in the main GUI, so that when updates are pushed out only changing the updater version or an .ini file would be required rather than recompiling GUI or something like that so even when filters are updated we'd see a version change.

[FuzzyNutz]

Core 2019.08.23 You have to look in the Settings > Tools > Installed Tools > Core
The RipBot version in the main window doesn't change with updates always, so it will still read 1.25.0
Personally the Window name should just be RipBotx264
and the version should be pulled from something else and shown in the main GUI, so that when updates are pushed out only changing the updater version or an .ini file would be required rather than recompiling GUI or something like that so even when filters are updated we'd see a version change.

I'm up to date. Thanks.
I'll chime in once I know if the frame flickering seems resolved.

[FuzzyNutz]

I'm up to date. Thanks.
I'll chime in once I know if the frame flickering seems resolved.

I'm still getting the flickering with core 08-23.

[byteshare]

I'm still getting the flickering with core 08-23.
Huh...I'm not, but you can switch back to FFMS2 if you weren't having an issue with that one.
Since 8.20 I wasn't having the issues since the Encoding Servers stopped trying to recreate the index files...at least on the 6 files that I had flickering between the 2-4 encodes for each with versions since the LSmash addition but before 8.20.

[FuzzyNutz]

Huh...I'm not, but you can switch back to FFMS2 if you weren't having an issue with that one.
Since 8.20 I wasn't having the issues since the Encoding Servers stopped trying to recreate the index files...at least on the 6 files that I had flickering between the 2-4 encodes for each with versions since the LSmash addition but before 8.20.

I'm not using DE. What's FFMS2?

[byteshare]

I'm not using DE. What's FFMS2?
Using DE mode doesn't matter, since 8.20 the way indexing works is different. I confirmed the flickering in DE and non-DE and then it working in both.
FFMS2 is the way before LSmash. You can change the default decoder in the settings from LSmash to FFMS2 for all codecs or just the ones you want.
Even though LSmash is working I switched back to FFMS2 now that we have the option since creating jobs is faster and I wasn't having issues before LSmash.

[FuzzyNutz]

Using DE mode doesn't matter, since 8.20 the way indexing works is different. I confirmed the flickering in DE and non-DE and then it working in both.
FFMS2 is the way before LSmash. You can change the default decoder in the settings from LSmash to FFMS2 for all codecs or just the ones you want.
Even though LSmash is working I switched back to FFMS2 now that we have the option since creating jobs is faster and I wasn't having issues before LSmash.

Where is the LSmash/FFMS2 setting? What did you confirm about the flickering?

[byteshare]

Where is the LSmash/FFMS2 setting? What did you confirm about the flickering?
You can change the default decoder in the settings (Main) from LSmash to FFMS2 for all codecs or just the ones you want, or you can even do it after the fast if you right click on a job and select FFMS2.
I confirmed it by going through both the parts I had marked as consistently having issues and skipping through 5s at a time on 6 files that had issues on every encode I did on them (2-4 times depending on the file).

[nekrosoft13]

Using DE mode doesn't matter, since 8.20 the way indexing works is different. I confirmed the flickering in DE and non-DE and then it working in both.
FFMS2 is the way before LSmash. You can change the default decoder in the settings from LSmash to FFMS2 for all codecs or just the ones you want.
Even though LSmash is working I switched back to FFMS2 now that we have the option since creating jobs is faster and I wasn't having issues before LSmash.

switched to FFMS2 as well, will see if it fixes the flickering.

[FuzzyNutz]

You can change the default decoder in the settings (Main) from LSmash to FFMS2 for all codecs or just the ones you want, or you can even do it after the fast if you right click on a job and select FFMS2.
I confirmed it by going through both the parts I had marked as consistently having issues and skipping through 5s at a time on 6 files that had issues on every encode I did on them (2-4 times depending on the file).

No LSmash/FFMS2 setting exists on my UI, "main".
What is the "fast"?
What is the "it" in "I confirmed it"?