Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About rbroberts

  • Rank
    Advanced Member


  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You'll notice two places where you specify an output directory, the first is what server path is mounted on the container as /output. The second is where you want the output to be written, it defaults to /output, but it can be any subdirectory of that. Since you can specify the actual output to be any subdirectory of the container mount point /output, and /output can be mounted from anyplace on the server, so I think that should count as being possible to change the output location.
  2. So, there's a workaround. Each instance has it's own /watch and /output, but they don't do any moving of files; instead if it's not for them, they just delete the input. Yes, they do. The trick is in the setup. I'm going to script this, but roughly, under the assumption that my directory structure is no more than one level, i.e., /watch/MyMovie/MyMovie.mkv, and other files in the MyMovie directory, I do the following. First, my watch directory on the server is not where the containers looks. I have /mnt/user/Videos/rip/watch/{1080,0720,0480}, three directories. But I drop the MyMovie directory in .../watch. Then I run a script that does this: for X in [A-Z]*; do for D in 0480 0720 1080; do mkdir -p $D/"$X"; ln -t $D/"$X" "$X"/*; done; done for X in [A-Z]*; do for D in 0480 0720 1080; do mkdir -p $D/"$X" ln -t $D/"$X" "$X"/* done done Since I have hard links, they've visible in the container mount points. And since they're hard links, the setup is fast, no data is copied, and deleting doesn't really remove the original. And I can easily tell when things are really done.
  3. And...a veto would be much nicer that the move stuff anyway. I really do like that one watch directory for them all. The 480p and 720p configs convert much faster than the 1080p (naturally), so stacking them behind the 1080p partially defeats the parallel setup.
  4. Hmm. I've set this up with a single /watch all mapped the same for each converter and, for blurays, this seems like it will work well. In fact, I've set up three instances and assigned different CPU sets to each instance, so they can run in parallel and not fight each other. But.... Only my 480p config makes sense for DVDs. All three instances will try to rip them, and I have a post conversion script that will rename them so they don't conflict when I eventually merge the outputs, but the 1080p config's output won't be any different than the 480p config's output. With the old single instance, the pre conversion script would detect that and move the input to the next queue. Looking at autovideoconverter/run, there doesn't seem to be any way to veto a conversion except to move the input file.
  5. I don't really know what's "normal" for /storage, I'm not completely sure why it's there at all. But I generally make it a parent directory of all the video-related things I want to operate on. Then I have subdirectories that map one-to-one with the container. My original config looked like this: /storage => /mnt/user/Videos/rip /watch => /mnt/user/Videos/rip/watch /output => /mnt/user/Videos/rip/output I use MakeMKV to rip the original media into /mnt/user/Videos/rip/staging. Then once that's done and I've renamed my files to something meaningful, I move the whole directory into "watch". Once Handbrake is finished, I move the watch subdirectory into /mnt/user/Videos/rip/done, and the output subdirectory into my Plex tree. You could, of course, just have Handbrake convert directly into your Plex output directory, which seems to be what you were aiming for, but I prefer to have Plex be ignorant of what's in process until I'm done.
  6. That looks really strange to me. One of my instances looks like this: What looks weird in yours is those extra mounts that seem to be mapping a path on the host to the same path in the container.
  7. I assume you meant /storage => /mnt/user/Plex Media/Converted Videos/ /watch => /mnt/user/Plex Media/Converted Videos/ /output => /mnt/user/Plex Media/Converted Videos/ /config => /mnt/user/appdata/Handbrake If not, then you'll have to explain a bit more. I'm not sure docker will let you munt the same directory three times with different permissions. /storage is normally read-only. /watch normally is, but doesn't have to be. /output is obviously read-write. Also, if your input and output containers are the same type, you're going to shoot yourself in the foot.
  8. Bummer, and I thought I would have to give this a try 😁
  9. Actually, that's pretty clever. I was actually thinking of trying to install a second instance of the container to see if is possible to rip the different versions in parallel, and that would very neatly work for that, too.
  10. Yeah, nvm. I had autoupdate turned on. I'm not sure if it really pulled an update last night, still looking, but that seems the most likely explanation.
  11. Hmm, this is not exactly a HandBrake question. This looks like my container restarted last night, which orphaned a nearly completed transcode. Any ideas on how to track down why it restarted? Encoding /watch/Avatar/Avatar.mkv: 85.38 % (2.66 fps, avg 4.06 fps, ETA 02h19m45s) [services.d] stopping services [services.d] stopping app... [services.d] stopping openbox... [services.d] stopping statusmonitor... [services.d] stopping logmonitor... [services.d] stopping autovideoconverter... Encoding /watch/Avatar/Avatar.mkv: 85.39 % (2.72 fps, avg 4.06 fps, ETA 02h19m40s) Encoding /watch/Avatar/Avatar.mkv: 85.39 % (2.72 fps, avg 4.06 fps, ETA 02h19m40s) Encoding /watch/Avatar/Avatar.mkv: 85.39 % (2.72 fps, avg 4.06 fps, ETA 02h19m40s) s6-svlisten1: fatal: timed out [services.d] stopping x11vnc... caught signal: 15 24/03/2020 03:12:45 deleted 40 tile_row polling images. [services.d] stopping xvfb... The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Unsupported high keycode 372 for name <I372> ignored > X11 cannot support keycodes above 255. > This warning only shows for the first high keycode. > Internal error: Could not resolve keysym XF86MonBrightnessCycle > Internal error: Could not resolve keysym XF86RotationLockToggle Errors from xkbcomp are not fatal to the X server [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. [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...
  12. That doesn't look like a permission problem, but maybe I'm missing something. I assume you tried touching the file to make it appear new? Did you also look for dot files in the output directory to see if something was left lying about from a previous failed attempt? I think that touching the file is sufficient to invalidate any dot files. What am I talking about...? Right now my encoder is running and I have this: root@Tower:/mnt/user/Video/rip# find output/* -type f | grep "Yesterday (2019).mkv" output/1080/.RsjOZG/Yesterday (2019).mkv I've see those files get left if the encoding failed, or (naturally) I restarted the container.
  13. I keep looking at the existing scripts, and since I don't really understand how docker works, I'm pretty sure I'm looking in the wrong place. The watch directories get mounted in /watch, /watch2, etc., but I'm wondering what it would take to do this differently. If on the unraid server, I've got them as some-path/watch/1080, some-path/watch/0720, etc, there's nothing to prevent mounting some-path/watch and symlinking from /watch -> mount-point-for-some-path/1080, etc. Well, nothing except figuring out how to manage the configuration, though I would just throw that at the user. Maybe a flag that says use symlinks. The main point of this being that the pre- and post-conversion scripts don't have to change, and everything that assumes files in /watch, /watch2, etc., still works. Admittedly, in the overall scheme of how long it takes to do multiple conversions, the copy time is small, but still, for a single bluray video it's a few minutes.
  14. Well, my message was a bit confusing. I really want to get all the watch directories in the same tree. And I don't see a variable for that; those appear to be mount points at /watch2, /watch3, etc. So while I can make the output directories all part of the same tree, I can't seem to do that for the inputs, at least not that I can tell.
  15. Well, there was no message until I edited the run script. I've saved aside my copy, so I'll see if there is a newer version of the contain, though unraid doesn't seem to think so. The version-looking part on the screen is the repository which say jlesage/handbrake:v1.11.2....which, now that I'm looking at the support info, looks like it's really old. So I guess the mystery of why it's not working is solved, now I have to figure out why unraid thinks I'm up-to-date.