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

[ReinerSchweinlin]

Emby is much like plex - it uses a server and a client... The upside of this concept is, that you can have one central media server and many clients connecting to them. Since plex and Emby are capable of real time transcoding content while streaming, you can have multiple machines with different capabilities in your setup. For example:

- I can view ALL of my library on any of my mobile phones all over the world - as soon as I have an internet connection fast enough for the quality I want to watch (transcoding is x264 in Plex, don´t know if Emby is up to x265).... If no internet is available, I can set plex up to download the videos in advance and store them on the fone to watch offline
- my TV has had several small media players (fire TV, Android TV Boxes, small NUCs with WIndows / Linux) which all had a Plex Client on it - so I can watch everythin in the lokal network
- If I am at work, I can watch my stuff

The transcoder autoamtically detects the bandwith of the connection, the playback capability of the client and - if needed - transcodes everything accordingly... Of course, transcoding is CPU-intensive, so havnig a small NAS for a few bucks and wanting to transcode 40mbit x264 4K videos is a no go... Any Intel Quick Sync machine or at least some higher Core2Duo machine is enough to have at least 720p with 4Mbit watchable - a 120 Euro Kaby Lake NUC easily transcodes several FUll HD Streams at once...

Most of my files are h265 high quality ac3/dts/etc..- so if one client only is capable of h264 and stereo AAC - no problem, Emby, Plex take care of this and transcode on the fly...

[gryph]

So there's been some talk about subtitles the last days, but this was about soft remux
- but since there's been no response to my earlier post about the bug when hardcoding subs, I'll try again

First, thank you so much for this program!
I've been using RipBot for years now.
However, for a long time now, there's been some sort of bug - havn't been able to find any reports of this, so here I go...
I use Ripbot to hardcode subtitles and set a fixed video bitrate.
However I have to edit every single subtitle file (.srt/.ass) with an extra line in the very end to assure I get the "original" last line of sub hardcoded.
Which ever program is handling the subtitles, is deleting the very last line in the process.
So adding a custom new last line have been my fix.
Not sure exactly when this started to happen - but it's been going on for a long long time (1 year+ at least I'd guess).
Prior this issue didn't occure and there was no need to add an extra line of subtitle.
I ofc. always keep Ripbot up-to-date. So question is, is there a bug somewhere in the program - or am I missing something?
(btw - I run on Windows 7 machines only)

Fingers crossed for a fix... would save me from having to edit every single subtitle file before encode.

Cheers

Anyone, other than me, having this issue?
Anyone having any clue to why this happens?
Anyone with any suggestion to fixing this?

Gryph

[gryph]

Hey Gryph,

So, are you using Ripbot just to incorporate subtiles ?? or are you filtering & adjusting files ??

If you're just after subtitling, I would suggest Handbrake, to either soft or hard code any sub's.

Hi there, and thanks for replying.
If you read my first post - the one I quote above... You'll read that I use Ripbot to hardcode subs and re-encode to a set bitrate.
I have looked at Handbreak (and others) but I really prefer Ripbot.
I use .ass subs only (Handbreak only support these if they are muxed into the mkv = 2x the work)- I convert .srt subs to .ass as I can play around with the style in .ass - which you can't in .srt
Anyways, like I said, the hardcoding used to work with no issues (long ago)... and it still does (kinda) except it deletes the very last line in the subtitle - hence me adding a fake last line to every single sub file.
So my guess is, there's must be some bug with the part of RipBot that hardcodes the subtitles.

Gryph

[Atak_Snajpera]

Hi there, and thanks for replying.
If you read my first post - the one I quote above... You'll read that I use Ripbot to hardcode subs and re-encode to a set bitrate.
I have looked at Handbreak (and others) but I really prefer Ripbot.
I use .ass subs only (Handbreak only support these if they are muxed into the mkv = 2x the work)- I convert .srt subs to .ass as I can play around with the style in .ass - which you can't in .srt
Anyways, like I said, the hardcoding used to work with no issues (long ago)... and it still does (kinda) except it deletes the very last line in the subtitle - hence me adding a fake last line to every single sub file.
So my guess is, there's must be some bug with the part of RipBot that hardcodes the subtitles.

Gryph

I've checked and all subtitles are shown on my PC. Can you provide some samples (subtitles) where this problem occurs.

[ReinerSchweinlin]

About Subtitles - it was me indeed beeing too blind to simply switch on the subtitle option - so I now have the subtitles in the encodes, all is fine...

How about audio tracks in batch mode? Seems only the first track is encoded.. If I manually add one encode job, I can deal with up to 3 Tracks. Am I again doing something wrong ? It would be totaly sufficient for me if simply all tracks would be encoded and kept with the same coded (e.g. having a source file with 5.1 dts, 2.0 ac3, etc... -> 5.1 AAC, 2.0 AAC.. all AAC).. Is this possible?

[userx]

Hello,

Since todays update the encoding servers wheren't shown in the taskbar. Encoding Client isn't able to connect to the local started servers.
Some 'new' SuperviseProcess.exe-windows are shown which brings me to the idea that somewhere the IP is missing.


