cybrnook Posted July 14, 2018 Share Posted July 14, 2018 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. 1 Quote Link to comment
cybrnook Posted July 14, 2018 Share Posted July 14, 2018 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. Quote Link to comment
cybrnook Posted July 14, 2018 Share Posted July 14, 2018 (edited) Segfault of ld-musl-x86_64.so.1 seems to point to the underlying Alpine Linux build of the container itself. Edited July 14, 2018 by cybrnook 1 Quote Link to comment
cybrnook Posted July 14, 2018 Share Posted July 14, 2018 (edited) 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 Edited July 14, 2018 by cybrnook Quote Link to comment
cybrnook Posted July 14, 2018 Share Posted July 14, 2018 (edited) Container resources while encoding (CPU/MEM wise): Edited July 15, 2018 by cybrnook Quote Link to comment
cybrnook Posted July 14, 2018 Share Posted July 14, 2018 Files uploaded to Git @Djoss, password PM'd 1 Quote Link to comment
Arndroid Posted July 14, 2018 Share Posted July 14, 2018 Can you enable x265 compression on Very Fast 1080p30 using the /watch folder? Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) 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. Edited July 15, 2018 by cybrnook Quote Link to comment
Jorgen Posted July 15, 2018 Share Posted July 15, 2018 On 7/14/2018 at 10:58 AM, Jorgen said: Aha. I’ve got a Haswell, will do some quality comparisons. Ok, thanks for pointing this out. I had (wrongly) assumed that QSV only added hardware acceleration to the normal h264 encoder, but after somme googling I now realise it's a completely different implementation of h264 encoding with different parameters and tradeoffs between quality/speed/file size. For other's benefit, QSV is really intended for real time streaming conversions where speed is more important than quality. If you care about quality, sacrifice raw speed and use the normal CPU powered encoders in Handbrake instead and you'll get better quality in smaller file sizes. Apparently, the best quality you can hope for using QSV is on par with the Veryfast preset for normal h264, but the file size will be larger. There are some tuning parameters you can add to QSV to improve things somewhat, but don't expect miracles: https://handbrake.fr/docs/en/latest/technical/video-qsv-options.html Quote Link to comment
Jorgen Posted July 15, 2018 Share Posted July 15, 2018 (edited) 9 minutes ago, cybrnook said: 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? You should be able to specify an older release by adding the correct tag to the Repository setting in the unRAID docker template. E.g. jlesage/handbrake:v1.13.5 For available tags, see https://hub.docker.com/r/jlesage/handbrake/tags/ I don't know which tag correspond to 1.1.0 though. Edit: if you specify a particular tag you will be stuck on that version forever and won't be notified of updates. Remove the tag to get back on the "latest" releases. Edited July 15, 2018 by Jorgen 1 Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) So is dev-latest a tag? EDIT: Testing against dev-latest, let's see Edited July 15, 2018 by cybrnook Quote Link to comment
Jorgen Posted July 15, 2018 Share Posted July 15, 2018 35 minutes ago, cybrnook said: So is dev-latest a tag? EDIT: Testing against dev-latest, let's see If you want Handbrake 1.1.0 I think you need to use docker tag 1.14.1: https://github.com/jlesage/docker-handbrake/releases 1 Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) 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. Edited July 15, 2018 by cybrnook Quote Link to comment
Arndroid Posted July 15, 2018 Share Posted July 15, 2018 (edited) Hmm can we make a feature that doesn't remove the Watch file if it is smaller than the Output? Again, maybe we can enable x265 support for the Watch folder compression? Edited July 15, 2018 by Arndroid Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) @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? Edited July 15, 2018 by cybrnook Quote Link to comment
Djoss Posted July 15, 2018 Author Share Posted July 15, 2018 1 hour ago, cybrnook said: @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? The problem is either with the upgrade to Alpine 3.8 or with the addition of QSV support... When you get a crash on a file, does restarting the encoding works? Or it is always crashing for the same file? 1 Quote Link to comment
Djoss Posted July 15, 2018 Author Share Posted July 15, 2018 1 hour ago, Arndroid said: Hmm can we make a feature that doesn't remove the Watch file if it is smaller than the Output? You ca use post conversion hooks to implement this: https://github.com/jlesage/docker-handbrake/blob/master/README.md#hooks 1 hour ago, Arndroid said: Again, maybe we can enable x265 support for the Watch folder compression? Since you can use any preset with the watch folder, you just need configure the preset with the x265 encoder and it should work. Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) 14 minutes ago, Djoss said: The problem is either with the upgrade to Alpine 3.8 or with the addition of QSV support... When you get a crash on a file, does restarting the encoding works? Or it is always crashing for the same file? 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. Edited July 15, 2018 by cybrnook Quote Link to comment
Djoss Posted July 15, 2018 Author Share Posted July 15, 2018 4 minutes ago, cybrnook said: 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) Ok thanks. So I can make 3 different builds: one with Alpine 3.8 without QSV, one with Alpine 3.7 and QSV and another one with debug enabled, so we can get a core dump and see exactly where it's crashing. 1 Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 Just now, Djoss said: Ok thanks. So I can make 3 different builds: one with Alpine 3.8 without QSV, one with Alpine 3.7 and QSV and another one with debug enabled, so we can get a core dump and see exactly where it's crashing. Sounds good to me! Just let me know the tag and the release notes for each tag and I will test. Quote Link to comment
Djoss Posted July 15, 2018 Author Share Posted July 15, 2018 5 minutes ago, cybrnook said: Sounds good to me! Just let me know the tag and the release notes for each tag and I will test. Perfect! Thank you. Quote Link to comment
Arndroid Posted July 15, 2018 Share Posted July 15, 2018 (edited) 42 minutes ago, Djoss said: You ca use post conversion hooks to implement this: https://github.com/jlesage/docker-handbrake/blob/master/README.md#hooks Since you can use any preset with the watch folder, you just need configure the preset with the x265 encoder and it should work. My post conversion, for anyone looking for help regarding this: (Not tested yet) (Also just set "Automatic Video Converter: Keep Source Files:" to 1) #!/bin/sh # # This is an example of a post-conversion hook. This script is always invoked # with /bin/sh (shebang ignored). # # The first parameter is the conversion status. A value of 0 indicates that # the video has been converted successfully. Else, conversion failed. # # The second parameter is the full path to the converted video (the output). # # The third parameter is the full path to the source file. # # The fourth argument is the name of the HandBrake preset used to convert the # video. # CONVERSION_STATUS=$1 CONVERTED_FILE="$2" SOURCE_FILE="$3" PRESET="$4" echo "post-conversion: Status = $CONVERSION_STATUS" echo "post-conversion: Output File = $CONVERTED_FILE" echo "post-conversion: Source File = $SOURCE_FILE" echo "post-conversion: Preset = $PRESET" if [ "$CONVERSION_STATUS" -eq 0 ]; then # Successful conversion. # TODO: Do something useful. FILENAME=$CONVERTED_FILE FILESIZE=$(stat -c%s "$FILENAME") FILENAMESource=$SOURCE_FILE FILESIZESource=$(stat -c%s "$FILENAMESource") if (FILESIZE > FILESIZESource) then rm FILENAME else rm FILENAMESource fi : else # Failed conversion. # TODO: Do something useful. : fi ---------------------------- How do I configure the preset to do x265 encoding? I only see these Docker Environmental Parameters: AUTOMATED_CONVERSION_PRESET AUTOMATED_CONVERSION_FORMAT AUTOMATED_CONVERSION_SOURCE_STABLE_TIME AUTOMATED_CONVERSION_SOURCE_MIN_DURATION AUTOMATED_CONVERSION_OUTPUT_SUBDIR AUTOMATED_CONVERSION_KEEP_SOURCE Maybe I missed it, can you point me in the right direction? Edited July 15, 2018 by Arndroid Quote Link to comment
Djoss Posted July 15, 2018 Author Share Posted July 15, 2018 2 minutes ago, Arndroid said: My post conversion, for anyone looking for help regarding this: (Not tested yet) (Also just set "Automatic Video Converter: Keep Source Files:" to 1) #!/bin/sh # # This is an example of a post-conversion hook. This script is always invoked # with /bin/sh (shebang ignored). # # The first parameter is the conversion status. A value of 0 indicates that # the video has been converted successfully. Else, conversion failed. # # The second parameter is the full path to the converted video (the output). # # The third parameter is the full path to the source file. # # The fourth argument is the name of the HandBrake preset used to convert the # video. # CONVERSION_STATUS=$1 CONVERTED_FILE="$2" SOURCE_FILE="$3" PRESET="$4" echo "post-conversion: Status = $CONVERSION_STATUS" echo "post-conversion: Output File = $CONVERTED_FILE" echo "post-conversion: Source File = $SOURCE_FILE" echo "post-conversion: Preset = $PRESET" if [ "$CONVERSION_STATUS" -eq 0 ]; then # Successful conversion. # TODO: Do something useful. FILENAME=$CONVERTED_FILE FILESIZE=$(stat -c%s "$FILENAME") FILENAMESource=$SOURCE_FILE FILESIZESource=$(stat -c%s "$FILENAMESource") if (FILESIZE > FILESIZESource) then rm FILENAME else rm FILENAMESource fi : else # Failed conversion. # TODO: Do something useful. : fi ---------------------------- How do I configure the preset to do x265 encoding? I only see these Docker Environmental Parameters: AUTOMATED_CONVERSION_PRESET AUTOMATED_CONVERSION_FORMAT AUTOMATED_CONVERSION_SOURCE_STABLE_TIME AUTOMATED_CONVERSION_SOURCE_MIN_DURATION AUTOMATED_CONVERSION_OUTPUT_SUBDIR AUTOMATED_CONVERSION_KEEP_SOURCE Maybe I missed it, can you point me in the right direction? You configure the preset using the GUI Quote Link to comment
Arndroid Posted July 15, 2018 Share Posted July 15, 2018 Just now, Djoss said: You configure the preset using the GUI Oh, will that configuration stick for the whole lifetime of the Docker Container applying the Preset settings to the /Watch folder? Even when updated/restarted? Quote Link to comment
cybrnook Posted July 15, 2018 Share Posted July 15, 2018 (edited) 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. Edited July 15, 2018 by cybrnook Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.