YoutubeDL-Material: ERROR: connect ECONNREFUSED 127.0.0.1:27017

I had the same problem and turned on logging for the mongodb container. Turns out that in my case mongodb was throwing an error and refusing to start. This is because on the newer versions of mongo (v5+) they have a requirement for ARM builds where the host CPU must meet the ARM spec ARMv8.2-A. I guess raspberry pi 4 doesn’t meet that or it can’t detect that it can when in docker. Either way I just set the image to an older version:

image: mongo:4.4.6

TL;DR mongodb version 5+ doesn’t work on raspberry pi 4 in docker, so I set the mongodb image to v4.4.6

Thanks for reply.

@GlassedSilver I was debugging and found that by default tries to connect to mongodb and when its not found after few retries it uses json.

So basically default image is working fine just need to wait few minutes.

I think I fixed the issue in #657! Commit: 55d4f74

Comfirmed! I patched my local app.js file and it started up instantly, zero delay. Fantastic!

How do I get it to stop trying to connect to mongodb on startup and always just use the local json file? I have tried setting: ytdl_use_local_db: true and use_local_db: true but neither one made it skip the mongodb check on start that makes it start up so slow.

In fact, the docs say that use_local_db defaults to true… so this shouldn’t even need to be set. It shouldn’t be trying to connect to mongodb unless specifically told to, no?

The docker-compose.yml does not work for me when attempting to use mongo.

getaddrinfo EAI_AGAIN ytdl-mongo-db
ECONNREFUSED 127.0.0.1:27017
Failed to connect to MongoDB, using Local DB as a fallback. Make sure your MongoDB instance is accessible, or set Local DB as a default through the config.

version: "2"
services:
   ytdl_material:
       environment: 
           ALLOW_CONFIG_MUTATIONS: 'true'
           ytdl_mongodb_connection_string: 'mongodb://ytdl-mongo-db:27017'
           ytdl_use_local_db: 'false'
           write_ytdl_config: 'true'
       restart: always
       depends_on:
           - ytdl-mongo-db
       volumes:
           - ./appdata:/app/appdata
           - ./audio:/app/audio
           - ./video:/app/video
           - ./subscriptions:/app/subscriptions
           - ./users:/app/users
       ports:
           - "8998:17442"
       image: tzahi12345/youtubedl-material:nightly
   ytdl-mongo-db:
       image: mongo
       ports:
           - "27017:27017"
       logging:
           driver: "none"          
       container_name: mongo-db
       restart: always
       volumes:
           - ./db/:/data/db

Found the issue.

Change MongoDB’s container name to ytdl-mongo-db so it matches the URL passed to YTDL-M container configs, so that it looks like this:

version: "2"
services:
    ytdl_material:
        environment: 
            ALLOW_CONFIG_MUTATIONS: 'true'
            ytdl_mongodb_connection_string: 'mongodb://ytdl-mongo-db:27017'
            ytdl_use_local_db: 'false'
            write_ytdl_config: 'true'
        restart: always
        depends_on:
            - ytdl-mongo-db
        volumes:
            - ./appdata:/app/appdata
            - ./audio:/app/audio
            - ./video:/app/video
            - ./subscriptions:/app/subscriptions
            - ./users:/app/users
        ports:
            - "8998:17442"
        image: tzahi12345/youtubedl-material:nightly
    ytdl-mongo-db:
        image: mongo
        ports:
            - "27017:27017"
        logging:
            driver: "none"          
        container_name: ytdl-mongo-db
        restart: always
        volumes:
            - ./db/:/data/db

I will make a PR to fix this inconsistency.

Sometimes it takes a while and some distance to spot these sorts of issues. (I personally deployed differently, so my working setup never challenged this docker-compose.yml.

Hello, I was having the same problem so I checked the docker-compose.yml from the repo here and noticed that the mongodb instance was moved to another container.

I guess you can try to play with the env ytdl_mongodb_connection_string or ytdl_use_local_db, but I didn’t test it. In my case I just recreated both containers using the updated docker-compose.yml from the repo.

Cheers