....
[2018-12-14 14:56:32] EncodingServer.exe (PID:8276) is NOT responding.
[2018-12-14 14:56:32] EncodingServer.exe (PID:8276) has been killed. No response for 1 minute.
[2018-12-14 14:56:32] D:\Programme\Ripbot264\EncodingServer.exe /start /restart-if-no-progress /ip 0.0.0.0 /port 3000 (PID:5628) executed.
[2018-12-14 14:56:33] EncodingServer.exe (PID:5628) is responding.
[2018-12-14 14:56:34] EncodingServer.exe (PID:5628) is responding.
[2018-12-14 14:56:35] EncodingServer.exe (PID:5628) is responding.
[2018-12-14 14:56:36] EncodingServer.exe (PID:5628) is responding.
[2018-12-14 14:56:37] EncodingServer.exe (PID:5628) is responding.
[2018-12-14 14:56:38] EncodingServer.exe (PID:5628) is NOT responding.
...

It is possible to connect to remote servers which hasn't been updated up to now.


running Ripbot264 on W10 1809

[ReinerSchweinlin]

Which "switch" did you find ? :)

https://forum.doom9.org/attachment.php?attachmentid=16617&stc=1&d=1544798599

:)

[slalom]

About Subtitles - it was me indeed beeing too blind to simply switch on the subtitle option - so I now have the subtitles in the encodes, all is fine...

How about audio tracks in batch mode? Seems only the first track is encoded.. If I manually add one encode job, I can deal with up to 3 Tracks. Am I again doing something wrong ? It would be totaly sufficient for me if simply all tracks would be encoded and kept with the same coded (e.g. having a source file with 5.1 dts, 2.0 ac3, etc... -> 5.1 AAC, 2.0 AAC.. all AAC).. Is this possible?
After the batch is loaded, edit the job you want and go to audio 2 or 3 to add the track you want (#1 is the default track)
Personally, I rarely use it

[byteshare]

Got a stall, looks like the same sort of thing I was seeing before the update, but I don't really know what causes it so IDK:
https://imgur.com/a/1TjHaAe
Win10 x64 build 1803
AMD Ryzen 7 1700
I can't find the logs: SuperviseProcessLog.txt and EncodingServerLog.txt
I did a search of my C drive and looked in the C:\Temp, RipBot folder (would make more sense to me), and in the %TEMP%\ folder (in my case: C:\Users\USERNAME\AppData\Local\Temp)
Only thing I found was SuperviseProcess.exe in the temp folder

I couldn't turn off the Server 2 (Thread 2 in the screenshot). I was able to end task the Ffmpeg.exe and that kicked the server 2 into off mode, and then I was able to start it again. Server 1 started encoding.
Not sure how important it is but normally the Ffmpeg.exe and x265_x64.exe show as a child (underneath) the RipBot264 Encoding Server tree like this: https://i.imgur.com/4etbRzc.jpg
But before I ended the Ffmpeg.exe task it was in the background processes list. Hope this helps.
Had this happen for a 3rd time now...with sources that weren't having this issue really until the update. I believe something is worse now but it could just be random chance that the stall issue is happening more now than it had in a month.

[byteshare]

@byteshare, & @ReinerSchweinlin,

Hey guys,

I really appreciate your input & suggestions, but I have absolutely no need, or desire for a media streaming server setup.

I don't need to stream to multiple devices, and/or multiple rooms, and also having to put all media on a single "box", and have it going just so I can watch a movie on the TV, seems a waste of energy, IMO.

As for the subtitles (which is the only issue), once I have demuxed them from the movies (which most have), and convert & spell check them, I don't mux them back in, it only needs to be in the same folder/directory as the movie, with the same exact naming (accept for the .mkv, .srt of course).

Cheers

If you got a standalone player, such as a MiBox (Android TV) and used MX Player, VLC, Kodi, etc... you wouldn't have to do the extra work with subtitles and then you wouldn't have to deal with putting all of your media in one place for a Emby/Plex server...which would be less work for you and less money than buying a new TV for better subtitle support and/or avoiding burning in subs with RipBot (not that you do but that would be another alternative).

[byteshare]

So is this happening after the very latest auto update ??, I got another one yesterday !!

Encoding Server is now up to version 1.13.1.0 !!

I was about to edit my post to say, I just got the 1.13.1.0 update...so I hope this won't happen now, lol

[Ryushin]

Getting a new error after the latest update:

The program can't start because OpenCL.dll is missing from your computer. Try reinstalling the program to fix this problem.

Going to see if I can find the OpenCL.dll somewhere. The Dell video driver wont' have it for the servers and I doubt the virtual machines video driver would have it as well.

[Ryushin]

I installed the Xeon OpenCL Runtimes for Intel Processors from:
https://software.intel.com/en-us/articles/opencl-drivers
They make you register an account. That stinks.

So now I have opencl.dll and RB does not show that error, but it does not start the encoding servers or start itself up. It looks like it is calling openclinfo.exe in the process list but that never completes so the Encoding servers do not start.

If I manually kill openclinfo.exe using the process manager, soon after starting a encoding server, I can get it to start.

[byteshare]

After all of the talk recently with subtiles (and audio while I was at it) I decided to give them another go in RipBot.
I have been for a few years now manually muxing audio (either a copy of source or processed outside of RipBot) and subs with a batch file.
Using the method that I've been doing does a few things for me:
Keeps MKV Title info (if there is any)
Handles more tracks than RipBot seems comfortable with ;)
Gives me some audio controls not found in RipBot
etc...
That said, I really do prefer RipBot over other encoders...

