Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
15th August 2019, 19:38 | #17141 | Link |
Registered User
Join Date: Oct 2010
Posts: 61
|
Viper714, thank you so much for the reply, disabled the Logitech framework and Ripbot now works. I only have the Logitech software installed for my MX518 mouse (not compatible with ghub), and that seems to work fine without the frame work running.
|
17th August 2019, 06:34 | #17142 | Link |
Registered User
Join Date: Jun 2008
Posts: 44
|
i got a bit of an odd question for the author, i noticed that ever since v 1.25, with Lmash decoding i assume, the indexing process takes twice as long than before. i built my encoding machine purposely with all Nvme drives to speed up the demux and index process, but it seems with the latest Lmash update, after the demux, and after index (which btw you can tell that sequential disk read/write are both at max), "gathering information/Extracting Frames" seems to be doing some additional CPU crunching without much disk usage or if at all and that "gathering information/extracting frames" process now takes wayyyyyy longer than before.
i confirmed the performance difference by comparing to v. 1.23.1, which was my fall-back version. with v. 1.23.1, after demux and index, gathering information only takes about 5 seconds on my Nvme doing HDR H265 source, now with v. 1.25 when it gets to the Gathering Information and extracting frames, it takes like 5~10 or so mins? i checked the task manager while it's doing its thing to find out why it's taking this longer, and looks like it's launching the ffprobe AGAIN to do something. FFProbe was already launched once when demuxing was taking place but why now again? thoughts? Last edited by howzz; 17th August 2019 at 10:31. |
17th August 2019, 13:30 | #17143 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
What is the size of .lwi file in job folder?
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
17th August 2019, 21:37 | #17145 | Link |
Registered User
Join Date: Jun 2008
Posts: 44
|
i tried v 1.23.1 again, and it doesn't produce .lwi file at all. so i guess v 1.25 is producing this .lwi file that's taking forever. what exactly does it do, and why do we need it? this makes me want to just go back to v 1.23.1 but v. 1.25 has the latest version of X265 (release v30 i beleive) with lots of improvements in the codec.
|
18th August 2019, 00:06 | #17146 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
|
18th August 2019, 00:23 | #17147 | Link | |
Registered User
Join Date: Jun 2008
Posts: 44
|
Quote:
but maybe i misunderstood you. |
|
18th August 2019, 00:44 | #17148 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
It's unrelated to playback, source filters create an index helping them to ensure frame accuracy for random frame access that some filters might do. There are people who understand and can explain this better than me.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
18th August 2019, 00:50 | #17149 | Link |
Registered User
Join Date: Jun 2008
Posts: 44
|
Update:
Strangely. there's a new update that just rolled out a few mins ago. i launched ripbot again and it udpated itself. so i looked into the update log, and looks like either Atak may have enabled a new update for Lmash pushed a new version update to ripbot. either way, Lmash got updated, and now when it gets to Gathering Information/Extracting frames, it does so much faster. i also noticed that it compressed the index with the new update. so instead of the massive 1.25GB index file, .lwi is now 30MB small. and you can tell that when it compressed it because just right after indexing and before Gathering information, you see the ripbot status bar briefly shows Compressing Index. it then quickly proceeds to Gathering information and Extracting Frame and only take 3 or so mins now. so whatever Atak did. thanks!. or whatever Lmash did, thanks! ========== 2019-08-17 13:38:25 : Update for [lsmash] detected 2019-08-17 13:38:25 : Downloading file http://atak-snajpera.5v.pl/ripbot264update/lsmash.zip to D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip 2019-08-17 13:38:26 : [SUCCESS] File D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip saved! 2019-08-17 13:38:26 : CRC32 value has not changed for [7z]. Update is not required. 2019-08-17 13:38:26 : Downloading finished. 2019-08-17 16:37:34 : =========================[UPDATER ACTIVATED]========================= 2019-08-17 16:37:34 : Installing updates... 2019-08-17 16:37:39 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\core.zip has been correctly extracted! 2019-08-17 16:37:48 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\ffmpeg.zip has been correctly extracted! 2019-08-17 16:37:49 : [SUCCES] D:\DVDRip Work Files\Programs\RipBot264v1.24.0\Updates\lsmash.zip has been correctly extracted! 2019-08-17 16:37:49 : Installation complete. 2019-08-17 16:37:55 : Next check after 2019-08-18 13:38:18 2019-08-17 16:38:42 : Next check after 2019-08-18 13:38:18 |
18th August 2019, 08:51 | #17151 | Link |
Registered User
Join Date: Jun 2016
Location: Canada
Posts: 131
|
flickering playback
As of the last few days, playback of some of my blu-ray source videos encoded with RB have occasional flickering, where video frames seem to pause or jump back and forward within fractions of seconds. After the incidents, playback returns to normal and the audio is still synced correct.
Last edited by FuzzyNutz; 18th August 2019 at 08:54. |
18th August 2019, 14:21 | #17152 | Link | |
Registered User
Join Date: Oct 2001
Posts: 454
|
Quote:
Thank you for the offer. I had a closer look into the temp folders... The two audio streams are extracted, audiolist.txt lists two streams and audiostreams.cmd lists to prozess 3 streams. What´s missing is content in "encodeaudio2.cmd" - it has zero bytes. |
|
18th August 2019, 20:41 | #17153 | Link |
Registered User
Join Date: Jun 2016
Posts: 116
|
I'm having an odd issue with ripbot. It's taking 5-15 minutes to start an encode chunk every time. I already did the update which compresses the lwi file down to around 30MBs.
Something I've noticed is that when the encoding client is starting a new chunk. The system process pegs my network connection - currently 1Gbps. While the disk usage is very low. So it'll start disk usage will hit 20-30MBps then drops to 1-2MB/s while the network is pegged at 800-900 Mb/s. it'll stay like that for quite some time. This is going from a R7 1700 to a AMD 3900x via Gigabit ethernet at the moment. I've also confirmed the system running the encoding server matches the system process behavior. I've also tried this on another machine same issue - 16c Xeon v4. I understand that the lwi file is larger in general which takes it longer to copy. This seems abnormally long given the lwi file uncompressed is usually around 1.3GBs for a 4K movie. Thoughts? Last edited by brumsky; 18th August 2019 at 20:49. |
18th August 2019, 20:55 | #17154 | Link |
Registered User
Join Date: Mar 2018
Posts: 12
|
Same for me, the last days were a nightmare....DE that always worked since months suddenly broken, servers not starting at all, big time delays when rendering chunks like you described, a looooong wait for Autocrop and so on.
I hope these issues get fixed soon since I really think ripbot is the best tool to convert uhd 4K hdr files. At least since today I am able to use DE again on my two machines and even after aborting he picks up where it left....which also seemed broken a day or two ago. Really strange. |
18th August 2019, 22:38 | #17155 | Link |
Registered User
Join Date: Jun 2016
Posts: 116
|
Digging into this further, I can see that it is reading the video.mkv file. It appears to be transferring the whole file. that is the only thing that makes sense given how small the new lwi files is after compressing.
|
19th August 2019, 02:31 | #17157 | Link | |
Registered User
Join Date: Feb 2008
Posts: 145
|
Quote:
P.S. I tried piping the filter to the CPU, it didn't work either sadly, I'd have loved to see how the 3900X handled that Edit: I may have found something - it looks like the old index files and the new index files may not be playing well together? My GTX 680 card claims OpenCL 1.2 but after a lengthy period of time creating the index it fails to "open file" like my previous attempts and then tries to recreate the index AGAIN :-O I will try this on the machine with the 1050 card as soon as I'm able to gain access to it again. Last edited by BLKMGK; 19th August 2019 at 02:58. |
|
19th August 2019, 07:22 | #17158 | Link |
Registered User
Join Date: Feb 2008
Posts: 145
|
Whoa! Just threw a brand new unfiltered job into the queue. After EACH block it's rebuilding an index file! It's literally taking longer to build the index file than it is to compress the block - d'oh! This is v1.25 using Encoding Server v1.15.2.0 just updated tonight.
|
19th August 2019, 10:27 | #17160 | Link |
Registered User
Join Date: Oct 2001
Posts: 454
|
I recognized something:
- The new index files are put into the source directory instead of the TEMP dir. - after encoding and deleting all the jobs, the files still are recognized as "used" by windows. - on some machines in the local network, the creating of the LWI Files after "Start" takes several minutes (the lokal machine and two others - all others are finished after a few seconds) Last edited by ReinerSchweinlin; 19th August 2019 at 11:24. |
Tags |
264, 265, appletv, avchd, bluray, gui, iphone, ipod, ps3, psp, ripbot264, x264 2-pass, x264 gui, x264_64, x265, xbox360 |
|
|