Latest added file stuck in infinite buffer when using Infuse with Jellyfin

[WLines84]

I have setup Debridav with docker compose and it works flawlessly 90% of time, however it seems that the most recent files it has added get stuck in an infinite buffer when I'm using Infuse through Jellyfin.
Example if I try to watch episode 1 I can see it perfectly, when I move to episode 2 I see like 5-10second and I get buffering screen and never moves on.

Logs seem ok on the debridav container, and I'm not even sure how to troubleshoot this.
If I mount real-debris webdav directly in infuse it works without any problems.

current config:

  debridav:
    image: ghcr.io/skjaere/debridav:v0
    container_name: debridav
    restart: unless-stopped
    environment:
      - PUID=$PUID
      - PGID=$PGID
      - TZ=$TZ
      - DEBRIDAV_ROOTPATH=${DEBRIDAV_ROOT_PATH}
      - DEBRIDAV_DOWNLOADPATH=${DEBRIDAV_DOWNLOAD_PATH}
      - DEBRIDAV_MOUNTPATH=${DEBRIDAV_MOUNT_PATH_CONTAINERS}
      - DEBRIDAV_DEBRIDCLIENTS=${DEBRIDAV_DEBRID_CLIENTS}
      - SPRING_DATASOURCE_URL=jdbc:postgresql://${DEBRIDAV_DB_HOST}:${DEBRIDAV_DB_PORT}/${DEBRIDAV_DB_DATABASE_NAME}?user=${DEBRIDAV_DB_USERNAME}&password=${DEBRIDAV_DB_PASSWO>
      - REALDEBRID_APIKEY=${REAL_DEBRID_API_KEY}
      - SONARR_INTEGRATIONENABLED=${SONARR_INTEGRATION_ENABLED}
      - SONARR_HOST=${SONARR_HOST}
      - SONARR_PORT=${SONARR_PORT}
      - SONARR_APIKEY=${SONARR_API_KEY}
      - RADARR_INTEGRATIONENABLED=${RADARR_INTEGRATION_ENABLED}
      - RADARR_HOST=${RADARR_HOST}
      - RADARR_PORT=${RADARR_PORT}
      - RADARR_APIKEY=${RADARR_API_KEY}
      - DEBRIDAV_CHUNKCACHINGSIZETHRESHOLD=0
    ports:
      - ${DEBRIDAV_PORT}:8080
      - "8000:8000"
    networks:
      - debridav-network
    volumes:
      - ${DEBRIDAV_ROOT_HOST_FS}:${DEBRIDAV_ROOT_PATH}
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8080/actuator/health/readiness" ]
      interval: 2s
      start_period: 2s
      retries: 1000
    depends_on:
      postgres-debridav:
        condition: service_healthy


  rclone:
    container_name: rclone
    image: rclone/rclone:latest
    restart: unless-stopped
    environment:
      PUID: 1000
      PGID: 1000
      UMASK: 002
    volumes:
      - ${DEBRIDAV_MOUNT_PATH_HOST_FS}:${DEBRIDAV_MOUNT_PATH_CONTAINERS}:rshared
      - $DOCKERDIR/appdata/rclone/:/config/rclone/
    cap_add:
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined
    devices:
      - /dev/fuse:/dev/fuse:rwm
    command: "mount debridav: $DEBRIDAV_MOUNT_PATH_CONTAINERS --uid 1000 --gid 1000 --default-permissions --allow-other --allow-non-empty --dir-cache-time 10s --vfs-cache-mode>
    ports:
      - "5572:5572"
    depends_on:
      debridav:
        condition: service_healthy
    networks:
      - debridav-network

[skjaere]

Are you using Easynews? What I suspect is happening is that those first five to ten seconds are cached, and then Easynews is too slow to respond, which happens from time to time. Not much I can do about that unfortunately.

You could try starting the monitoring stack and taking a look at the grafana dashboard to get some more insight into what is happening. If I'm right you should be able to see the stream from Easynews opened, but very little data being transferred.

[WLines84]

I'm using real debrid, this is what the logs show

[skjaere]

I see.
I am aware that RD has been having some issues recently, it's possible that this is related. Looking closer I see you've disabled caching, which means the first few seconds are coming from RD.

I would advise you to start the monitoring stack regardless. It will give us additional insights into the problem. In particular we want to see if data is indeed being sent over the connection.

[WLines84]

I got the monitoring stack up:
11:17 was where the buffering started and 11:20 it simply exited the video

[skjaere]

So it looks like the stream is being aborted. Aborted in this context means the client closed the stream, as in didn't stream the whole file.

Since the stream goes through rclone and jellyfin before finally reaching infuse, I would ask that you try playing the file with something like kodi which can stream directly from debridav via webdav. I think you can do this with infuse too.

I addition,

• are there errors in the rclone, jellyfin, or infuse logs?
• does this happen consistently or sporadically?
• does it happen with other files or just that one?
• is jellyfin transcoding the file?

[WLines84]

If I connect directly to real debrid webdav it works 100% of the time.

This is really sporadic, usually happens when I try to watch the latest file grabbed by the *arr apps.
It's direct streaming without transcoding
you might be on to something on the cliente side, found this error in Jellyfin:

[skjaere]

Okay, looks like jellyfin is complaining that it didn't receive all the bytes it expected. Could you please try connecting infuse directly to debridav?

Feel free to reach out to me on discord too.

[Joost1991]

It seems like I'm having the same issues, but with Plex. In Plex it now often starts to buffer, sometimes it recovers, but most of the times I have to restart the episode.

If I play the same file directly from real-debrid with WebDav in Infuse, it works fine.
If I play the same file from the DebriDav webdav, it also works fine.
If I play the same file from Plex in Infuse, it buffers.

Could it be an Rclone issue...?

[Joost1991]

Did some testing, seems like the default settings for the rclone mount can cause some trouble.

I made it use the --vfs-cache-mode=full and now it streams with no problem.

Edit: spoke too soon. Still having the same problems.

[skjaere]

So it seems that Infuse is the common denominator here. Unfortunately I do not have access to a device that can run it, so debugging this is going to be difficult for me.

@Joost1991 Infuse is capable of mounting a webdav server directly, right? Could you try doing that to see if the problem persists?

[skjaere]

I have a theory about what's happening here. The first few bytes of files are typically cached and get served fast, but there is a delay between the cached bytes and the bytes fetched from the remote source. I think this delay is causing a timeout somewhere.

A fix for this would be to disable and purge the cache.

• run curl -X DELETE http://localhost:8888/actuator/cache
• set DEBRIDAV_CHUNKCACHINGSIZETHRESHOLD=0