A couple of issues

[f1nlay]

Edit: I believe these issues to be related to my use of Gluetun with NZBdav. I have since updated my configuration to no longer use Gluetun, and it's all running smoothly again.

---

Hi! Just wanted to say that this project is incredible - but there are a couple of problems which I'm facing with my instance.

I'm not really sure how to reproduce these issues (hence why I am creating a more information discussion post, rather than an issue) as they seem to occur somewhat randomly, but I will try my best to describe them to see if anyone else is having similar problems.

I'm using the latest build, through Docker compose, with the recommended configuration defined in the README.

1. Entries in the queue occasionally get stuck processing at 99%.

• For the most part, this seems to happen on larger files (usually long 4K movies, around 50 GB+) - but not sure how to reproduce consistently.
• Once stuck the entry is unable to be removed from the queue - clicking the delete button causes it to become greyed out but does nothing. Cannot remove from Radarr queue either. Also, the active Usenet connections number drops down to around 1-3.
• Nothing is printed to the logs when this happens.
• The only way to fix this is to restart the container entirely!

2. Connections sometimes drop when watching via Jellyfin.

• Watching through Jellyfin usually works okay, but sometimes the connection to Usenet will be aborted causing the client's buffer to stop populating.
• The active Usenet connections number also drops down whenever this happens.
• Again, not very sure how to reproduce this - though anecdotally it seems to perhaps occur more often when a queue is being processed at the same time? It seems to happen both when direct playing and when transcoding.
• Nothing is printed to NZBdav logs, nor anything of note to Jellyfin logs.

[nzbdav-dev]

When no.1 happens, could you grab that nzb from the /nzbs folder and send it to [email protected]?

• I know you mentioned that it happens randomly and I may not reproduce by simply trying to download the same nzb, but just in case..
• (Note: The /nzbs folder on the webdav mirrors the queue. Any item in the queue will be in the /nzbs folder and you can also add items to the queue by dropping them into the /nzbs folder)

For no.2, can you post your rclone mount options?

[spantobi]

Those two issues that @f1nlay has are exactly the same problems I’m having as well, except I’m using Plex. The logs don’t show anything unusual. I tried watching an episode yesterday, and Plex kept crashing at random points. My downloads also keep hanging around 99% several times a day.

I’m currently running nzbdav 0.4.17.

my rclone settings:

  rclone:
    image: rclone/rclone:1.71.2
    restart: unless-stopped
    devices:
      - /dev/fuse:/dev/fuse
    cap_add:
      - SYS_ADMIN
    security_opt:
      - apparmor:unconfined
    command:
      - "mount"
      - "nzbdav-webdav:"
     
      - "/data/nzbdav"
      - "--allow-other"
      - "--allow-non-empty"
      - "--vfs-cache-mode=full"
      - "--vfs-cache-max-size=5G"
      - "--vfs-cache-max-age=180m"
      - "--buffer-size=1G"
      - "--dir-cache-time=1s"
      - "--use-cookies"
      - "--uid=5000"
      - "--gid=5000"
      - "--links"
    volumes:
      - /opt/rclone/config:/config/rclone
      - /files/data:/data:rshared

networks:
  media-stack:
    external: true

[f1nlay]

Hi, just to update - I think I have found a contributing factor to why these problems occur.

The issues seem to be related to Gluetun. For convenient communication with my existing *arr stack, I was previously routing the NZBdav contain through a Gluetun VPN. I have since realised that this is unnecessary and have stopped using Gluetun with NZBdav, and it has been running smoothly for almost a week now!

I'm still not sure why using NZBdav with Gluetun causes these issues to crop up - my guess is that the VPN connection is unstable and NZBdav may not always correctly handle situations in which the connection drops out, but I'm just speculating.

Either way, I have no need to ever use NZBdav with Gluetun - so if this is the same issue that @spantobi is having then maybe it could be worth adding a disclaimer to the README?

Hope this is of help to someone, will update my original post.

[spantobi]

@f1nlay I also use Gluetun, but only for qBittorrent. Since the newgroups part is all done through SSL, there really isn't any reason to route that traffic through a VPN, which seems to confirm your thinking.

I am still having problems with downloads hanging/pausing, but this only seems to happen if I add hundreds or thousands of downloads at once.

Separately, I did manage to solve an issue with playback hanging or crashing by turning off hardware-accelerated transcoding on my iGPU. It used to work fine, but I don't know what changed. When I turned it off and switched to using the CPU alone, it became stable again.