View Full Version : RipBot264 v1.18.3 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY
byteshare
18th September 2018, 12:06
I think that this time problem might be on your side. Before releasing I've tested new encoding server (1.12.1) on virtual machine (win10) using 16 running server (extreme stress test) many times. I have never experienced this kind of issues. Well to be honest I haven't noticed any problems at all. At this point I can only advise you to check what is happening under the hood. Open Process Hacker and check if ffmpeg.exe or/and x265_x65.exe is still in memory. I suspect that ffmpeg.exe just died and stopped serving frames to an encoder.
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?
byteshare
18th September 2018, 12:08
Hey guys,
I'm new to the party, acquired a capable Drive and am know ripping, remuxing and partially compressing my BluRays and UHD's.
Thanks to RipBot and distributed encoding, x265 is now feasable for normal people as well.
I'm just baffled by the results im getting:
The resulting Bitrate while having an constant CQ vastly differentiates with the preset.
For example, i reencoded the first 20 Minutes of a 4K remux, @ 3840x1608, keeping 10bit and HDR, assuming that this should be x265 strongest disciplin, with the following results:
-cq 17, slower :20,2MBps
-cq 17, default: 14,5MBps
-cq 17 ultrafast: 4,6MBps
Of course they look very different.
I redid the same thing with Handbrake, yielding similar results.
Shouldn't cq encoding always keep the same visual quality, and the slower speeds allow for better compression, meaning that the tendency should be the other way around. At least thats the way it was with x264.
Maybe someone could give me a rundown of what I'm not understanding, or respectively what I'm dowing wrong.
Thanks a lot
The presents don't just affect compression, they also affect quality because they use different settings to either speed up or slow down things to make better predictions.
Very few things with encoding is linear.
sneaker_ger
18th September 2018, 12:08
Shouldn't cq encoding always keep the same visual quality
As you found out it doesn't work that way. Simple as that.
Atak_Snajpera
18th September 2018, 12:58
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?
So like I thought. ffmpeg.exe silently crashed or just stopped serving frames to an encoder. Since ffmpeg.exe is just a messenger I think that something wrong is happening on avisynth level (some filter is behaving badly)
guest
18th September 2018, 13:02
They are still in memory. I've had this happen on 3 different machines, of which 2 are Win7 and 1 Win10.
Would it be possible to add in a feature if ffmpeg hasn't responded in say 120s to kill it and restart the server?
Atak,
I understand that you'd want to test, and test before release, which I commend, but because it can be so random, it could take days of testing to have a stall.
byteshare,
Your suggestion, (if possible), would be excellent, it would look after itself :)
Atak_Snajpera
18th September 2018, 13:05
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
guest
18th September 2018, 13:10
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
Atak,
98% of my encodes are x264 mkv's, and I don't use a lot of filters (other than default), occasionally, MDeGrain2, and HQD3D.
But when the stall is a Server, wouldn't that be something a little different (just asking).
byteshare
18th September 2018, 13:58
It would be better if you could find some pattern. Does it happen on specific file source codec (MPEG-2,MPEG-4 ASP,MPEG-4 AVC,HEVC and so on). The same with avisynth filters.
I don't know what the pattern is but I also don't know what was causing FFMPEG to crash before you changed the EncodingServer to restart on a crash.
Every time it crashes, it will work if I try it again, so I don't know how to reproduce the issue.
I haven't tried it, but I'm sure if I tried the same encode that had a crash it wouldn't have the same issue again.
I have been using the same avisynth filters on a lot of encodes recently and it is rare to have a crash/lockup but a pain when I'm not checking my encodes every few hours, since it could happen at any moment or it could also take days to encounter.
Danette
18th September 2018, 23:32
Try clicking in the seek bar and then clicking play for the error message
Thanks, that worked for reading the error messages. So, onto the messages.
If I try to load this (from the previous post):
Import("C:\Users\Main\Desktop\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Scripts\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\yadif.dll")
video=AssumeTFF(video)
video=QTGMC(video,Preset="Very Slow")
The error message simply states that "Import: couldn't open" QTGMC-3.32.avsi. I get the same message if I try to load the same files that are included with RipBot263:
Import("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Scripts\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\RgTools\RgTools.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\nnedi3\nnedi3.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\masktools\masktools2.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\mvtools\mvtools2.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Yadif\yadif.dll")
video=AssumeTFF(video)
video=QTGMC(video,Preset="Very Slow")
How would you construct the script necessary to accomplish this QTGMC function?
byteshare
19th September 2018, 16:51
Thanks, that worked for reading the error messages. So, onto the messages.
If I try to load this (from the previous post):
Import("C:\Users\Main\Desktop\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Scripts\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins\yadif.dll")
video=AssumeTFF(video)
video=QTGMC(video,Preset="Very Slow")
The error message simply states that "Import: couldn't open" QTGMC-3.32.avsi. I get the same message if I try to load the same files that are included with RipBot263:
Import("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Scripts\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\RgTools\RgTools.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\nnedi3\nnedi3.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\masktools\masktools2.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\mvtools\mvtools2.dll")
LoadPlugin("C:\Program Files\RipBot264 v1.23.0.7\Tools\AviSynth plugins\Yadif\yadif.dll")
video=AssumeTFF(video)
video=QTGMC(video,Preset="Very Slow")
How would you construct the script necessary to accomplish this QTGMC function?
This is what it should look like for Medium.
Loadplugin("C:\RipBot\Tools\AviSynth plugins\RgTools\RgTools.dll")
Loadplugin("C:\RipBot\Tools\AviSynth plugins\nnedi3\nnedi3.dll")
Loadplugin("C:\RipBot\Tools\AviSynth plugins\masktools\masktools2.dll")
Loadplugin("C:\RipBot\Tools\AviSynth plugins\mvtools\mvtools2.dll")
LoadCplugin("C:\RipBot\Tools\AviSynth plugins\Yadif\Yadif.dll")
Import("C:\RipBot\Tools\AviSynth plugins\Scripts\QTGMC.avs")
video=QTGMC(video,Preset="Medium",FPSDivisor=2)
You're missing elements for Very Slow. You also need:
ffms2.dll, RepairSSE2.dll, RemoveGrainSSE2.dll, and FFT3DFilter.dll
You can read more here:
http://avisynth.nl/index.php/QTGMC
byteshare
19th September 2018, 20:43
Just wanted to say Thank you again for making the queue so much much more friendly. Moved several things around that would have taken at least 5 min, maybe more...did it in about 30s. Even moved some things that in the past I would have just left as is because I didn't want to spend the time.
Atak_Snajpera
21st September 2018, 19:06
I don't know what the pattern is but I also don't know what was causing FFMPEG to crash before you changed the EncodingServer to restart on a crash.
Every time it crashes, it will work if I try it again, so I don't know how to reproduce the issue.
I haven't tried it, but I'm sure if I tried the same encode that had a crash it wouldn't have the same issue again.
I have been using the same avisynth filters on a lot of encodes recently and it is rare to have a crash/lockup but a pain when I'm not checking my encodes every few hours, since it could happen at any moment or it could also take days to encounter.
Question to native english speakers.
https://i.postimg.cc/fLGHtJ52/Untitled-1.png
Does this sentence look good to you or would you prefer something else to describe that "stall" effect.
I don't know...
"Encoding hung"
"Encoding froze"
"Encoding stalled"
Would you also want see at what frame it stopped working?
byteshare
21st September 2018, 20:26
Question to native English speakers.
https://i.postimg.cc/fLGHtJ52/Untitled-1.png
Does this sentence look good to you or would you prefer something else to describe that "stall" effect.
I don't know...
"Encoding hung"
"Encoding froze"
"Encoding stalled"
Would you also want see at what frame it stopped working?
I would prefer "EncodingSever.exe has stopped working" (If I'm understanding the issue correctly)
Stalled, froze, hung, and stopped all come across clearly to me.
Glad to see you've found the issue.
guest
22nd September 2018, 00:54
I would prefer "EncodingSever.exe has stopped working" (If I'm understanding the issue correctly)
Stalled, froze, hung, and stopped all come across clearly to me.
Glad to see you've found the issue.
I'm with byteshare..
As for knowing what frame it stopped at, probably doesn't really matter to us user's, as long as it's easy to get it started again, unless that is going to be "automatic"...
And there's a new version of mkvtoolnix v26.
freakout
22nd September 2018, 08:39
G'day Atak,
First, thanks for RipBot. It's an incredibly useful app that makes my life easier on a daily basis.
I have two issues with distributed encoding that sound simple to resolve on paper. I couldn't find anyone else referencing them in this thread, so hopefully I'm not wasting your time here.
(1) Since Microsoft have removed HomeGroups from the latest version of Win10, I've frequently had a problem where encoding servers will tell me "File path does not exist!" when the client tries to connect to them. It can usually be revolved by a combination of hard restarts or restarting the Peer Networking processes.
The issue appears to be because the servers are using the Windows computer names in the path, rather than their IP addresses. If I try to browse the machines by name in the File Explorer, it fails. If I use the IP address, however, everything is A-OK.
Is there any possibility that we could have an option for the clients and servers to use IP addressing in the filepath rather than hostnames?
(2) Owing to VPN adapters and a mixture of wired and wireless connections, my various boxes have multiple network interfaces. Usually, unless I disable all others except the primary physical LAN interface, the RipBot server will bind to the wrong IP address/interface. Sometimes it will still work, but usually I will get "access violation" errors on the server when the client tries to start it.
Is there any possibility of getting an option to choose which network interface the server binds to?
Thanks very much for your time.
HehoChef
22nd September 2018, 17:48
Thanks for opening my eyes, and helping me keeping my mental sanity on the x265 presets.
On another note:
Since the latest update i have massive problems when it comes to videos containing eac3 audiotracks.
I'm setting up aac3-lc 5.1 256kbs as a target, and it fails everytime. It works though if i choose any other type of track, lesser quality (standard ac3 640kbps) or better (DTS and TRUEHD) tracks.
What kind of log or verbose would i have to submit so one can look into it?
@freakout: I myself had various Issues with the latest Windows Update, also in an addition with multiple NIC's, some of them virtual. It messed up all my shares and the standard windows firewall. I could'nt even ping the server without disabling it, and the server wouldn't even find its own shares if resolved by ip adress, not to talk about other machines getting into it. It solved for me by using a 1803 ISO to reinstall but with the latests updates, of course keeping all apps, files and setting. The needed reconfiguring was minimal compared to the hours of trouble shooting i invested beforehand. If your problem is a systemwide, as mine was, and not limited to ripbot, I would suggest that.
guest
23rd September 2018, 08:09
Hi Atak,
I had 3 more "stall's" today, and all of them were on the server, not the main client.
3 different chunks, and very different % of progress 97.1%, 2.3% & 10.8%, also couldn't stop the affected server with the "STOP" button, had to kill with Process Hacker.
These all occurred whilst doing the same encode, and the only filter I was using was MDegrain2.
Ryushin
23rd September 2018, 15:21
Just wanted to say Thank you again for making the queue so much much more friendly. Moved several things around that would have taken at least 5 min, maybe more...did it in about 30s. Even moved some things that in the past I would have just left as is because I didn't want to spend the time.
I second the much improved manipulation of the queue. I'm up to 731 in my job queue as I have not been able to get my job queue to zero in quite awhile. Still have about 100 or so jobs in my queue. Only thing I can suggest is adding an arrow that moves an item to the end or beginning to instead move 10 or so at a time, or just being able to hold down the single arrow and have it move quickly instead of having to click the arrow each time to move one.
byteshare
23rd September 2018, 18:58
Hi Atak,
I had 3 more "stall's" today, and all of them were on the server, not the main client.
3 different chunks, and very different % of progress 97.1%, 2.3% & 10.8%, also couldn't stop the affected server with the "STOP" button, had to kill with Process Hacker.
These all occurred whilst doing the same encode, and the only filter I was using was MDegrain2.
It might be by chance but I reduced the number of servers from 4 to 2 on one of my computers that was having stalls the most and I haven't had one in two days, which I was getting on almost every day.
I second the much improved manipulation of the queue. I'm up to 731 in my job queue as I have not been able to get my job queue to zero in quite awhile. Still have about 100 or so jobs in my queue. Only thing I can suggest is adding an arrow that moves an item to the end or beginning to instead move 10 or so at a time, or just being able to hold down the single arrow and have it move quickly instead of having to click the arrow each time to move one.
The ^^ (double arrow) moves any selection of items to the top or the vv to the bottom. It wasn't clear to me at first that you can select multiple items and move them at once wither with shift clicking or control clicking.
After figuring out all of the improvements I'm not sure the queue needs more work, other than if it wanted to be more noob friendly that allowed clicking and dragging but personally not something I need (Handbreak has this).
G'day Atak,
First, thanks for RipBot. It's an incredibly useful app that makes my life easier on a daily basis.
I have two issues with distributed encoding that sound simple to resolve on paper. I couldn't find anyone else referencing them in this thread, so hopefully I'm not wasting your time here.
(1) Since Microsoft have removed HomeGroups from the latest version of Win10, I've frequently had a problem where encoding servers will tell me "File path does not exist!" when the client tries to connect to them. It can usually be revolved by a combination of hard restarts or restarting the Peer Networking processes.
The issue appears to be because the servers are using the Windows computer names in the path, rather than their IP addresses. If I try to browse the machines by name in the File Explorer, it fails. If I use the IP address, however, everything is A-OK.
Is there any possibility that we could have an option for the clients and servers to use IP addressing in the filepath rather than hostnames?
(2) Owing to VPN adapters and a mixture of wired and wireless connections, my various boxes have multiple network interfaces. Usually, unless I disable all others except the primary physical LAN interface, the RipBot server will bind to the wrong IP address/interface. Sometimes it will still work, but usually I will get "access violation" errors on the server when the client tries to start it.
Is there any possibility of getting an option to choose which network interface the server binds to?
Thanks very much for your time.
I use IP addresses and put in the network login info in the settings under distributed encoding and haven't had any issues with Win10 or Win7
Atak_Snajpera
24th September 2018, 11:31
It might be by chance but I reduced the number of servers from 4 to 2 on one of my computers that was having stalls the most and I haven't had one in two days, which I was getting on almost every day.
For science you could also manually increase priority for EncodingServer.exe to HIGH using Task Manager/Process Hacker.
https://i.postimg.cc/Y9N691vz/Untitled-1.png
Who knows maybe 4 running encoders are just choking to death EncodingServer.exe when all have the same priority.
guest
24th September 2018, 12:22
For science you could also manually increase priority for EncodingServer.exe to HIGH using Task Manager/Process Hacker.
Who knows maybe 4 running encoders are just choking to death EncodingServer.exe when all have the same priority.
And would doing that, have the same result/affect as the server settings within Ripbot (eg:- RipBot264.ini)
"Server1CommandLine=/port 1000 /minimize /priority low"
Atak_Snajpera
24th September 2018, 12:53
/priority low sets EncodingServer.exe,ffmpeg.exe,x264.exe,x265.exe
so my suggestion is to manually change priority for encodingserver.exe from low to high. Rest of encoding processes (ffmpeg and so on) will be running in normal priority (because child processes can't inherit higher priority from parent).
guest
24th September 2018, 13:16
/priority low sets EncodingServer.exe,ffmpeg.exe,x264.exe,x265.exe
so my suggestion is to manually change priority for encodingserver.exe from low to high. Rest of encoding processes (ffmpeg and so on) will be running in normal priority (because child processes can't inherit higher priority from parent).
OK, well that sounds like a plan..
Just got newest auto update with new core & encoder build's.
So just confirm, (I just went into Process Hacker to have a look for myself), so once the priority is changed, then save for encoder.exe, to lock it in.
Ryushin
24th September 2018, 13:23
Updates just applied and I'm receiving a error when starting up the EncodingServer.exe. Error: List index out of bounds (0)
I've updated two different servers and both are receiving the same errors.
guest
24th September 2018, 13:39
Updates just applied and I'm receiving a error when starting up the EncodingServer.exe. Error: List index out of bounds (0)
I've updated two different servers and both are receiving the same errors.
I had that error twice, a week or so ago, and it cleared out what jobs I had in the queue.
Haven't given the latest update a "proper" run.
Ryushin
24th September 2018, 13:45
I had that error twice, a week or so ago, and it cleared out what jobs I had in the queue.
Haven't given the latest update a "proper" run.
At least all my jobs are still there then. Man, I would have panicked to have lost the 100+ jobs. I least I could restore the virtual machine that holds the jobs from a snapshot.
byteshare
24th September 2018, 14:36
/priority low sets EncodingServer.exe,ffmpeg.exe,x264.exe,x265.exe
so my suggestion is to manually change priority for encodingserver.exe from low to high. Rest of encoding processes (ffmpeg and so on) will be running in normal priority (because child processes can't inherit higher priority from parent).
Will give it a shot and let you know.
Privateer5000
24th September 2018, 18:16
Updates just applied and I'm receiving a error when starting up the EncodingServer.exe. Error: List index out of bounds (0)
I've updated two different servers and both are receiving the same errors.
Same Problem here. But i have no Jobs in Queue. Get the Error when Ripbot starts and is trying to start up the Encoding Server.
byteshare
24th September 2018, 19:38
Same Problem here. But i have no Jobs in Queue. Get the Error when Ripbot starts and is trying to start up the Encoding Server.
I get this issue as well on one Win7 PC. It has to do with the new version of EncodingServer.exe, because the debug version and the old 1.12.0.0 runs without the error.
Stuck using the 1.12.1.0 debug version right now, since I didn't have a backup of the official 1.12.1.0
byteshare
24th September 2018, 19:48
For science you could also manually increase priority for EncodingServer.exe to HIGH using Task Manager/Process Hacker.
https://i.postimg.cc/Y9N691vz/Untitled-1.png
Who knows maybe 4 running encoders are just choking to death EncodingServer.exe when all have the same priority.
Before I do this, I noticed this: blob:https://imgur.com/7b61a4a0-9b2e-44ad-b5c4-4fd14c10713a
This is a Win10 Machine, the same one that I went from 4 to 2 encoding servers. Not sure why it stalled.
Running the Priority High change now...
Danette
25th September 2018, 02:24
Hi Danette,
Well, I just did a test for you, I loaded several episodes of a series I have, set a few options, and it loaded every file without issue.
However, as soon as I pressed Start, thats when the problems started, some avisynth error (should have taken a screenshot), so I tried another file, same error, so I imported another file, (not in batch mode), and it did the same thing.
Are you having any problems with just single movie jobs ??
So, what I tried was re installing the latest AviSynth that Ripbot has, and then tried again, and it all went as it should.
So do you know how to install AviSynth from the Ripbot Tools folder ??
In the main Ripbot folder, you'll see a folder called "Tools", go in there, then a folder called "AviSynth", go in there, there should be another 4 folders, and "install.cmd"...double click on that, and that will refresh / install not only the latest version of AviSynth, but all the required Microsoft Visual C++ versions.
So give that a shot, and see what happens.
Well ...the solution didn't hold. I'm back to the "Jobs Rejected" activity for batch jobs. Can't even try to solve the Avisynth loading issues at this point. Looking more and more like RipBot264 is really more useful for single jobs where multiple computers are involved. Batch functionality seems very buggy on my Win 7 desktop. MeGUI works like a champ for both batch processing and employing Avisynth script. I just prefer the RipBot264 layout.
If anyone is interested in trying to solve this, I'd be happy to to receive your help. As it is, whenever I try a simple batch job , every other file loaded (the even numbered jobs) results in a "Job Rejected" message. The log file states "I don't know what YV12 means" but, apparently, it does "know" what YV12 means because the odd numbered jobs process fine.
guest
25th September 2018, 02:42
I get this issue as well on one Win7 PC. It has to do with the new version of EncodingServer.exe, because the debug version and the old 1.12.0.0 runs without the error.
Stuck using the 1.12.1.0 debug version right now, since I didn't have a backup of the official 1.12.1.0
OK, well I can confirm that there is a serious problem with the latest update, every time I open Ripbot, the same error comes up, showing multiple error screens, and it doesn't matter if there are any jobs in the queue, or not.
http://www.mediafire.com/file/5y5qwnqakdry8da/1st_startup_of_newest_update.jpg/file
This is on W10 (1809) RS5.
Changing Encoder priority doesn't change anything either.
The only thing that does do anything is if you disable DE, which isn't really a good option :(
So definitely back to the drawing board !!!!!
Well, I have an interesting update to share..
I get this above error on both Windows 10 Pro (1809), and Windows Server 2016 Datacentre....which are both single cpu pc's. (No NUMA)
and the only way to get rid of the error is to go back to the previous build of encoder.exe.
However, the error does NOT occur on Windows 10 Enterprise (1809), but this pc is a dual "old" Xeon X5690 with NUMA Nodes enabled.
So I'm just trying to give some options to what might be the problem.
Haven't tried in on the W7 pc, yet.
Just tried it on my little DELL laptop, with some DE servers enabled, on W7...no problem. I get all the updates on this, and copy them around all the other pc's I've got.
OK, yet another update...just tried it on the W7 dual "old" Xeon pc, and has the same error :(
So you either have to do 1 of 2 things, replace the encoder.exe with previous, or disable DE.
slalom
25th September 2018, 13:30
Hi Atak
an error with the latest update, for the Encodingserver.exe
"List index out of bounds (0)"
byteshare
25th September 2018, 22:58
/priority low sets EncodingServer.exe,ffmpeg.exe,x264.exe,x265.exe
so my suggestion is to manually change priority for encodingserver.exe from low to high. Rest of encoding processes (ffmpeg and so on) will be running in normal priority (because child processes can't inherit higher priority from parent).
I did this but so far, I've only had the encodingserver.exe stall at starting and not during an encode. Will keep testing.
slalom
26th September 2018, 17:38
New update, new error
Established connection with client... 192.168.1.3:1003
ERROR! File \\192.168.1.3\RipBot264temp\job228\Chunks\21.cmd does not exist!
Encoding terminated.
Connection Closed Gracefully.
ERROR! File \\192.168.1.3\RipBot264temp\job228\Chunks\21.cmd does not exist!
Encoding terminated.
Looks like the client can't find the path to connect
Atak_Snajpera
26th September 2018, 17:52
Change Client ip
https://i.postimg.cc/4N3J1ZMk/Untitled-1.png
slalom
26th September 2018, 18:49
I only have one IP in that box, the local IP in each PC
byteshare
26th September 2018, 23:56
I did this but so far, I've only had the encodingserver.exe stall at starting and not during an encode. Will keep testing.
Newest version seemed to solve the starting EncodingServer.exe issue on my one PC. Seems to have solved the stalling (shuts down the EncodingServer.exe at some points) but I have to start the EncodingServer.exe again sometimes to get all of the servers going.
Doesn't seem to have fixed the not starting an encode (getting stuck at starting). Over all seems in a better place.
And now, for some reason, I can't connect from one computer to another, but I can when using the 1.12.1.0 Test Debug version. I've turned off Windows Firewall on both computers while testing this. Both are Windows 7 machines.
I think the newer version for some reason isn't registering the port correctly because if I start the Debug version either before or after the 1.12.2.0 it will still use the same ports. And I have tried a Reboot on both machine.
guest
27th September 2018, 02:06
Newest version seemed to solve the starting EncodingServer.exe issue on my one PC. Seems to have solved the stalling (shuts down the EncodingServer.exe at some points) but I have to start the EncodingServer.exe again sometimes to get all of the servers going.
Doesn't seem to have fixed the not starting an encode (getting stuck at starting). Over all seems in a better place.
And now, for some reason, I can't connect from one computer to another, but I can when using the 1.12.1.0 Test Debug version. I've turned off Windows Firewall on both computers while testing this. Both are Windows 7 machines.
I think the newer version for some reason isn't registering the port correctly because if I start the Debug version either before or after the 1.12.2.0 it will still use the same ports. And I have tried a Reboot on both machine.
Do you think this may have something to do with the relatively new feature shown in Atak's post #16136..."Client IP" ??
I've yet to try this update !!!
guest
27th September 2018, 06:23
Change Client ip
https://i.postimg.cc/4N3J1ZMk/Untitled-1.png
Will this have to be changed every time you open/re-open Ripbot, if you have multiple nic's/IP's ??
I think I've answered my own question...and yes, it does appear to remember :)
slalom
27th September 2018, 12:28
Will this have to be changed every time you open/re-open Ripbot, if you have multiple nic's/IP's ??
I think I've answered my own question...and yes, it does appear to remember :)
Do you see multiple IPs in this box?
I only see the PC's IP
Atak_Snajpera
27th September 2018, 12:37
run ipconfig.exe /all and show me what you got.
guest
27th September 2018, 13:13
Do you see multiple IPs in this box?
I only see the PC's IP
Well it depends if I'm connected to my LAN, and/or the web.
So to answer your ?, up to 3 !
slalom
27th September 2018, 13:38
run ipconfig.exe /all and show me what you got.
https://thumb.ibb.co/njkyP9/Screenshot_2018_09_27_15_31_47.jpg (https://ibb.co/njkyP9)
Not in English, but you will understand
Dual Gigabit, one port connected
and all my shares are working
byteshare
27th September 2018, 13:48
Do you think this may have something to do with the relatively new feature shown in Atak's post #16136..."Client IP" ??
I've yet to try this update !!!
Not sure really
Atak_Snajpera
27th September 2018, 14:29
https://thumb.ibb.co/njkyP9/Screenshot_2018_09_27_15_31_47.jpg (https://ibb.co/njkyP9)
Not in English, but you will understand
Dual Gigabit, one port connected
and all my shares are working
Can you open ripbot264temp folder via these commands in explorer?
\\192.168.1.3\ripbot264temp
\\Pavlos-PC\ripbot264temp
phred1
27th September 2018, 17:36
New update, new error
Connection Closed Gracefully.
ERROR! File \\192.168.1.3\RipBot264temp\job228\Chunks\21.cmd does not exist!
Encoding terminated.[/CODE]
Looks like the client can't find the path to connect
Same error for me. Running Encoding Client on a W10 machine with 3 NICs of which i currently only use 1. Also running a virtual W10 client + a virtual Switch on same machine as the EC.
Edit: solved it temporarily by reverting to old version.
Here is my ipconfig /all:
C:\Users\FvB>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : W8S
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : localdomain
Ethernet adapter NIC23:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physical Address. . . . . . . . . : 00-E0-81-C8-C7-31
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Ethernet 3:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection #3
Physical Address. . . . . . . . . : 00-E0-81-C8-C7-30
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter vEthernet (Default Switch):
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
Physical Address. . . . . . . . . : FE-15-87-DA-C4-CC
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::cc59:afbb:acfe:bb87%10(Preferred)
IPv4 Address. . . . . . . . . . . : 172.24.140.97(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.240
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 402527623
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-71-FD-1D-00-E0-81-C8-C7-30
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter vEthernet (vSwitch_FvB):
Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #2
Physical Address. . . . . . . . . : 00-E0-81-C8-C7-2F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::c44e:4c28:a595:b748%7(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.22(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : den 21 september 2018 22:25:14
Lease Expires . . . . . . . . . . : den 28 september 2018 10:25:34
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 385933441
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-71-FD-1D-00-E0-81-C8-C7-30
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter Ethernet 4:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TeamViewer VPN Adapter
Physical Address. . . . . . . . . : 00-FF-96-49-29-A1
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
I can view the EC directory contents by
\\W8S\ripbot264temp\
..but not by
\\192.168.1.22\ripbot264temp\
BTW, thanks for an awesome app!
slalom
27th September 2018, 18:45
Can you open ripbot264temp folder via these commands in explorer?
\\192.168.1.3\ripbot264temp
\\Pavlos-PC\ripbot264temp
You mean the address bar?
No and Yes respectively
slalom
27th September 2018, 23:12
Updated and working fine!
:thanks:
byteshare
28th September 2018, 16:41
Latest update fixed all of my connection and starting issues (opening an EncodingServer.exe)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.