jlesage / docker-handbrake

Docker container for HandBrake
MIT License
812 stars 92 forks source link

container crashes when adding multiple files/folder #154

Open wbilger opened 3 years ago

wbilger commented 3 years ago

I used to be able to do this without issue, but now anytime I try to add a folder, to then add multiple files to the queue, the container crashes. This is the log from the docker container;

[services.d] stopping services [services.d] stopping app... [services.d] stopping x11vnc... caught signal: 15 04/11/2020 15:33:36 deleted 40 tile_row polling images. 04/11/2020 15:33:36 Restored X server key autorepeat to: 1 [services.d] stopping logmonitor... [services.d] stopping certsmonitor... [services.d] stopping nginx... [services.d] stopping statusmonitor... [services.d] stopping openbox... [services.d] stopping xvfb... The XKEYBOARD keymap compiler (xkbcomp) reports:

Warning: Unsupported high keycode 372 for name ignored X11 cannot support keycodes above 255. This warning only shows for the first high keycode. Errors from xkbcomp are not fatal to the X server [services.d] stopping autovideoconverter... [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.

Raiu commented 3 years ago

I got the same problem. Pulled the lastest from docker hub as of 20-11-17 but the problem persist

jlesage commented 3 years ago

Could you look at ghb/Activity.log.XXXX (under the folder you mapped to /config) to see if we can get more details about the error ?

Raiu commented 3 years ago

This is the log content after a restart and attempting to open a source with multiple files:

[16:32:12] gtkgui: HandBrake 1.3.3 (2020080500) - Linux x86_64 - https://handbrake.fr
Cannot load libnvidia-encode.so.1
[16:32:12] hb_init: starting libhb thread
[16:32:12] hb_init: starting libhb thread
[16:32:12] hb_init: starting libhb thread

I have tested two different browsers, edge (chromium) and firefox. Both with the same result.

This container worked during the summer and i cant remember doing anything else to it since, but yesterday when i tried to start an encode it wont work and just hard crash and restart the container

Raiu commented 3 years ago

Managed to get some more info from logs, didnt realize at first that the log file was overwritten on restart

[23:11:08] gtkgui: HandBrake 1.3.3 (2020080500) - Linux x86_64 - https://handbrake.fr
Cannot load libnvidia-encode.so.1
[23:11:08] hb_init: starting libhb thread
[23:11:08] hb_init: starting libhb thread
[23:11:08] hb_init: starting libhb thread
[23:11:29] CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
[23:11:29]  - Intel microarchitecture Ivy Bridge
[23:11:29]  - logical processor count: 32
[23:11:29] Intel Quick Sync Video support: no
[23:11:29] hb_scan: path=/storage/shows/Marvels.Agents.of.S.H.I.E.L.D/S01, title_index=0
disc.c:424: error opening file BDMV/index.bdmv
disc.c:424: error opening file BDMV/BACKUP/index.bdmv
bluray.c:2585: nav_get_title_list(/storage/shows/Marvels.Agents.of.S.H.I.E.L.D/S01/) failed
[23:11:29] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.1
libdvdread: Couldn't find device name.
libdvdread:DVDOpenFilePath:findDVDFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFilePath:findDVDFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[23:11:29] dvd: not a dvd - trying as a stream/file instead
jlesage commented 3 years ago

I tried to reproduce without success. Could you try with the image and provide the exact steps you are doing to reproduce the crash ?

puralpha commented 3 years ago

I had the same issue. Worked fine and now crashes/container restarts when File > Open Source > selecting a folder. No issue with File > Open Source > selecting a single file.

I use mergerFS and I have this issue when the pooled directory is mapped as a volume, no issue when the proper (physical directory) is mapped instead.

Perhaps some issue with mergerFS or FUSE?