cybrnook

It should. The container itself is not volatile like that, it does retain settings through restarts. I think this will all be in the ghb folder in appdata/Handbrake, so you could even back them up yourself for things like upgrades, just in case.

Sounds good to me! Just let me know the tag and the release notes for each tag and I will test.

It is not always the same point on the same file. For example, If I have 5 episodes in a queue 1-5. Perhaps I make it through episode 1, and then beginning of 2 container crashes. When I restart the container, and restart the queue, there is a good chance I will at least get episode 2 this time, then likely crash on 3 (but not guaranteed). With tag v1.13.5, it is stable. But like you said, either Alpine or QS. (My suspicions are on Alpine) EDIT: The CPU I am using now does not support QS (Haven't had time this weekend to setup that build). So I am not using QS at the moment, I am using raw CPU on a E5 v4 Xeon.

@Djoss I dropped back to tag v1.13.5 because this was the last release prior to you upgrading the base Alpine OS. I was able to process 20 episodes staged in a queue last night, no issues. So I think the segfault issue, in my opinion, arose from the base upgrade, since it appears in all releases since. Would it be at all possible for you to compile your latest build for me to test on, but using the older base image that is in use for v1.13.5, prior to the v3.4.0 base image?

So far so good on 1.14.1 (knock on wood). @Djoss , what's happening on these two commits? https://github.com/jlesage/docker-handbrake/commit/46dec53d7920081ad0609141af4bbe9b699ed713 https://github.com/jlesage/docker-handbrake/commit/fa660ff0eed5f68a3e2a860d39735c9e77d15841 Outside of upgrading to HB 1.1.1, these are the only two differences, and so far 1.14.1 is working, while 1.14.2 (and dev-latest) fails with segfaults. EDIT: Spoke too soon: ghb[19742]: segfault at 1542a3636fe0 ip 00001542e634e33b sp 00001542a3636fe8 error 6 in ld-musl-x86_64.so.1[1542e62fd000+8d000] Dropping to v1.13.5 which is on an older base.

So is dev-latest a tag? EDIT: Testing against dev-latest, let's see

Would it be possible to revert to 1.1.0, for a test case? Or perhaps you still have it, and I can just change my docker source? I am seeing this is an Handbrake forums as well: https://forum.handbrake.fr/viewtopic.php?f=13&t=37842 "Hmm. There does seem to be a common pattern...If I try and re-encode a DVD with a single main title, like a movie, 99% of the time it works fine.But if I try and re-encode a DVD with multiple titles, like a TV show, it's almost always guaranteed to fail." This is the case for me as well.

Files uploaded to Git @Djoss, password PM'd

Container resources while encoding (CPU/MEM wise):

Are we (I) running out of memory perhaps within the container? EDIT: Seems I am not the only one: https://github.com/jlesage/docker-handbrake/issues/23

Segfault of ld-musl-x86_64.so.1 seems to point to the underlying Alpine Linux build of the container itself.

And this is UnRaid's log: Jul 14 13:16:15 noah kernel: ghb[4990]: segfault at 14f0889e5fe0 ip 000014f0cb86333b sp 000014f0889e5fe8 error 6 in ld-musl-x86_64.so.1[14f0cb812000+8d000] Jul 14 13:16:22 noah kernel: docker0: port 3(veth66c3bee) entered disabled state Jul 14 13:16:22 noah kernel: veth50cb98e: renamed from eth0 Jul 14 13:16:22 noah avahi-daemon[4591]: Interface veth66c3bee.IPv6 no longer relevant for mDNS. Jul 14 13:16:22 noah avahi-daemon[4591]: Leaving mDNS multicast group on interface veth66c3bee.IPv6 with address fe80::48fa:b1ff:fed2:857b. Jul 14 13:16:22 noah kernel: docker0: port 3(veth66c3bee) entered disabled state Jul 14 13:16:22 noah kernel: device veth66c3bee left promiscuous mode Jul 14 13:16:22 noah kernel: docker0: port 3(veth66c3bee) entered disabled state Jul 14 13:16:22 noah avahi-daemon[4591]: Withdrawing address record for fe80::48fa:b1ff:fed2:857b on veth66c3bee.

Had 13~ or so chapters in a queue for conversion, and during processing seems the container crashed/shutdown: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 00-app-niceness.sh: executing... [cont-init.d] 00-app-niceness.sh: exited 0. [cont-init.d] 00-app-script.sh: executing... [cont-init.d] 00-app-script.sh: exited 0. [cont-init.d] 00-app-user-map.sh: executing... [cont-init.d] 00-app-user-map.sh: exited 0. [cont-init.d] 00-clean-logmonitor-states.sh: executing... [cont-init.d] 00-clean-logmonitor-states.sh: exited 0. [cont-init.d] 00-clean-tmp-dir.sh: executing... [cont-init.d] 00-clean-tmp-dir.sh: exited 0. [cont-init.d] 00-set-app-deps.sh: executing... [cont-init.d] 00-set-app-deps.sh: exited 0. [cont-init.d] 00-set-home.sh: executing... [cont-init.d] 00-set-home.sh: exited 0. [cont-init.d] 00-take-config-ownership.sh: executing... [cont-init.d] 00-take-config-ownership.sh: exited 0. [cont-init.d] 00-xdg-runtime-dir.sh: executing... [cont-init.d] 00-xdg-runtime-dir.sh: exited 0. [cont-init.d] 10-certs.sh: executing... [cont-init.d] 10-certs.sh: exited 0. [cont-init.d] 10-cjk-font.sh: executing... [cont-init.d] 10-cjk-font.sh: exited 0. [cont-init.d] 10-nginx.sh: executing... [cont-init.d] 10-nginx.sh: exited 0. [cont-init.d] 10-vnc-password.sh: executing... [cont-init.d] 10-vnc-password.sh: exited 0. [cont-init.d] 10-web-index.sh: executing... [cont-init.d] 10-web-index.sh: exited 0. [cont-init.d] 95-check-optical-drive.sh: executing... [cont-init.d] 95-check-optical-drive.sh: looking for usable optical drives... [cont-init.d] 95-check-optical-drive.sh: found optical drive /dev/sr0, but it is not usable because is not exposed to the container. [cont-init.d] 95-check-optical-drive.sh: found optical drive /dev/sr1, but it is not usable because is not exposed to the container. [cont-init.d] 95-check-optical-drive.sh: no usable optical drive found. [cont-init.d] 95-check-optical-drive.sh: exited 0. [cont-init.d] 95-check-qsv.sh: executing... [cont-init.d] 95-check-qsv.sh: Processor: Intel(R) Xeon(R) CPU E5-2650 v4@ 2.20GHz [cont-init.d] 95-check-qsv.sh: Intel Quick Sync Video not supported: device directory /dev/dri not exposed to the container. [cont-init.d] 95-check-qsv.sh: exited 0. [cont-init.d] handbrake.sh: executing... Generating machine-id... [cont-init.d] handbrake.sh: exited 0. [cont-init.d] done. [services.d] starting services [services.d] starting s6-fdholderd... [services.d] starting certsmonitor... [services.d] starting nginx... [services.d] starting xvfb... [nginx] starting... [certsmonitor] disabling service: secure connection not enabled. [xvfb] starting... [services.d] starting autovideoconverter... [services.d] starting logmonitor... [logmonitor] no file to monitor: disabling service... [services.d] starting statusmonitor... [services.d] starting openbox... [statusmonitor] no file to monitor: disabling service... [autovideoconverter] starting... [openbox] starting... [autovideoconverter] Processing watch folder '/watch'... [autovideoconverter] Watch folder '/watch' processing terminated. [services.d] starting x11vnc... [services.d] starting app... [x11vnc] starting... [app] starting HandBrake... [services.d] done. 14/07/2018 09:45:07 passing arg to libvncserver: -rfbport 14/07/2018 09:45:07 passing arg to libvncserver: 5900 14/07/2018 09:45:07 passing arg to libvncserver: -rfbportv6 14/07/2018 09:45:07 passing arg to libvncserver: -1 14/07/2018 09:45:07 passing arg to libvncserver: -httpportv6 14/07/2018 09:45:07 passing arg to libvncserver: -1 14/07/2018 09:45:07 passing arg to libvncserver: -desktop 14/07/2018 09:45:07 passing arg to libvncserver: HandBrake 14/07/2018 09:45:07 x11vnc version: 0.9.14 lastmod: 2015-11-14 pid: 932 14/07/2018 09:45:07 Using X display :0 14/07/2018 09:45:07 rootwin: 0x43 reswin: 0x400001 dpy: 0xc553ea00 14/07/2018 09:45:07 14/07/2018 09:45:07 ------------------ USEFUL INFORMATION ------------------ 14/07/2018 09:45:07 X DAMAGE available on display, using it for polling hints. 14/07/2018 09:45:07 To disable this behavior use: '-noxdamage' 14/07/2018 09:45:07 14/07/2018 09:45:07 Most compositing window managers like 'compiz' or 'beryl' 14/07/2018 09:45:07 cause X DAMAGE to fail, and so you may not see any screen 14/07/2018 09:45:07 updates via VNC. Either disable 'compiz' (recommended) or 14/07/2018 09:45:07 supply the x11vnc '-noxdamage' command line option. 14/07/2018 09:45:07 X COMPOSITE available on display, using it for window polling. 14/07/2018 09:45:07 To disable this behavior use: '-noxcomposite' 14/07/2018 09:45:07 14/07/2018 09:45:07 Wireframing: -wireframe mode is in effect for window moves. 14/07/2018 09:45:07 If this yields undesired behavior (poor response, painting 14/07/2018 09:45:07 errors, etc) it may be disabled: 14/07/2018 09:45:07 - use '-nowf' to disable wireframing completely. 14/07/2018 09:45:07 - use '-nowcr' to disable the Copy Rectangle after the 14/07/2018 09:45:07 moved window is released in the new position. 14/07/2018 09:45:07 Also see the -help entry for tuning parameters. 14/07/2018 09:45:07 You can press 3 Alt_L's (Left "Alt" key) in a row to 14/07/2018 09:45:07 repaint the screen, also see the -fixscreen option for 14/07/2018 09:45:07 periodic repaints. 14/07/2018 09:45:07 GrabServer control via XTEST. 14/07/2018 09:45:07 14/07/2018 09:45:07 Scroll Detection: -scrollcopyrect mode is in effect to 14/07/2018 09:45:07 use RECORD extension to try to detect scrolling windows 14/07/2018 09:45:07 (induced by either user keystroke or mouse input). 14/07/2018 09:45:07 If this yields undesired behavior (poor response, painting 14/07/2018 09:45:07 errors, etc) it may be disabled via: '-noscr' 14/07/2018 09:45:07 Also see the -help entry for tuning parameters. 14/07/2018 09:45:07 You can press 3 Alt_L's (Left "Alt" key) in a row to 14/07/2018 09:45:07 repaint the screen, also see the -fixscreen option for 14/07/2018 09:45:07 periodic repaints. 14/07/2018 09:45:07 14/07/2018 09:45:07 XKEYBOARD: number of keysyms per keycode 7 is greater 14/07/2018 09:45:07 than 4 and 51 keysyms are mapped above 4. 14/07/2018 09:45:07 Automatically switching to -xkb mode. 14/07/2018 09:45:07 If this makes the key mapping worse you can 14/07/2018 09:45:07 disable it with the "-noxkb" option. 14/07/2018 09:45:07 Also, remember "-remap DEAD" for accenting characters. 14/07/2018 09:45:07 14/07/2018 09:45:07 X FBPM extension not supported. 14/07/2018 09:45:07 X display is not capable of DPMS. 14/07/2018 09:45:07 -------------------------------------------------------- 14/07/2018 09:45:07 14/07/2018 09:45:07 Default visual ID: 0x21 14/07/2018 09:45:07 Read initial data from X display into framebuffer. 14/07/2018 09:45:07 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/5120 14/07/2018 09:45:07 14/07/2018 09:45:07 X display :0 is 32bpp depth=24 true color 14/07/2018 09:45:07 14/07/2018 09:45:07 Listening for VNC connections on TCP port 5900 14/07/2018 09:45:07 14/07/2018 09:45:07 Xinerama is present and active (e.g. multi-head). 14/07/2018 09:45:07 Xinerama: number of sub-screens: 1 14/07/2018 09:45:07 Xinerama: no blackouts needed (only one sub-screen) 14/07/2018 09:45:07 14/07/2018 09:45:07 fb read rate: 917 MB/sec 14/07/2018 09:45:07 fast read: reset -wait ms to: 10 14/07/2018 09:45:07 fast read: reset -defer ms to: 10 14/07/2018 09:45:07 The X server says there are 10 mouse buttons. 14/07/2018 09:45:07 screen setup finished. 14/07/2018 09:45:07 The VNC desktop is: cadbbe3b5f10:0 0 ****************************************************************************** Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet? The scheme stores pixel data offscreen on the VNC viewer side for faster retrieval. It should work with any VNC viewer. Try it by running: x11vnc -ncache 10 ... One can also add -ncache_cr for smooth 'copyrect' window motion. More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching (ghb:942): GLib-GIO-CRITICAL **: 09:45:07.328: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed GLib-GIO-Message: 09:45:07.553: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. 14/07/2018 09:45:08 Got connection from client 127.0.0.1 14/07/2018 09:45:08 other clients: 14/07/2018 09:45:08 Got 'ws' WebSockets handshake 14/07/2018 09:45:08 Got protocol: binary 14/07/2018 09:45:08 - webSocketsHandshake: using binary/raw encoding 14/07/2018 09:45:08 - WebSockets client version hybi-13 14/07/2018 09:45:08 Disabled X server key autorepeat. 14/07/2018 09:45:08 to force back on run: 'xset r on' (3 times) 14/07/2018 09:45:08 incr accepted_client=1 for 127.0.0.1:54422 sock=10 14/07/2018 09:45:08 Client Protocol Version 3.8 14/07/2018 09:45:08 Protocol version sent 3.8, using 3.8 14/07/2018 09:45:08 rfbProcessClientSecurityType: executing handler for type 1 14/07/2018 09:45:08 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 14/07/2018 09:45:08 copy_tiles: allocating first_line at size 41 14/07/2018 09:45:08 Pixel format for client 127.0.0.1: 14/07/2018 09:45:08 32 bpp, depth 24, little endian 14/07/2018 09:45:08 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 14/07/2018 09:45:08 no translation needed 14/07/2018 09:45:08 Enabling NewFBSize protocol extension for client 127.0.0.1 14/07/2018 09:45:08 Enabling full-color cursor updates for client 127.0.0.1 14/07/2018 09:45:08 Using image quality level 6 for client 127.0.0.1 14/07/2018 09:45:08 Using JPEG subsampling 0, Q79 for client 127.0.0.1 14/07/2018 09:45:08 Using compression level 9 for client 127.0.0.1 14/07/2018 09:45:08 Enabling LastRect protocol extension for client 127.0.0.1 14/07/2018 09:45:08 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC) 14/07/2018 09:45:08 Using tight encoding for client 127.0.0.1 14/07/2018 09:45:09 client_set_net: 127.0.0.1 0.0001 14/07/2018 09:45:09 created xdamage object: 0x40002c 14/07/2018 09:45:09 client 1 network rate 1383.8 KB/sec (94912.8 eff KB/sec) 14/07/2018 09:45:09 client 1 latency: 0.6 ms 14/07/2018 09:45:09 dt1: 0.0130, dt2: 0.0288 dt3: 0.0006 bytes: 57344 14/07/2018 09:45:09 link_rate: LR_LAN - 1 ms, 1383 KB/s 14/07/2018 09:45:17 created selwin: 0x40002d 14/07/2018 09:45:17 called initialize_xfixes() 14/07/2018 09:45:17 got closure, reason 1001 14/07/2018 09:45:17 rfbProcessClientNormalMessage: read: Connection reset by peer 14/07/2018 09:45:17 client_count: 0 14/07/2018 09:45:17 Restored X server key autorepeat to: 1 14/07/2018 09:45:17 Client 127.0.0.1 gone 14/07/2018 09:45:17 Statistics events Transmit/ RawEquiv ( saved) 14/07/2018 09:45:17 FramebufferUpdate : 66 | 0/ 0 ( 0.0%) 14/07/2018 09:45:17 copyRect : 1 | 16/ 757416 (100.0%) 14/07/2018 09:45:17 LastRect : 38 | 456/ 456 ( 0.0%) 14/07/2018 09:45:17 tight : 246 | 172732/ 10420808 ( 98.3%) 14/07/2018 09:45:17 RichCursor : 1 | 1374/ 1374 ( 0.0%) 14/07/2018 09:45:17 TOTALS : 352 | 174578/ 11180054 ( 98.4%) 14/07/2018 09:45:17 Statistics events Received/ RawEquiv ( saved) 14/07/2018 09:45:17 PointerEvent : 663 | 3978/ 3978 ( 0.0%) 14/07/2018 09:45:17 FramebufferUpdate : 68 | 680/ 680 ( 0.0%) 14/07/2018 09:45:17 SetEncodings : 1 | 56/ 56 ( 0.0%) 14/07/2018 09:45:17 SetPixelFormat : 1 | 20/ 20 ( 0.0%) 14/07/2018 09:45:17 TOTALS : 733 | 4734/ 4734 ( 0.0%) 14/07/2018 09:45:17 destroyed xdamage object: 0x40002c 14/07/2018 11:39:52 Got connection from client 127.0.0.1 14/07/2018 11:39:52 other clients: 14/07/2018 11:39:52 Got 'ws' WebSockets handshake 14/07/2018 11:39:52 Got protocol: binary 14/07/2018 11:39:52 - webSocketsHandshake: using binary/raw encoding 14/07/2018 11:39:52 - WebSockets client version hybi-13 14/07/2018 11:39:52 Disabled X server key autorepeat. 14/07/2018 11:39:52 to force back on run: 'xset r on' (3 times) 14/07/2018 11:39:52 incr accepted_client=2 for 127.0.0.1:54426 sock=10 14/07/2018 11:39:52 Client Protocol Version 3.8 14/07/2018 11:39:52 Protocol version sent 3.8, using 3.8 14/07/2018 11:39:52 rfbProcessClientSecurityType: executing handler for type 1 14/07/2018 11:39:52 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 14/07/2018 11:39:52 Pixel format for client 127.0.0.1: 14/07/2018 11:39:52 32 bpp, depth 24, little endian 14/07/2018 11:39:52 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 14/07/2018 11:39:52 no translation needed 14/07/2018 11:39:52 Enabling NewFBSize protocol extension for client 127.0.0.1 14/07/2018 11:39:52 Enabling full-color cursor updates for client 127.0.0.1 14/07/2018 11:39:52 Using image quality level 6 for client 127.0.0.1 14/07/2018 11:39:52 Using JPEG subsampling 0, Q79 for client 127.0.0.1 14/07/2018 11:39:52 Using compression level 9 for client 127.0.0.1 14/07/2018 11:39:52 Enabling LastRect protocol extension for client 127.0.0.1 14/07/2018 11:39:52 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC) 14/07/2018 11:39:52 Using tight encoding for client 127.0.0.1 14/07/2018 11:39:52 client_set_net: 127.0.0.1 0.0001 14/07/2018 11:39:52 created xdamage object: 0x40002e 14/07/2018 11:40:12 client 2 network rate 3018.8 KB/sec (346251.9 eff KB/sec) 14/07/2018 11:40:12 client 2 latency: 0.6 ms 14/07/2018 11:40:12 dt1: 0.0101, dt2: 0.0016 dt3: 0.0006 bytes: 34286 14/07/2018 11:40:12 link_rate: LR_LAN - 1 ms, 3018 KB/s 14/07/2018 11:40:58 got closure, reason 1001 14/07/2018 11:40:58 rfbProcessClientNormalMessage: read: Connection reset by peer 14/07/2018 11:40:58 client_count: 0 14/07/2018 11:40:58 Restored X server key autorepeat to: 1 14/07/2018 11:40:58 Client 127.0.0.1 gone 14/07/2018 11:40:58 Statistics events Transmit/ RawEquiv ( saved) 14/07/2018 11:40:58 ServerCutText : 1 | 8/ 8 ( 0.0%) 14/07/2018 11:40:58 FramebufferUpdate : 92 | 0/ 0 ( 0.0%) 14/07/2018 11:40:58 copyRect : 2 | 32/ 3998712 (100.0%) 14/07/2018 11:40:58 LastRect : 61 | 732/ 732 ( 0.0%) 14/07/2018 11:40:58 tight : 525 | 361176/ 25868204 ( 98.6%) 14/07/2018 11:40:58 RichCursor : 1 | 1374/ 1374 ( 0.0%) 14/07/2018 11:40:58 TOTALS : 682 | 363322/ 29869030 ( 98.8%) 14/07/2018 11:40:58 Statistics events Received/ RawEquiv ( saved) 14/07/2018 11:40:58 KeyEvent : 4 | 32/ 32 ( 0.0%) 14/07/2018 11:40:58 PointerEvent : 2061 | 12366/ 12366 ( 0.0%) 14/07/2018 11:40:58 FramebufferUpdate : 95 | 950/ 950 ( 0.0%) 14/07/2018 11:40:58 SetEncodings : 1 | 56/ 56 ( 0.0%) 14/07/2018 11:40:58 SetPixelFormat : 1 | 20/ 20 ( 0.0%) 14/07/2018 11:40:58 TOTALS : 2162 | 13424/ 13424 ( 0.0%) 14/07/2018 11:40:58 destroyed xdamage object: 0x40002e 14/07/2018 11:40:58 Got connection from client 127.0.0.1 14/07/2018 11:40:58 other clients: 14/07/2018 11:40:58 Got 'ws' WebSockets handshake 14/07/2018 11:40:58 Got protocol: binary 14/07/2018 11:40:58 - webSocketsHandshake: using binary/raw encoding 14/07/2018 11:40:58 - WebSockets client version hybi-13 14/07/2018 11:40:58 Disabled X server key autorepeat. 14/07/2018 11:40:58 to force back on run: 'xset r on' (3 times) 14/07/2018 11:40:58 incr accepted_client=3 for 127.0.0.1:54428 sock=10 14/07/2018 11:40:58 Client Protocol Version 3.8 14/07/2018 11:40:58 Protocol version sent 3.8, using 3.8 14/07/2018 11:40:58 rfbProcessClientSecurityType: executing handler for type 1 14/07/2018 11:40:58 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 14/07/2018 11:40:58 Pixel format for client 127.0.0.1: 14/07/2018 11:40:58 32 bpp, depth 24, little endian 14/07/2018 11:40:58 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 14/07/2018 11:40:58 no translation needed 14/07/2018 11:40:58 Enabling NewFBSize protocol extension for client 127.0.0.1 14/07/2018 11:40:58 Enabling full-color cursor updates for client 127.0.0.1 14/07/2018 11:40:58 Using image quality level 6 for client 127.0.0.1 14/07/2018 11:40:58 Using JPEG subsampling 0, Q79 for client 127.0.0.1 14/07/2018 11:40:58 Using compression level 9 for client 127.0.0.1 14/07/2018 11:40:58 Enabling LastRect protocol extension for client 127.0.0.1 14/07/2018 11:40:58 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC) 14/07/2018 11:40:58 Using tight encoding for client 127.0.0.1 14/07/2018 11:40:58 client_set_net: 127.0.0.1 0.0001 14/07/2018 11:40:58 created xdamage object: 0x40002f 14/07/2018 11:41:02 client 3 network rate 133.4 KB/sec (12522.2 eff KB/sec) 14/07/2018 11:41:02 client 3 latency: 0.6 ms 14/07/2018 11:41:02 dt1: 0.7102, dt2: 0.0017 dt3: 0.0006 bytes: 94927 14/07/2018 11:41:02 link_rate: LR_BROADBAND - 1 ms, 133 KB/s 14/07/2018 11:41:02 increased wireframe timeouts for slow network connection. 14/07/2018 11:41:02 netrate: 133 KB/sec, latency: 1 ms 14/07/2018 11:48:06 idle keyboard: turning X autorepeat back on. [services.d] stopping services [services.d] stopping app... [services.d] stopping x11vnc... caught signal: 15 14/07/2018 13:16:15 deleted 40 tile_row polling images. [services.d] stopping openbox... [services.d] stopping statusmonitor... [services.d] stopping logmonitor... [services.d] stopping autovideoconverter... [services.d] stopping xvfb... [services.d] stopping nginx... [services.d] stopping certsmonitor... [services.d] stopping s6-fdholderd... [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] syncing disks. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting.

