View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
Atak_Snajpera
26th December 2019, 13:47
Is it a problem at my end, or is it something that you need to dig a little deeper into ??
This has nothing to do with my code. My code just executes .cmd file and then waits for spawned ffmpeg.exe and x264.exe/x265.exe. When they terminate my code next checks number of encoded frames and reports to encodingclient with proper command. Nothing extraordinary. I would try not to push CPU usage to absolute 100%.
guest
26th December 2019, 14:04
This has nothing to do with my code. My code just executes .cmd file and then waits for spawned ffmpeg.exe and x264.exe/x265.exe. When they terminate my code next checks number of encoded frames and reports to encodingclient with proper command. Nothing extraordinary. I would try not to push CPU usage to absolute 100%.
OK, but what if just 1 DE server uses 100%....how could it be cut back a little ??
Would a newer ffmpeg make any difference ??
Atak_Snajpera
26th December 2019, 14:09
OK, but what if just 1 DE server uses 100%....how could it be cut back a little ??
Would a newer ffmpeg make any difference ??
I mean ,do not run extra server if you already have 90%+ cpu usage. Another thing. Run EncodingServer in LOW priority instead of NORMAL.
guest
26th December 2019, 14:17
I mean ,do not run extra server if you already have 90%+ cpu usage.
Well, I noticed today (yesterday now), that with the custom MDegrain3 filter I'm using, REALLY max's everything out, and just 1 DE server per PC or NUMA node, pretty much ran @ 100%
Just saw your edit, so I will run at LOW, and see what that does
Atak_Snajpera
26th December 2019, 14:24
BTW. If you want to check if UMA is slower/faster than NUMA then you should compare speed only using that one PC. Do not look at some random chunks because some parts of the movie are just easier to compress (faster encoding speed).
guest
26th December 2019, 14:31
BTW. If you want to check if UMA is slower/faster than NUMA then you should compare speed only using that one PC. Do not look at some random chunks because some parts of the movie are just easier to compress (faster encoding speed).
:thanks: I think I'll stay with using NUMA.
That random test (in that screenshot), was a reasonable difference, even taking in to account what you said about different parts of a movie being easier to compress.
Atak_Snajpera
26th December 2019, 14:37
NUMA may be faster due to direct access to memory. In UMA threads have to communicate between sockets which is obviously much slower (higher delay and so on).
https://techdifferences.com/difference-between-uma-and-numa.html
guest
27th December 2019, 00:47
Do not abort. Instead wait for encoding server to finish encoding. There is high chance that at the end progress on encondingclient side will immediately change to encoded ...
Like I predicted...
Most likely ffmpeg.exe (decoder process) silently terminated prematurely because it couldn't get data from host machine.
I forgot to mention that I DID see a ffmpeg error pop up message on one of my servers that I'm running W8.1 on.
Something like "ffmpeg stopped responding" (or similar)
guest
27th December 2019, 06:58
I mean ,do not run extra server if you already have 90%+ cpu usage. Another thing. Run EncodingServer in LOW priority instead of NORMAL.
Well, yet another day of "testing", but there has been no related problems today.
I had one hiccup which I think was network related (posted error msg)
https://www.mediafire.com/file/qpbflkirvni5opl/strange_stoppage.txt/file
And to my surprise there was an Autoupdate waiting, so that was great. :thanks:
I didn't update my Client PC however, just in case it jeopardised the unfinished job from yesterday, didn't want that to go to waste.
Updated ALL the servers, changed the CPU Priority down to LOW.
So once I started yesterday's job, I slowly introduced the servers, noting their encoding speed's.
I also noticed that trying to start 2 servers on NUMA 0 & 1, didn't seem to work all that well, so I just used NUMA 0,
but then I noticed that basically only 1 CPU was working, and even the cooling radiators proved that one was working, the other was not.
So due to that, I progressively changed my older SMC boards back to UMA, and changed the priority to NORMAL and VARIABLE, and ran 1 DE server on each pc.
Oh, and that had the CPU's just "bouncing off" 100%....
Seemed to work quite well, both rad's were warm, encoding speed was up, so maybe thats the way to go, when giving them a heavy filtered encode to process.
But having said all that, would there be a way in Encoding Client, that when one chunk is complete (that was using say, NUMA 0), that the next chunk on that IP would switch over and use NUMA 1 (just to share the load over both CPU's during the encode, not just one doing all the work) ??
I might also try to use 2 different RipBot folders, and have one that was configured to these heavy filtering jobs, and used certain DE servers.
And have another, setup to use more and/or different DE servers & settings, for "lighter" loads.
So all in all, a pretty successful day (hopefully tomorrow is as good)
_________________________________________________________________________________________________
A couple question's about the update....I noticed "HDRtools"....how is that used / enabled ??
Also, under "Default Video Decoder", it's changed from Lsmash, FFMS2 & GPU, to just CPU & GPU ??
So is Lsmash the one and only, now ??
stryker412
27th December 2019, 17:10
Just finished my new build. Are there any settings I should enable/disable with this new system?
Ryzen 3700X
16GB RAM
1TB NVMe (Adata SX8200 Pro)
Nvidia RTX2070 Super
I'm testing with an UHD movie now. I set it to 10bit, CQ 18. Looks like it's going to take around a total of 6hrs. Does that sound right?
Atak_Snajpera
27th December 2019, 17:21
Just finished my new build. Are there any settings I should enable/disable with this new system?
Ryzen 3700X
16GB RAM
1TB NVMe (Adata SX8200 Pro)
Nvidia RTX2070 Super
I'm testing with an UHD movie now. I set it to 10bit, CQ 18. Looks like it's going to take around a total of 6hrs. Does that sound right?
GPU decoding may give you few percent speed boost...
guest
28th December 2019, 01:16
Just finished my new build. Are there any settings I should enable/disable with this new system?
Ryzen 3700X
16GB RAM
1TB NVMe (Adata SX8200 Pro)
Nvidia RTX2070 Super
I'm testing with an UHD movie now. I set it to 10bit, CQ 18. Looks like it's going to take around a total of 6hrs. Does that sound right?
Hey stryker412,
That's great you have a nice new system up and running (slightly envious).
So, tell us a little more about your "test" encode...
Whats the movie ??
What other settings are you using, filters, are you able to use DE ??
It all makes a difference.
stryker412
28th December 2019, 04:02
I used Wreck it Ralph since it was a shorter film. I didn't change any settings other than bump CQ from 20 to 18. The final file was only 4.8GB which seems a little small for an HD10 movie. I also only used the DD track as it seems TrueHD has issues on my system. Plus, I only have a 5.1 setup anyway.
Is GPU decoding only in the ini file settings? I didn't see it in the GUI settings.
guest
28th December 2019, 04:31
I used Wreck it Ralph since it was a shorter film. I didn't change any settings other than bump CQ from 20 to 18. The final file was only 4.8GB which seems a little small for an HD10 movie. I also only used the DD track as it seems TrueHD has issues on my system. Plus, I only have a 5.1 setup anyway.
Is GPU decoding only in the ini file settings? I didn't see it in the GUI settings.
So is that 1080p or 2160p (4K) version you're "playing" with ??
It does seem a little on the small side, maybe you could check it with Mediainfo (which can be found in the Ripbot Tools folder, or you can download & install it, very handy).
How big is the original ??
Yes, I know what it's like to have TrueHD issues, I convert mine to DTSHD-MA (bit of a process).
So how long did the job take, finally ??
So here's where you change the Decoder settings (in the latest build of RB) :-
https://www.mediafire.com/view/kxl01wv9awvky0k/Default_Video_Decoder.jpg/file
stryker412
28th December 2019, 04:44
So is that 1080p or 2160p (4K) version you're "playing" with ??
It does seem a little on the small side, maybe you could check it with Mediainfo (which can be found in the Ripbot Tools folder, or you can download & install it, very handy).
How big is the original ??
Yes, I know what it's like to have TrueHD issues, I convert mine to DTSHD-MA (bit of a process).
So how long did the job take, finally ??
So here's where you change the Decoder settings (in the latest build of RB) :-
https://www.mediafire.com/view/kxl01wv9awvky0k/Default_Video_Decoder.jpg/file
Sorry this was 4K resolution. The original is 36GB.
How can I get version 1.25? I still have 1.24 which is why I wasn't seeing those options. All the links on videohelp and the first post here are still for 1.24.
guest
28th December 2019, 05:17
Sorry this was 4K resolution. The original is 36GB.
How can I get version 1.25? I still have 1.24 which is why I wasn't seeing those options. All the links on videohelp and the first post here are still for 1.24.
OK, well that's sort of strange it's only 4.8Gb.
You didn't resize it, did you ?? Is it still 4K res., 3840 x 2160.
So how long did it take ??
If you're still on 1.24.0, you must not have Auto-update enabled, enable it, (refer to screenshot in previous post) then close RB, then re start it, if you're connected online it will download all the updates it needs (yes Auto-update is working fine again).
Wait a couple of minutes, then check the "update_log.txt", or in the "Updates" folder, to check if there is any files in there.
Then all you need to do is close RB down again, re start, it will automatically update itself, and there you have it.
stryker412
28th December 2019, 17:15
No it was not resized.
stryker412
28th December 2019, 17:27
GPU decoding may give you few percent speed boost...
I'm actually getting the opposite. On GPU, I'm averaging 4-5FPS and on CPU 7-8.
GZZ
28th December 2019, 21:28
Might have found the issue with the info.txt missing.
If I use batch mode and have a custom filter with a UNC path to the tools folder (in this case for MDegrain) in my shared folder, then the script fail if the tools folder is missing, but Ripbot fail to see this and just continue without an error.
I did a video (Screen capture). Please have a look at it: http://gofile.me/6GaFo/v7OO0kwJ
If GetInfo.avs is runned multiple times, then the file (info.txt) is not overwritten, but data is appended to the file.
Atak_Snajpera
28th December 2019, 21:56
Why do you use network paths in Avs?
GZZ
28th December 2019, 22:01
Why do you use network paths in Avs?
I been using it for a long time. If I add the direct path to my custom script, then it didnt work on my DE server because the path didnt exists.
I added this to a custom script:
Loadplugin("\\DESKTOP_8700K\RipBot264temp\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)
If I add it with a direct path to the non-shared folder then it didnt work . My script was created 18-03-2018, so maybe things have change since then.
But do I add this path: e:\RipBot264v\Tools\AviSynth plugins\mvtools\mvtools2.dll
then it will fail on DE server, as it dont know the above path.
But maybe your program replace custom script path as it does for other path in avs script ?
Atak_Snajpera
28th December 2019, 22:08
1) put your plugins to tools/avisynth plugins
2) in your custom script load plugins using regular paths
EmcodingClient will copy all plugins you put to that folder and change paths in Avs to network Path automatically.
GZZ
28th December 2019, 22:19
1) put your plugins to tools/avisynth plugins
2) in your custom script load plugins using regular paths
EmcodingClient will copy all plugins you put to that folder and change paths in Avs to network Path automatically.
I see
1) I have the file in the e:\RipBot264v\Tools\AviSynth plugins\Scripts\Custom\ or else It wouldnt be under custom script in your application.
2) I will change the UNC path to regular path, this will solve the batch issue when the tools folder dosnt exists on import.
guest
29th December 2019, 00:46
How can I get version 1.25? I still have 1.24 which is why I wasn't seeing those options. All the links on videohelp and the first post here are still for 1.24.
So, did you go ahead and update to the latest 1.25.0 ??
guest
29th December 2019, 01:17
Hi Atak, would you be so kind as to comment on these questions I asked back at :-
https://forum.doom9.org/showpost.php?p=1893954&postcount=18109
A couple question's about the update....I noticed "HDRtools"....how is that used / enabled ??
Also, under "Default Video Decoder", it's changed from Lsmash, FFMS2 & GPU, to just CPU & GPU ??
So is Lsmash the one and only, now ??
stryker412
29th December 2019, 03:38
So, did you go ahead and update to the latest 1.25.0 ??
Yes, I'm on the latest.
guest
29th December 2019, 09:55
Yes, I'm on the latest.
You're welcome.
BLKMGK
29th December 2019, 22:53
No it was not resized.
Not an unusual size IMO. It's an animated movie so there's much less detail and x.265 encode of this will crush it way down. It's odd how some regular videos will crush down too depending on the types of scenes. Denoising them will also bring file sizes down as the randomness gets removed.
BLKMGK
30th December 2019, 07:11
Had a lockup on my PC controlling distributed processing. Upon restart it pulled in an update, as a result I also updated my slave clients to keep everything on the same "version". Version still says 1.25.0 but now the 30 videos in my queue left over freak out when the job attempts to run. Anyone else seeing this? I see the video copy to the work folder and then all clients go haywire. I can successfully abort but right clicking and trying to get a log gives no results. If I run a chunk .cmd file on the controlling machine it begins to create a chunk just fine. For some reason I'm also unable to see the encoding server although it appears to start when I attempt a job, closing RipBot I have to terminate it manually now.
No idea what just happened but a system that's been working fine for quite awhile just ground to a halt.....
GZZ
30th December 2019, 08:25
Had a lockup on my PC controlling distributed processing. Upon restart it pulled in an update, as a result I also updated my slave clients to keep everything on the same "version". Version still says 1.25.0 but now the 30 videos in my queue left over freak out when the job attempts to run. Anyone else seeing this? I see the video copy to the work folder and then all clients go haywire. I can successfully abort but right clicking and trying to get a log gives no results. If I run a chunk .cmd file on the controlling machine it begins to create a chunk just fine. For some reason I'm also unable to see the encoding server although it appears to start when I attempt a job, closing RipBot I have to terminate it manually now.
No idea what just happened but a system that's been working fine for quite awhile just ground to a halt.....
What kind of error. Does it write "Cant find file ....\Info.txt, closing in 5 sec" just after it has copy the file ?
guest
30th December 2019, 11:03
Had a lockup on my PC controlling distributed processing. Upon restart it pulled in an update, as a result I also updated my slave clients to keep everything on the same "version". Version still says 1.25.0 but now the 30 videos in my queue left over freak out when the job attempts to run. Anyone else seeing this? I see the video copy to the work folder and then all clients go haywire. I can successfully abort but right clicking and trying to get a log gives no results. If I run a chunk .cmd file on the controlling machine it begins to create a chunk just fine. For some reason I'm also unable to see the encoding server although it appears to start when I attempt a job, closing RipBot I have to terminate it manually now.
No idea what just happened but a system that's been working fine for quite awhile just ground to a halt.....
That is one major disadvantage of having "Auto update" enabled on your main encoding client, isn't it ?!?!?
As there is no "warning" that you're getting an update, it's generally too late, when you realise there's been one.
I have RipBot installed on a laptop ONLY to get the updates to it first, then I will manually update each other RB pc I have, as I see fit.
And that way, I can also document & archive all the updates.
And another thing is, I NEVER update a Client that has a queue of Jobs, as "sure as egg's" there will be something slightly different in the code of the updates that will cause this type of problem.
I think you'll just have to go thru and "refresh/reload" EVERY job :(
BLKMGK
30th December 2019, 14:34
What kind of error. Does it write "Cant find file ....\Info.txt, closing in 5 sec" just after it has copy the file ?
Nope, it acts like it's goiong to encode per usual but all of the clients attempt a connect, fail, try again, and keep cycling over and over. I get the failure to find info.txt occasionally too but I think corrupt files or files that have too many subtitles or whatever cause this - remuxing them with MakeMKV solves this sometimes. Nothing I've tried has solved the current problem and I regret not having made a backup of my previous set of files <sigh>
BLKMGK
30th December 2019, 14:53
That is one major disadvantage of having "Auto update" enabled on your main encoding client, isn't it ?!?!?
As there is no "warning" that you're getting an update, it's generally too late, when you realise there's been one.
I have RipBot installed on a laptop ONLY to get the updates to it first, then I will manually update each other RB pc I have, as I see fit.
And that way, I can also document & archive all the updates.
And another thing is, I NEVER update a Client that has a queue of Jobs, as "sure as egg's" there will be something slightly different in the code of the updates that will cause this type of problem.
I think you'll just have to go thru and "refresh/reload" EVERY job :(
I generally only run RipBot on one machine and just the Encoding Server on the others until I need an update but when I saw this one update I updated the others to keep them in synch - not having a version number that's worth anything is frustrating BTW. If simply updating the jobs solved this at least I'd have a path forward and could batch the files then edit the jobs but I tried redoing a job with one of the smaller files - nope after waiting ten minutes for it to be pulled apart and indexed it too FAILED with the same behavior. I don't understand why the files are pulled apart before processing, it's a time consuming step to say the least.
Just tried it again with a smaller file that I'd had queued up - fails with "no info.txt file". The file exists and contains the exact same data as the previous one generated with working code.
I'll see if I can pull my old binaries from backup tonight late when I get home. Hopefully I'm not the only one who sees these errors and this gets sorted <sigh>. I cannot even really offer much to troubleshoot because no useful logs appear to be generated. Below is all I get and exactly NOTHING has changed except RipBot binaries. One minute working, the next nope!
'\\XXXXX\XX\XXXX\XXXX\new'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
C:\Windows>"E:\Software\RipBot\EncodingClient.exe" "C:\Temp\RipBot264temp\job31\job31_EncodingClient.meta"
'\\XXXXX\XX\XXXX\XXXX\new'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
mkvmerge v41.0.0 ('Smarra') 64-bit
Error: The file 'C:\Temp\RipBot264temp\job31\video.265' could not be opened for reading: open file error.
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
-------------------------
Elapsed Time: 00h:02m:13s
ImEverlasting
30th December 2019, 16:52
Hello,
So I've been using RipBot for a few months now, exclusively using Distributed Encoding. I have one Main PC (Master-PC, Windows 10 Home x64) and 5 headless PC (Slaves One through Five, Windows 10 Pro x64).
I'm assuming these problems started with the recent update to Core. The past week I was having issues with halts, like others have started above me, from the Slaves. Usually more so at the end an encode (Encoding Adventure Time so the encodes are short at 11 minutes long.) Sometimes two slaves will still be "encoding" when the halt happens. The only way to fix this was for me to kill the Encoding Client on the Master PC. A few days ago I was given an update on the Master and later updated all the slaves as usual, ending the Encoding Servers, starting RipBot.exe and letting auto-updater do it's thing.
Well, since then I've been getting 100% halts after EVERY encode. The Encoding Client is frozen, I can not bring it back up from the Task Bar, but when hovering my mouse over it, it does show 100% completion of the job. Right clicking does nothing. Attempting to "Abort" the encode causes RipBot to crash resulting in me having to kill both RipBot and Encoding Client from the Task Manager. Task manger shows 0% CPU/Disk/Network usage for RipBot /Encoding Client so I'm assuming it's just hanging in error, and not looping.
https://i.imgur.com/m5i8b4e.png
The Slaves all show they have finished with all conversions and the connection was ended;
Example from Slave One (all other show pretty much the same thing:)
7811|CLIENT <- SERVER| ENCODING_FINISHED
7812|CLIENT -> SERVER| OK
7813|CLIENT -> SERVER| GET_ENCODING_SUMMARY
7814|CLIENT <- SERVER| OK
7815|CLIENT <- SERVER| ENCODING_SUMMARY=192.168.1.101:1000 -> encoded 1444 frames, 5.53 fps, 2026 kbps;CHUNK=7;CPU=99;RAM=45;DECODER=0;ENCODER=99;OTHER=0;ENCODING_PRIORITY=normal;
7816|CLIENT -> SERVER| OK
7817|CLIENT -> SERVER| STANDBY
7818|CLIENT <- SERVER| OK
7819|CLIENT <- SERVER| SERVER_IDLE
7820|CLIENT -> SERVER| OK
As a side note, I have noticed that the Slaves are being put to sleep quite often and I even have the "shutdown" method set to "No Action", is there something else I'm missing?
https://i.imgur.com/pYTjP57.png
This morning I downloaded a completely fresh copy of RipBot from the link on the main page, and letting it auto-update on the master, then zipping the RipBot folder and distributing RipBot to the Slaves (to ensure all applications are the same version). I'm still having the same issues, and am at a loss. Does anyone have a possible 100% known working last version and link? Documentation is sparse and having to go back through 50+ pages of discussion to figure out where things went wrong seems daunting. Thanks.
slalom
30th December 2019, 17:20
Same problems here, servers hang randomly for no reason. Even if I abort the program, it can hang
Last version working flawlessly was before auto combining of chunks was introduced
It could run for days unattended
ImEverlasting
30th December 2019, 20:07
Same problems here, servers hang randomly for no reason. Even if I abort the program, it can hang
Last version working flawlessly was before auto combining of chunks was introduced
It could run for days unattended
^ Exactly my issue, the Slaves are encoding almost 24/7. I encode a lot of x265 HEVC material. But the past week or more I've had to baby sit and restart multiple times a day. Production is slowing to a halt. :P
GZZ
30th December 2019, 23:35
1) put your plugins to tools/avisynth plugins
2) in your custom script load plugins using regular paths
EmcodingClient will copy all plugins you put to that folder and change paths in Avs to network Path automatically.
Atak_Snajpera. I did what you asked me to do and I can now import the job with a regular path. But it wont work when served as a chunk to me DE server because it dosnt change the path!
See screenshot from DE server: https://imgur.com/upyA4BK
Below is my script from chunk 2.avs where you can see it dosnt change the path in the #Custom section as you said it would!
#MT
Import("\\DESKTOP_8700K\RipBot264temp\Tools\AviSynth plugins\Scripts\MTmodes.avs")
#PREFETCH_LIMIT=0
#VideoSource
LoadPlugin("\\DESKTOP_8700K\RipBot264temp\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("\\DESKTOP_8700K\RipBot264temp\job31\video.mkv",threads=0,cachefile="C:\Users\Henrik\AppData\Local\Temp\EncodingServer1\video.mkv.lwi")
#Deinterlace
#Decimate
#Crop
video=Crop(video,0,280,-0,-280)
#Resize
#Tonemap
#Levels
#Colours
#Denoise
#Custom
Loadplugin("e:\RipBot264v\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=800)
#Prefetch
video=Prefetch(video,8)
#After_Prefetch_Denoise
#After_Prefetch_Custom
#Borders
#Subtitles
#AudioSource
#Triming
#AVSameLength
video=Trim(video,2844,5771)
#ColorSpace
#Return
return video
Please tell me what Im doing wrong in context to what you said ?
guest
31st December 2019, 00:14
UNC paths are not supported. Defaulting to Windows directory.
I could be wrong, but isn't this a glaring problem ??
I'm sure that this was raised by GZZ just a couple of posts back #18119 - #18123.
Yes, backup's are great, in hindsight :(
guest
31st December 2019, 00:28
Atak_Snajpera. I did what you asked me to do and I can now import the job with a regular path. But it wont work when served as a chunk to me DE server because it doesn't change the path!
See screenshot from DE server: https://imgur.com/upyA4BK
Below is my script from chunk 2.avs where you can see it doesn't change the path in the #Custom section as you said it would!
Please tell me what I'm doing wrong in context to what you said ?
Import \\DESKTOP_8700K\RipBot264temp\Tools\AviSynth plugins
Loadplugin e:\RipBot264v\Tools\AviSynth plugins
Why don't these match ??
Why don't you try and put EVERYTHING in the same place ??
Atak_Snajpera
31st December 2019, 01:02
@gzz
Show me job31.avs and file with .meta extension
guest
31st December 2019, 01:51
Hello,
Does anyone have a possible 100% known working last version and link? Documentation is sparse and having to go back through 50+ pages of discussion to figure out where things went wrong seems daunting. Thanks.
Welcome to the forum....
I posted a slightly earlier build on page 889, post #17777, which might help you out.
ImEverlasting
31st December 2019, 03:00
Welcome to the forum....
I posted a slightly earlier build on page 889, post #17777, which might help you out.
Thanks for the welcome, Sorry to come in guns blazing with issues. Ripbot is a fantastic tool when it was working, just want to get things going again. :)
Sorry to ask but, how did you make a "custom" version, do you work on this project with Atak_Snajpera? I'm sorta of hesitant to download something from someone I'm unfamiliar with, especially when the zip file was just uploaded today :x
BLKMGK
31st December 2019, 03:04
I could be wrong, but isn't this a glaring problem ??
I'm sure that this was raised by GZZ just a couple of posts back #18119 - #18123.
Yes, backup's are great, in hindsight :(
It's always thrown those errors and it's always worked. I don't map drive letters for every share, there's not enough letters in the alphabet lol
Edit: Restored from backups to all clients, works like a charm. Turned OFF auto-updates so I guess I'll have to monitor here to see when changes occur. It promptly downloaded a pile of proposed updates too...
guest
31st December 2019, 03:27
Thanks for the welcome, Sorry to come in guns blazing with issues. Ripbot is a fantastic tool when it was working, just want to get things going again. :)
Sorry to ask but, how did you make a "custom" version, do you work on this project with Atak_Snajpera? I'm sorta of hesitant to download something from someone I'm unfamiliar with, especially when the zip file was just uploaded today :x
No, I posted it from a working build, just to help people in need.
I think the reason for it showing that I uploaded it today is, that I actually took it down, for a day or so.
Hey, you asked if anybody had a working version, and then you question it....:(
It's entirely up to you if you want to use it or not....I just know that at least 23 others have.
You're new, and I don't know you, either !!!
guest
31st December 2019, 06:18
It's always thrown those errors and it's always worked. I don't map drive letters for every share, there's not enough letters in the alphabet lol
Edit: Restored from backups to all clients, works like a charm. Turned OFF auto-updates so I guess I'll have to monitor here to see when changes occur. It promptly downloaded a pile of proposed updates too...
That's great that you got it working again :)
So do you know what build you're on now ??
I had a couple of self imposed problems this morning, but once I figured what was wrong, it's been going great now, for about 5 hours, and it's a stinking hot day here today (great way to finish 2019), and haven't had any lock ups or anything (very latest build, too).
And about the only little problem I am having is a couple of servers don't like to "talk" to the network, randomly (but I'm pretty sure it's the cables/plugs)
GZZ
31st December 2019, 08:04
@gzz
Show me job31.avs and file with .meta extension
Job31.avs file from \Temp\RipBot264temp\job31\
#MT
Import("E:\RipBot264v\Tools\AviSynth plugins\Scripts\MTmodes.avs")
#PREFETCH_LIMIT=0
#VideoSource
LoadPlugin("E:\RipBot264v\Tools\AviSynth plugins\lsmash\LSMASHSource.dll")
video=LWLibavVideoSource("E:\UHD_mkv\Angels and Demons_t00.mkv",cachefile="E:\Temp\RipBot264temp\job31\Angels and Demons_t00.mkv.lwi")
#Deinterlace
#Decimate
#Crop
video=Crop(video,0,280,-0,-280)
#Resize
#Tonemap
#Levels
#Colours
#Denoise
#Custom
Loadplugin("e:\RipBot264v\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=800)
#Prefetch
video=Prefetch(video,6)
#After_Prefetch_Denoise
#After_Prefetch_Custom
#Borders
#Subtitles
#AudioSource
Import("E:\Temp\RipBot264temp\job31\job31_a1.avs")
#Triming
#AVSameLength
#ColorSpace
#Return
job31_EncodingClient.meta
E:\Temp\RipBot264temp\job31
E:\RipBot264v
"E:\RipBot264v\Tools\ffmpeg\bin\ffmpeg.exe" -loglevel panic -i "E:\Temp\RipBot264temp\job31\job31.avs" -strict -1 -f yuv4mpegpipe - | "E:\RipBot264v\tools\x265\x265_x64.exe" --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --max-cll "2105,1007" --crf 18 --fps 24000/1001 --min-keyint 24 --keyint 240 --frames 199416 --sar 1:1 --profile main10 --output-depth 10 --ctu 64 --y4m --output "E:\Temp\RipBot264temp\job31\video.265" -
E:\UHD_mkv\Angels and Demons_t00.mkv
h265
1
GZZ
31st December 2019, 08:09
Import \\DESKTOP_8700K\RipBot264temp\Tools\AviSynth plugins
Loadplugin e:\RipBot264v\Tools\AviSynth plugins
Why don't these match ??
Why don't you try and put EVERYTHING in the same place ??
I have the application in folder: e:\RipBot264v\
and my temp folder is at e:\Temp\RipBot264temp\
The temp folder is the only shared folder for other machines to see.
It might be the reason the path isnt changed, as it dont match with the expected. But if this is the case, then Ripbot should warn about having the temp folder in a unsupported folder or something and guide me to where it should be located. This could lead to all kind og issues.
GZZ
31st December 2019, 08:14
I also had a chunk that stalled today on newest version of ripbot. Dont know if its related to what other people have written.
Got a screenshot up: https://imgur.com/Ful2QuA and https://imgur.com/h8PmYA3
Cant get anymore details. Seems like the EncodingServer is still expecting the chunk to finish and FFMpeg and X264_64 is a 0% cpu. So somewhere along the chain something broke.
Update: restarted the chunk and it reencoded it without issues.
Suggestion: Something with a deadlock timeout, if EncodingServer havent changed encoded frames for X min or sec, then it sends a command back to Encoding Client to restart the chunk.
guest
31st December 2019, 10:37
Suggestion: Something with a deadlock timeout, if EncodingServer havent changed encoded frames for X min or sec, then it sends a command back to Encoding Client to restart the chunk.
Forgive me if I'm wrong, but I'm pretty sure there is a "command" to do just that.../restart-if-no-progress
Mind you, I haven't had much luck with it.
And again, forgive me if I'm wrong, but have you got RipBot, the Temp folder, and the folder where you put your final encodes ALL on your E:\ drive ?? (just looking at your log files)
Atak_Snajpera
31st December 2019, 12:11
@gzz
1) code which replaces text is case sensetive! You wrote e: but IT should be E: in load plugin
2) If for some reason ffmpeg.exe still sits in memory with 0 % CPU then there is special switch to restart encoding automatically
EncodingServer.exe /restart-if-no-progress
Encoding will be restarted If encodingserver detects no CPU usage for ffmpeg.exe/x26x.exe for 1 minute.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.