[Support] Djoss - HandBrake


Recommended Posts

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.

 

  • Like 1
Link to comment

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.

 

Link to comment

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 by cybrnook
Link to comment
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

 

Link to comment
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 by Jorgen
  • Like 1
Link to comment

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 by cybrnook
Link to comment

@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 by cybrnook
Link to comment
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?

  • Like 1
Link to comment
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.

Link to comment
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 by cybrnook
Link to comment
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.

  • Like 1
Link to comment
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.

Link to comment
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 by Arndroid
Link to comment
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 ;)

Link to comment

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 by cybrnook
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.