Okay what I tested. I tested a 15s clip with 5 audio tracks and 2 subtitles. (I'll post media info after this description)
Had "Skip demuxing Process" turned off in settings and was using the batch mode (doing this for single files would not be something I'd consider since I'd be handling many files at once).
For batch mode I had Remux Subs on and Copy Stream. Pictures of this:
https://imgur.com/a/oBugnzb

Media Info (source):
General
Format : Matroska
Format version : Version 4 / Version 2
File size : 7.08 MiB
Duration : 15 s 560 ms
Overall bit rate : 3 817 kb/s
Encoded date : UTC 2018-12-15 16:55:12
Writing application : mkvmerge v29.0.0 ('Like It Or Not') 64-bit
Writing library : libebml v1.3.6 + libmatroska v1.4.9
Attachments : Arial_0.ttf / ArnoPro-Display.otf / Ascriptt.ttf / DFGSogeiW5-Kami.ttf

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 10@L4
Format settings : CABAC / 16 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 14 s 932 ms
Bit rate : 1 492 kb/s
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.184
Stream size : 2.66 MiB (38%)
Writing library : x264 core 129 r2245+729M 1a52e03
Encoding settings : cabac=1 / ref=16 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / fade_compensate=1.40 / psy_rd=0.60:0.20 / mixed_ref=1 / me_range=32 /
chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 /
bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40
/ intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.70 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.10
Default : Yes
Forced : No
Color range : Limited
Matrix coefficients : BT.470 System B/G

Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 817 KiB (11%)
Title : 1
Language : Spanish
Service kind : Complete Main
Default : Yes
Forced : No

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 409 KiB (6%)
Title : 2
Language : Spanish
Service kind : Complete Main
Default : No
Forced : No

Audio #3
ID : 4
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 817 KiB (11%)
Title : 3
Language : Italian
Service kind : Complete Main
Default : No
Forced : No

Audio #4
ID : 5
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 817 KiB (11%)
Title : 4
Language : Japanese
Service kind : Complete Main
Default : No
Forced : No

Audio #5
ID : 6
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 350 KiB (5%)
Title : 5
Language : English
Service kind : Complete Main
Default : No
Forced : No

Text #1
ID : 7
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Duration : 3 s 440 ms
Bit rate : 139 b/s
Count of elements : 1
Compression mode : Lossless
Stream size : 60.0 Bytes (0%)
Title : asdf fdsa
Language : Spanish
Default : No
Forced : No

Text #2
ID : 8
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Duration : 3 s 440 ms
Bit rate : 53 b/s
Count of elements : 1
Stream size : 23.0 Bytes (0%)
Title : asdf -asdf
Language : English
Default : No
Forced : No

Menu
00:00:00.000 : ja:OP

What I got after the encode was a video with 1 audio track and 2 subtitles (with no MKV title info):
General
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.49 MiB
Duration : 15 s 560 ms
Overall bit rate : 801 kb/s
Movie name : 00Test00-001
Encoded date : UTC 2018-12-15 16:59:19
Writing application : mkvmerge v29.0.0 ('Like It Or Not') 64-bit
Writing library : libebml v1.3.6 + libmatroska v1.4.9

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 14 s 932 ms
Bit rate : 635 kb/s
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.078
Stream size : 1.13 MiB (76%)
Writing library : x265 2.9+14-3023bd8b05c0:[Windows][GCC 8.2.1][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=704x480 / interlace=0
/ total-frames=358 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop
/ min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / radl=0 / no-splice / no-intra-refresh
/ ctu=16 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0
/ nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / weightb /
no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=1.50
/ psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 /
aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=69 / qpmin=1 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 /
transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps /
no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 /
scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine /
no-single-sei
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 14 s 944 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 350 KiB (23%)
Language : English
Service kind : Complete Main
Default : Yes
Forced : No

Text #1
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Duration : 3 s 440 ms
Bit rate : 134 b/s
Count of elements : 1
Compression mode : Lossless
Stream size : 58.0 Bytes (0%)
Language : Spanish
Default : No
Forced : No

Text #2
ID : 4
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Duration : 3 s 440 ms
Bit rate : 53 b/s
Count of elements : 1
Stream size : 23.0 Bytes (0%)
Language : English
Default : No
Forced : No

Menu
00:00:00.000 : en:OP

If this is working as intended, so be it.
As I've said I already, I am used to batch muxing files outside of RipBot but my guess this isn't very helpful for videos with more than 1 audio track.
MKV title info is probably something very few people care about so no worries on that...I have my batch file :D

[slalom]

@Atak
Same error again
File:blah blah blah
FFVideoSource: No video track found
(E:\Temp\RipBot264temp\job68\getinfo.avs, line 2)
Is there a limitation with the number of subtitles in a mkv file?
This one had 38 subs. I removed a few with mkvmerge, now there are 21 subs

The job loaded with no errors

[Atak_Snajpera]

OK, just had a stall !!! :(

On one Port, using EncoderServer 1.13.1.0, I killed Port 3000 in Process Hacker, which sort of let other servers try and take over, but it was just "scrolling" thru all enabled port, (Auto Reconnect, was enabled) but really wasn't doing much.

So I decided to abort the Job, then backing out of RB, upon restarting RB, it found the chunk that needed to be completed, which it did, but then it didn't progress to muxing it all back together :(

So I decided to abort again !!

And then on re starting the job again, the damn thing started from the very beginning :(

Can't tell you anymore than that, will update when this job is complete.

Update: OK, 1 hour & 12 minutes later, the 2nd attempt went thru without a hitch, however, for what ever other reason there's quite a audio sync problem :(

Update #2:So it happened again, on the very next job, you've just gotta kill whatever port has stalled, abort the job, re start RB, and hope it starts from where it left off.

Whatever the problem is, "Supervise Process" can't restart it.

So it looks like "stall" issue can not be fixed. For some unknown reasons both processes SuperviseProcess.exe and EncodingServer.exe hang at the same time. I give up. You will have to accept this problem or use something else.

[Atak_Snajpera]

I don't believe that you're gonna give up !!!

So, let's say it's an FFMPEG problem, (which has been questioned), when was the last time RB had a newer version of that, updated ??

20180823, is when.

I just went to https://ffmpeg.zeranoe.com/builds/win64/static/, and correct me if I'm wrong, there seems to be a lot newer builds than that, available.....worth a try ???

OR, is there something else other than FFMPEG that can be used for what needs to be done ??

Just thinking out loud.

You haven't posted screenshot from process hacker/explorer but I'm 99% sure that I would see something like this
https://i.imgsafe.org/64/64e47d67e1.png

[gryph]

I've checked and all subtitles are shown on my PC. Can you provide some samples (subtitles) where this problem occurs.

Finally had some free time to make some samples.
You can get them here: https://mega.nz/#F!8Tom3YjL!3QWwKc6cwiwQf-C3WxCZKw
There are 4 files in total.

https://i.gyazo.com/adc449d96f3bcf7a9bffc752c3e30612.png

I always use batch convert... so I did the same for this sample.
These are the settings used for the sample encode.

https://i.gyazo.com/14d1f092c56fd75c6af60081b2a51529.png

And as you'll see, the "bug" only happens when I use .ass subtitles (which is all I do use :) )
However, once the job is created and you go to the job-folder, the subtitle is fine - all lines are there.
Somehow the last line goes missing doing the encode.

Did a few quick test with older versions of RB
RipBot264v1.21.0 = Same result. Last line is missing.
RipBot264v1.20.0 = Works! All lines are encoded.
RipBot264v1.19.6 = Works! All lines are encoded.
RipBot264v1.19.4 = Works! All lines are encoded.

So it seems something changed from v1.20.0 to v1.21.0
Now... I need coffee! Please let me know if there's anything else I can do to help sort this issue.

Gryph

[Ryushin]

I installed the Xeon OpenCL Runtimes for Intel Processors from:
https://software.intel.com/en-us/articles/opencl-drivers
They make you register an account. That stinks.

So now I have opencl.dll and RB does not show that error, but it does not start the encoding servers or start itself up. It looks like it is calling openclinfo.exe in the process list but that never completes so the Encoding servers do not start.

If I manually kill openclinfo.exe using the process manager, soon after starting a encoding server, I can get it to start.

Just received another update. I'm not able to get any encoding servers to start now even if I kill openclinfo.exe.

Edit: I'm having limited success getting a Encoding Server to run. Having to kill the openclinfo.exe process just right.

[byteshare]

So it looks like "stall" issue can not be fixed. For some unknown reasons both processes SuperviseProcess.exe and EncodingServer.exe hang at the same time. I give up. You will have to accept this problem or use something else.
So far I've had less issues with the most recent version.

[Atak_Snajpera]

Well, after another VERY annoying experience with the current build of RB, I took a "video capture" of what was going wrong when RB "shit itself".

https://www.mediafire.com/file/a1dcz...43258.mkv/file
Encoding server window would tell you what went wrong. You will most likely see error saying "File \\Your-PC\RipBot264Temp\Job1\Chunks\1.cmd" does not exist!
This message pop-ups when there is not access to shared folder. You have "Auto reconnect" option enabled and therefore you see this endless loops of "Staring..." <-> "Queue".

[ReinerSchweinlin]

Encoding server window would tell you what went wrong. You will most likely see error saying "File \\Your-PC\RipBot264Temp\Job1\Chunks\1.cmd" does not exist!
This message pop-ups when there is not access to shared folder.

I had exactly that issue on some machines (which worked fine before) - Interesting though - if the share is looked up in the explorer, everything is there, the batches can be opened manualy - but ripbot encodingersever complains exactly like you describe above..

[Atak_Snajpera]

I had exactly that issue on some machines (which worked fine before) - Interesting though - if the share is looked up in the explorer, everything is there, the batches can be opened manualy - but ripbot encodingersever complains exactly like you describe above..

I've noticed the same on virtual machine. If I authenticate shared folder via explorer (once) then everything is fine. What is weird that on real machine on my LAN this problem does not occur. I will have to investigate this issue a little deeper.

[ReinerSchweinlin]

As far as I remember, the machines here with this issue were:

- older Core2DUO over a VPN (Router - Router) with Win 7 Ultimate 64 Bit (fairly fresh install, only some tax software is present, too....)..
- Intel NUC with Win 10 S 64 Bit on the same net as the master machine, completely fresh install, only one plex-server present, too.
- i5 Notebook with Windows 10PRO 64 Bit in the same net as master machine

All of them used to work fine in the past, nothing has changed on the machines (maybe some automatik updates from windows which I don`t monitor or keep track of..)

[ReinerSchweinlin]

There was no error message...did you see one in the clip ???? No.
As Atak mentioned above - the error message appears in the encoder server window - did you see it there? In your video I see no encoder server window.

[Atak_Snajpera]

@burt123
Forget about encoding in ripbot for some time and come back in next year to see if things are improved. Ripbot is a free software so you lose nothing. Just switch to other less frustrating software. Personally I don't care.

[Ryushin]

I loaded a x265 4K movie, and it took RB over 30 minutes to do it's thing, and after all that, it did what that capture shows (and this was on 2 different pc's)

Admittedly, RB does a pretty good job on x264 files, but it just takes way too long to do "thing's" with x265.

I would suggest that if you could start from scratch with a RB type program (Ripbot4K) that is basically exclusively for x265, 4K encoding & limited filtering, & DE (of course) so that it only takes a couple of hours to run thru a 4K movie, instead of a couple of days.

For example, if you load a 4K x265 into MKVToolNix, it almost immediately shows everything that that file contains, then you add & remove the tracks you want, and within a fairly short time you have your "new" edited movie.

Like I said earlier, it takes approx. 30 +/- minutes to just load a x265 4K file.


I'm going to defend Atak here. You should not be complaining about the speed of x265 encodes or the amount of time it takes to rip them.

It is your choice to use whatever encoding settings you want. Either x265, x264, or the x264 with all the options it provides. There are tradeoffs. You can choose where you want the tradeoffs to happen. In quality vs size vs speed.

For example, I've tweaked my h.264 settings to this which increased my encoding time 30% but gave me a better encode in quality and size.

With all my servers running, I could see up to 90 frames per second during an encode. Those servers run about 2300 watts of electricity when running full tilt.

Now lets get to x265. x265 is HEVC. High Efficiency does not mean fast. The new codec provides roughly 50-100% better compression. But the compression comes as heavy cost to encode and playback. Just think that it takes 2-3 times the amount of processing power to encode compared to x264. On top of that, a single 4K frame is four 1080P frames. So 4K should take 4 times longer to encode then 1080P regardless of the codec being used to encode. Add your already slow encode just got slower. This does not included turning on MDegrain2.

So my servers can see 10-20fps encoding 4K without using MDegrain2. All the while consuming a huge amount of electricity.

We are at the beginning of general use of x265. Many years ago I had the same speeds for x264 encodes. But as hardware changes, those are now really fast compared to x265. A decade from now, x265 will be easier where we are at now for x264.

So how do you make your x265 encodes go faster. You need to throw money at the problem. Demuxing the streams is much faster on a SSD, but the Terabytes of encodes that I do, I would destroy the SSD in short order and in addition the cost to purchase the large SSDs are expensive. For encoding x265, I don't think there is anything better then the AMD Zen based chips.

So the saying with cars, How fast do you want to go? = How much money you want to spend. Applies in every way to this case. There is no free lunch here. Money = Speed.

[Atak_Snajpera]

As far as I remember, the machines here with this issue were:

- older Core2DUO over a VPN (Router - Router) with Win 7 Ultimate 64 Bit (fairly fresh install, only some tax software is present, too....)..
- Intel NUC with Win 10 S 64 Bit on the same net as the master machine, completely fresh install, only one plex-server present, too.
- i5 Notebook with Windows 10PRO 64 Bit in the same net as master machine

All of them used to work fine in the past, nothing has changed on the machines (maybe some automatik updates from windows which I don`t monitor or keep track of..)

Good news. I found the problem. During authentication instead of client's local computer name I was using ip address.

for example
net use \\192.168.1.100\RipBot264temp /user:UserName UserPassword

instead of
net use \\Client-PC\RipBot264temp /user:UserName UserPassword

I remember that someone in the past asked if I could use IP address instead of local computer name. In practice it turned out that it was a terrible idea because accessing shared folder via IP is ULTRA slow. I immediately reverted back my code to old method but I totally forgot about authentication command for server!

[ReinerSchweinlin]

Whoooo :) Wonderful! It´s like christmas already :)
I will try as sonn as I reach my Mastermachine :)

Thanx!

(now where was this donate-button... lookielookie..)

[LigH]

Well, x265 is not x264; it does not provide a "film" tuning, only: psnr, ssim, grain, zerolatency, fastdecode

[Atak_Snajpera]

Of course you are...

So how many movie length x265 encodes to you do ??

And I'm sure as hell happy I don't have to pay your power bill !!!!

Just imagine how much time (and money) you would save it RB didn't spend so much time gathering information & indexing & demuxing & remuxing, it would be nearly an hour per job.

For example, if I had a Job Queue that had multiple x265 jobs, and I set it going, it would take approx 30 minute before it would even think about encoding, then a day later (if you're lucky), it would then take approx another 30 minutes to mux it all back together, then on the next job....same again, so over several jobs, hours have been wasted doing nothing :(

Like I said in a previous post, MKVToolNix does it's job in minutes, admittedly there's no DE, or filtering, but if the movie quality is good, (and most 4K movie's are), why does RB have to pull it apart, and put it back together. That's what takes all the time (other than the encoding), and why that has to take so long, when the file is already "up to scratch".

The problem with you is that you do not see difference between simple remuxing (copying streams from one container to another) and re-encoding! (processing frames and encoding to reduce file size). You also do not understand simple things like why encoding 3840x2160 frames take 4 times more time to process/encode than 1920x1080. Next. You also use x265 which uses a lot more complex algorithms in order to increase compression efficiency than x264. If MKVToolnix offers so amazing "compression and speed" then what are you even doing here? Seriously! Your "frustration" comes mainly from lack of knowledge in this particular topic.

[Ryushin]

Of course you are...

So how many movie length x265 encodes to you do ??

And I'm sure as hell happy I don't have to pay your power bill !!!!

Like I said in a previous post, MKVToolNix does it's job in minutes, admittedly there's no DE, or filtering, but if the movie quality is good, (and most 4K movie's are), why does RB have to pull it apart, and put it back together. That's what takes all the time (other than the encoding), and why that has to take so long, when the file is already "up to scratch".

I have about 160 4K discs. Only about 2/3 done with my encoding for 4K right now.

Power bill is heavy. Wife complains.

So as Atak just posted, I understand what you're thinking and trying to do. There is a big difference between remuxing and re-encoding. If you just want to get the 4K movie off the disc and onto your computer, then use MakeMKV and it will take the film and place it into a MKV file at it's original quality and size from the 4K disc. Average size of your file will be between 45-100GB in size. Should take about an hour or so per disc to do and then you are done. All the original subtitles will be there as well.

Now if you want to make changes to said video, making it smaller, degraining, etc. then you will need to re-encode. This is what RB is for. It takes time to extract each component to set it up for how RB processes it (Handbrake skips this step, but it also can not do DE). After that, its encoding time. So for me it is 1-3 movies per day, depending on if I'm using MDegrain or not. If the file size is not right (for me) then I tweak its settings (MDegrain) and back it goes for encoding. I like to shoot for the movie to be 1/3 to 1/4 of it's original size. So about 15-25GB depending on length. Depending on grain, I might have to redo the encode 2-3 times. So a single movie, might take 1-4 days to get done.

Since time seems really important to you, just use MakeMKV and keep the original movie. Get a couple of 10GB drives and store your movies natively.

[guest]

The problem with you is that you do not see difference between simple remuxing (copying streams from one container to another) and re-encoding! (processing frames and encoding to reduce file size). You also do not understand simple things like why encoding 3840x2160 frames take 4 times more time to process/encode than 1920x1080. Next. You also use x265 which uses a lot more complex algorithms in order to increase compression efficiency than x264. If MKVToolnix offers so amazing "compression and speed" then what are you even doing here? Seriously! Your "frustration" comes mainly from lack of knowledge in this particular topic.

One last comment/reply...

I have helped you with a lot of problem solving with your program, over the past couple of years, to help get it better, and I'm happy that I was able to help.

I have told you many times that this IS way over my head, and sometimes you expect "us" to be able to read your mind, when it comes to feedback of problems, and where & what to look for.

I have had NO IT training at all.

Having said that, in my experience, RB does an awesome job with anything up and including 1080, x264.

And it's probably clearly the fastest x265 encoder around, mainly due to the DE function.

My suggestions of building a simple remuxing tool, that also offers some filtering, denoising, & DE, would be very welcome, as most 4K movies probably don't require encoding, and I'm not too interested in reducing file size.

So there's an opportunity for you to create another great program.

You're right, I probably shouldn't be here, so I will disappear.

I won't stop using RB.

[ReinerSchweinlin]

Exactly ... Storage with traditional HDs is so cheap these days..... If remiuxing is faster on a SSD, one could take this intermediate step and pull everything in one peace over to the HD.. Much cheaper on the bill and a lot quicker than re-encoding...

If Size/Quality Ratio is not that big of a concern - one could easily buy a recent GPU oder CPU with hardware encoding and be very quick with very good results. My 50 Euro Pentium (Kaby Lake) was able to do 1080p in H265 10 Bit in "faster than realtime" with no sweat... and Q20 gave results for a normal Movie (with not too much grain in it) at max 6mbit or so.... All my quicksync encodes look very good with about 50% to 100% more Bitrate thrown at them than x265 - and are done much faster..

Of course, If one wants to squeeze out the best quality per bitrate possible - you have to filter, use X265 instead of hardware, take slow settings, wait, twak, CU-losless your brains out, etc.. :) I really enjoy optmizing things, but thats more of a question of "whats important to me - time? Quality? Having a Hobby? Learning the secrets of encdoing? go to avisynth college...??

But it all comes down to the basics - understanding the difference between re-muxing and re-encoding - I agree on that :)

[ReinerSchweinlin]

And it's probably clearly the fastest x265 encoder around, mainly due to the DE function.
RB uses x264 and x265 - which are used by almost every other software for encoding... Speed of encoding mainly relies on the x265 part... Given the same parameters while encoding, most Software bundles (Staxrip, RB, handbrake, Mediacoder, etc... thousands probably) are of the same speed.

RB has this one wonderfull feature of Distributed encoding - which is probably unique... (I´ve seen Mediaencoder having some network settings.. never got it to work).

This way your file can be split up into many small parts - and every PC in your network can contribute encoding..

That´s the speed advantage....

Of course, RB does some muxing, indexing, etc... This is helpful and necessary to keep everything together and in sync... Handbrake (for exmaple) can deal with a videofile without that many "pre-steps", because it simply starts at the beginnig (but take a look at staxrip, wich demuxes also). Handbrake does subtitle scanning which can take a while, too..

But all this time (preparing before encoding) is "next to nothing" compared to the encoding time itself when using x265 in 4k and high quality settings (if you filter, it gets even worse)...

My suggestions of building a simple remuxing tool, that also offers some filtering, denoising, & DE, would be very welcome, as most 4K movies probably don't require encoding, and I'm not too interested in reducing file size.

And here probably lies the biggest misunderstanding....
Filtering, Denoising (which is filtering).... requires re-encoding.. There is NO WAY to simply remux and have a filter applied....

So your suggestion is impossible (not because no one wants to try, it really is impossible!).

[slalom]

Having said that, in my experience, RB does an awesome job with anything up and including 1080, x264.

And it's probably clearly the fastest x265 encoder around, mainly due to the DE function.
It's not the program man, It's your Hardware

My suggestions of building a simple remuxing tool, that also offers some filtering, denoising, & DE, would be very welcome, as most 4K movies probably don't require encoding, and I'm not too interested in reducing file size.
That requires re-encoding

remuxing & re-encoding are two different things

[FuzzyNutz]

Clicking "remove" permanently deletes jobs. Removed jobs should move to the recycle bin.

[Wishbringer]

Only a remark how good or bad is --opencl in x264:

I am encoding in DE mode.
Two Ryzen 2700X with RX550 and DDR4-3200

using placebo preset...

With opencl enabled for RX550 I get around 13 fps alltogether, but cpu-utilization is around 45%,
when opencl is disabled cpu-utilization increases to 100%, but encoding fps only increases to 19 fps.
(this means higher wattage for CPU but lower demands for GPU)

With opencl enabled and using two encodingservers per Client cpu-utilization stays at around 45%, no increase of encoding fps.
(so opencl at RX550 seems to be the bottleneck, I am curious that opencl at RX550 seems to be slower than without on Ryzen 2700X)

Is there a possible option to enable x264 opencl for the first encodingserver per client and disable for the second one?

[Atak_Snajpera]

(so opencl at RX550 seems to be the bottleneck, I am curious that opencl at RX550 seems to be slower than without on Ryzen 2700X)

Have you checked GPU usage in Task Manager? This would clearly show if GPU is a bottleneck here.

Is there a possible option to enable x264 opencl for the first encodingserver per client and disable for the second one?
Not yet but I will add this to my short to do list.

UPDATE: Have tried adding incorrect device id to disable opencl acceleration?
/x264-opencl-device-id 9

[ReinerSchweinlin]

AFAIR Remember, Win10 Task Manager not always is 100% reliable to show GPU workload. I am using GPU-Z to cross-check.

[Ryushin]

One last comment/reply...

You're right, I probably shouldn't be here, so I will disappear.


You don't have to go away. Atak has done and is doing an amazing job evolving RB. He spent a lot of time trying to solve your problem, but doing without being able to duplicate the issue in his development environment, makes it REALLY hard to debug and troubleshoot. At some point, he cannot solve it from his end.

You also have to understand, Atak may be a bit short sometimes. He may feel sometimes that some are ungrateful with all of his hard work. (I'm very grateful for RB!) And he just gets exasperated. He has a life too outside of RB and who knows how much stress is involved in that. And on top of all of this, he develops RB for FREE and on his own time. We have to be more grateful for everything he has done.

So in the end, we can post bugs that we find, and hope that Atak can fix them. But if he can't, and a work around exists, then we should just live with it. Just look at how much more RB does year after year. 4K support just got added around this time last year. Amazing stuff.

Thank you Atak for such an amazing problem and your awesome support.

[byteshare]

Clicking "remove" permanently deletes jobs. Removed jobs should move to the recycle bin.
You can just not have a job get removed until you're ready to have the temp files deleted.
There is an option in the settings for this: Keep jobs after conversion

[FuzzyNutz]

You can just not have a job get removed until you're ready to have the temp files deleted.
There is an option in the settings for this: Keep jobs after conversion

Not applicable when clicking "remove" and doesn't address non-use of recycle bin.

[Wishbringer]

UPDATE: Have tried adding incorrect device id to disable opencl acceleration?
/x264-opencl-device-id 9

with "/x264-opencl-device-id 9" at second encodingserver now I got 100% CPU usage.
So your suggestion works. That x264 task from 2nd encodingserver has 0% GPU usage.
Thanks!


now the weird ones:
with one encodingserver using opencl and one encodingserver not using opencl I got per client 100% CPU usage an 2% GPU usage (GPU usage is unexpected low!)
with both encodingservers using opencl per client I got again around 45% CPU usage and 40-60% GPU usage (again unexpected low, expected 100%)
But the difference in GPU usage between one and two servers is remarkable, and curious.

HDD usage can't be the reason: using 1TB 970 Evo M.2 NVMe with around 3.5 GB/Sek reading and 2 GB/Sek writing.
RAM is 64GB DDR4-3200-16-16-18-38
Network is 1GBit per client over HPE 1920S-48 switch (at moment only 3 pcs on it)

the only result I got like expected :
Both encodingservers without opencl gave 100% CPU and 0% GPU usage.

[Ryushin]

Atak, not sure if you were aware that updates are not working right now:

2018-12-20 06:46:42 : =========================[UPDATER ACTIVATED]=========================
2018-12-20 06:46:42 : Looking for correct UUID link in http://atak-snajpera.5v.pl/
2018-12-20 06:46:43 : [SUCCESS] http://atak-snajpera.5v.pl/ has correct UUID link 6c966b28-e0dd-48f6-b1c7-a56e8a275ec0
2018-12-20 06:46:43 : Downloading update file http://atak-snajpera.5v.pl/ripbot264update/update.zip
2018-12-20 06:46:43 : [ERROR] Unable to download update file http://atak-snajpera.5v.pl/ripbot264update/update.zip
2018-12-20 06:46:43 : Searching for UUID link with DuckDuckGo...
2018-12-20 06:46:44 : Search results...
2018-12-20 06:46:44 : http://atak-snajpera.5v.pl
2018-12-20 06:46:44 : Looking for correct UUID link in http://atak-snajpera.5v.pl
2018-12-20 06:46:44 : [SUCCESS] http://atak-snajpera.5v.pl has correct UUID link 6c966b28-e0dd-48f6-b1c7-a56e8a275ec0
2018-12-20 06:46:44 : [ERROR] Unable to download update file http://atak-snajpera.5v.pl/ripbot264update/update.zip
2018-12-20 06:46:44 : No results.

I was hoping for an update to fix the OpenCLInfo hang problem.

[Atak_Snajpera]

with "/x264-opencl-device-id 9" at second encodingserver now I got 100% CPU usage.
So your suggestion works. That x264 task from 2nd encodingserver has 0% GPU usage.
Thanks!


now the weird ones:
with one encodingserver using opencl and one encodingserver not using opencl I got per client 100% CPU usage an 2% GPU usage (GPU usage is unexpected low!)
with both encodingservers using opencl per client I got again around 45% CPU usage and 40-60% GPU usage (again unexpected low, expected 100%)
But the difference in GPU usage between one and two servers is remarkable, and curious.

HDD usage can't be the reason: using 1TB 970 Evo M.2 NVMe with around 3.5 GB/Sek reading and 2 GB/Sek writing.
RAM is 64GB DDR4-3200-16-16-18-38
Network is 1GBit per client over HPE 1920S-48 switch (at moment only 3 pcs on it)

the only result I got like expected :
Both encodingservers without opencl gave 100% CPU and 0% GPU usage.

What happens with CPU and GPU usage if you run single encodingserver with opencl ON and then during conversion activate extra server with Opencl OFF?

[gryph]

Finally had some free time to make some samples.
You can get them here: https://mega.nz/#F!8Tom3YjL!3QWwKc6cwiwQf-C3WxCZKw
There are 4 files in total.

https://i.gyazo.com/adc449d96f3bcf7a9bffc752c3e30612.png

I always use batch convert... so I did the same for this sample.
These are the settings used for the sample encode.

https://i.gyazo.com/14d1f092c56fd75c6af60081b2a51529.png

And as you'll see, the "bug" only happens when I use .ass subtitles (which is all I do use :) )
However, once the job is created and you go to the job-folder, the subtitle is fine - all lines are there.
Somehow the last line goes missing doing the encode.

Did a few quick test with older versions of RB
RipBot264v1.21.0 = Same result. Last line is missing.
RipBot264v1.20.0 = Works! All lines are encoded.
RipBot264v1.19.6 = Works! All lines are encoded.
RipBot264v1.19.4 = Works! All lines are encoded.

So it seems something changed from v1.20.0 to v1.21.0
Now... I need coffee! Please let me know if there's anything else I can do to help sort this issue.

Gryph

Noone have any ideas to why this is happening?
Or to what have changed from those two versions?
Saw a post about v1.20.0 was the last 32-bit version and v1.21.0 beeing 64-bit or something, but can't find that post nomore.
Dunno if this would change anything(?)

[Wishbringer]

What happens with CPU and GPU usage if you run single encodingserver with opencl ON and then during conversion activate extra server with Opencl OFF?
Not possible at moment, am now at vacation. Around 02.01.19 back.

[gryph]

Update on my own issue:
Decided to downgrade to 1.20.0 and disable the updater. This turned out to be a great idea!
The bug with the subs is gone and even better is, I now get 40 FPS encodes up form 13.5 - 15 FPS.
Whatever the diffrences is on the versions above 1.20.0 there seems to be some huge changes.
As I don't care for H265/4K stuff I don't know if there's a boost to this encode form - which some have been complaining about taking too long.
Try downgrading and see if that changes things for you guys aswell.
Anyways... Good luck! :)

Gryph

[ReinerSchweinlin]

Hey Gryph,
do you have some OPNECL Filters enabled?