Gotcha, I remember that way. Was just wondering about that pretty button ? Thank you much!

Would it be possible to get this to work? Or as simple as passing a device to the container, same as we do MakeMKV?

Do that, and a few bucks are coming your way EDIT: should I say a few "more" bucks

Nice, still use windirstat from time to time.

Well, I ended up mapping a drive 1:1 per container. I am able to use the physical eject button, and discs are scanning in no issue on swap. I am wondering if perhaps since both containers had both drives mapped, and I was swapping and dropping new discs into both drives within the same 10 - 15 second span, perhaps it was somehow causing an issue where drive 1 was actively scanning in a new disc when suddenly drive 2 received a new disc for scan it at the same time, and neither container was able to handle that in quick succession? I will try with containers as 1:1 for now and see if anything pops up.

Balls, I could easily see that being the case, because YES, I am known to hit the eject button on the drive itself. I got tons of discs to rip through this weekend, will try this out and report back. Thanks @saarg

@Djoss hope all is well! Had a quick question..... Now that I am really cranking on this container in particular (and handbrake), I am noticing something. As you know, I am running two instances of this container (as seen above) on separate ports. It's working fine, and I can rip from both containers at the same time against the 2 x ASUS USB BD drives I have attached (both drives are mounted to both containers, not just one to one). What I am just now seeing, and maybe has been that way for some time, is that let's say I start a backup before bed on both drives, then walk away..... I come back in the am or two days later, and the containers have the nice "Backup Complete" message and all seems well. Click okay, and MakeMKV goes back to it's primary screen. At that point in time, I head over to the server, eject, and swap in two more discs, and come back to the PC interface. However, the containers are still presenting the "old" discs I just previously took out, like it's not refreshing. I need to restart the containers to refresh/re-initiate. AT THIS POINT, I am also noticing that when the container goes down, it's not always return code (0) in the advanced logs view in UnRaid. It's ending with a 2xx code (I forget exactly). But nevertheless they do come back up, and work fine from that point. Have you seen any time outs or any sequencing issues with the MakeMKV container if you let it sit running for an extended period of time perhaps on a display window with a disc inserted?

I got a couple of these: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157615 BNIB if interested

I should have my E3 1275 v6 and SM board waiting for me when I get home. Can't wait to play ? Want to bench mark it against my E5 2650 v4. Many slow cores vs few fast cores ? (with QS) - I got seasons 1 - 7 of GoT BD to convert from MKV RAW backup.

Super cool Quick Sync is finally making it's way to Handbrake. It's only been what, 7 years? ? I remember encoding years ago in a desktop based CPU using quick sync (another program other than handbrake) and it was amazingly fast, as stated in your git.

Ended up working out just fine ? Only thing is I needed to remap some ports, so I just ended up remapping them all a bit cleaner, at least in my eyes: Outside of that, dual ripping worked fine. FYI, "Backup" mode does convert to a three folder format (CERTIFICATE, BDMV, and MAKEMKV). Handbrake seems to understand that structure well enough to convert out of it.

I know I could (and likely will) just try, but if you're bored, I have a question. If you change the default output from MKV to BACKUP, does this produce an ISO structure? Or does it just create the folder structure, which I could then just compress to an ISO (similar as rip to iso does in anydvd)?