Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Jav-It

The most comprehensive JAV video cataloging tool. · By jav-it

[ANSWERED] Docker container for jav-it

A topic by Hawker2 created Jan 19, 2022 Views: 724 Replies: 7
Viewing posts 1 to 4

I whipped up a (very) simple Docker container to use with the Linux binary; not sure if that's something you'd be interested in? It's nice because on a command-line Linux system it avoids having to download a whole bunch of X11/graphics related stuff to address certain dependencies; they stay nicely self-contained in the Docker image.

On that note, when it says "Verifying if support modules require downloading and caching", which directory is that going to? I'd like to create a persistent volume for the cache so it doesn't have to download it every launch.

Developer

Hi,

Thanks for the kind reply. I don't personally have a need for a Docker container since I rarely need to use it on such a stripped down system. Since the binary is already quite self contained, it usually just works "out of box" like any other CLI application. However, I'd still be interested in seeing any docker-compose definitions you come up with (just for fun/curiosity).  In regards to your question, the "<home>/.cache" folder is where support files go on a Linux machine. So you'd want to mount that so any applications can cache data.

I'll add in a volume for the cache and post it shortly. The container also builds in ffmpeg for concatenating multi-part movies and shifting the resulting data to a more standard container format (MKV presently, although MP4 would be preferable).

Developer

Thanks! I assume you'll probably need two volumes. One for the cache and one where users place the Jav-It binary and/or other work files.

I've been on the fence about whether or not to include the binary in the container (note, I have *no* plans on uploading this to github or the Docker Hub; I'd just post the Dockerfile and docker-compose.yml here for you). The reason I lean towards the binary being in the container is the image should be immutable and self-contained, or else you could get unexpected behavior with future jav-it builds (even though this is unlikely). On the other hand, since the jav-it binary is paid registered software, it's a bit weird to put it in a container, even if it isn't distributed.

Developer

Ah, thanks for the kind consideration. In regards to your thoughts, I would mostly agree (I also like containers to be immutable). The only thing I would consider is, this project limits / disables versions that are considered out of date. So as new versions are released, previous versions are retired. This is done mostly to limit service/support tickets open on older versions which are a pain to troubleshoot (especially when simply using the latest version resolve the problem).

That's why I initially suggested having a mount location for the binary, and other upgradable files, since it would make swapping things out super easy. As a side effect, if people wanted to upgrade to the Patreon version and use your recipe, it would make it easy for people to add the latest subtitle definitions files anytime a new pack is released.

Makes sense. I already load in cookies from a volume mount (as those change every couple videos), but I'll consider changing the binary location as I go.

(1 edit) (+2)

In the interest of keeping this at the top discussion level, here's the detail (pain-in-the-ass forum software strips carriage returns on paste, and removes all blank lines on post).

Dockerfile

FROM debian:stable-slim
# Install base tools to support firefox
ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update RUN apt-get install -y --no-install-recommends \
    libgtk-3-0 gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 \
    libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 \
    libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 \
    libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 \
    libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxt6 libxtst6 \
    ca-certificates fonts-liberation libnss3 lsb-release xdg-utils wget ffmpeg
# Create a base environment to work
RUN set -xe && mkdir -p /output /cookies /app /root/.cache
VOLUME /output /cookies /root/.cache
ENV PATH="/app:${PATH}"
ENV LANG="en_US.UTF8"
# Setup the executable/script
WORKDIR /app
COPY jav-it        jav-it
COPY dictionary.csv dictionary.csv
COPY jav-it.sh      jav-it.sh
RUN chmod 555 /app/*
# Run the process script
ENTRYPOINT ["/app/jav-it.sh"]

jav-it.sh

#!/bin/bash
CONTENTID=$1
FILENAME=$2
# Default - don't keep temp files
KEEP="${keep_temp:=false}"
# Default - use mkv for the container
EXT="${container:=mkv}"
TMP="/tmp/jav-it"
download() {
    # Download video from R18 and decrypt to *.ts
    /app/jav-it download -c /cookies/cookies.txt -i $1 -o "$TMP"
}
transcode() {
    # Convert a list of *.ts files to a single mkv
    ffmpeg -f concat -safe 0 -i "$TMP/$1-parts.txt" -c copy -bsf:a aac_adtstoasc "/output/$2.$3"
}
# Attempt to download the video
mkdir -p  "$TMP"
if download $CONTENTID; then
    # If successful, list all *.ts files and pass them to ffmpeg for transcoding
    for i in `ls "$TMP/$CONTENTID"*.ts | sort -V`; do echo "file '$i'"; done >> "$TMP/$CONTENTID-parts.txt"
    transcode $CONTENTID $FILENAME $EXT
    # Check whether we should keep the intermediate files
    if [[ $KEEP != 'false' ]]; then
        mv "$TMP/"* /output/
    fi
fi

docker-compose.yml

version: "3"
services:
  jav-it:
    build: .
    image: jav-it/jav-it
    container_name: jav-it
#    environment:
#      keep_temp: 'true'
#      container: 'mkv'
    volumes:
      - ./output:/output
      - ./cookies:/cookies
      - cache:/root/.cache
    labels:
      com.centurylinklabs.watchtower.enable: false
volumes:
  cache:

Once these are all saved in a directory along with the jav-it binary and dictionary.csv:

docker-compose build
mkdir output cookies
# Move your cookies file to cookies/cookies.txt
# docker-compose run --rm jav-it <contentid> <filename>
docker-compose run --rm jav-it 1atom00150 ATOM-150

If all went well (and works like it does on my machine - obligatory "Docker: We'll ship your machine" meme), then it will download its dependencies to the cache volume, download the streams one by one to a temp dir, and finally ffmpeg them together into a single MKV in the output directory, then remove the container and temp files.