[unsolved] Unpackerr is not finding any files

[jclsn]

So I have configured the API keys for Lidarr etc. and mounted the downloads folder. Unpackerr is successfully connecting to Lidarr, but doesn't get any information about any downloads, nor does it detect the zip files and unpack them.

I am also not able to attach to the container with docker exec -it unpackerr /bin/bash for some reason. I also tried /bin/ash, but no luck either. It is not finding the path of the shell, which is weird.

File permissions are also correct.

Here is my compose file:

version: "3.7"
services:

  unpackerr:
    image: golift/unpackerr
    container_name: unpackerr
    volumes:
      - /data/downloads:/downloads
    restart: always
    user: 1000:1000
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin

      # General config
      - UN_DEBUG=false
      - UN_LOG_FILE=
      - UN_LOG_FILES=10
      - UN_LOG_FILE_MB=10
      - UN_INTERVAL=2m
      - UN_START_DELAY=1m
      - UN_RETRY_DELAY=5m
      - UN_MAX_RETRIES=3
      - UN_PARALLEL=1
      - UN_FILE_MODE=0644
      - UN_DIR_MODE=0755
      # Sonarr Config
      - UN_SONARR_0_URL=http://localhost:8989
      - UN_SONARR_0_API_KEY=somekey
      - UN_SONARR_0_PATHS_0=/downloads
      - UN_SONARR_0_PROTOCOLS=torrent
      - UN_SONARR_0_TIMEOUT=10s
      - UN_SONARR_0_DELETE_ORIG=false
      - UN_SONARR_0_DELETE_DELAY=5m
      # Radarr Config
      - UN_RADARR_0_URL=http://localhost:7878
      - UN_RADARR_0_API_KEY=somekey
      - UN_RADARR_0_PATHS_0=/downloads
      - UN_RADARR_0_PROTOCOLS=torrent
      - UN_RADARR_0_TIMEOUT=10s
      - UN_RADARR_0_DELETE_ORIG=false
      - UN_RADARR_0_DELETE_DELAY=5m
      # Lidarr Config
      - UN_LIDARR_0_URL=http://localhost:8686
      - UN_LIDARR_0_API_KEY=somekey
      - UN_LIDARR_0_PATHS_0=/downloads
      - UN_LIDARR_0_PROTOCOLS=torrent
      - UN_LIDARR_0_TIMEOUT=10s
      - UN_LIDARR_0_DELETE_ORIG=false
      - UN_LIDARR_0_DELETE_DELAY=5m
      # Folder Config
      - UN_FOLDER_0_PATH=/downloads
      - UN_FOLDER_0_EXTRACT_PATH=/downloads
      - UN_FOLDER_0_DELETE_AFTER=10m
      - UN_FOLDER_0_DELETE_ORIGINAL=false
      - UN_FOLDER_0_DELETE_FILES=false
      - UN_FOLDER_0_MOVE_BACK=false

    security_opt:
      - no-new-privileges:true

and the logs

2023/05/20 07:30:48 Unpackerr v0.11.2 Starting! PID: 1, UID: 1000, GID: 1000, Now: 2023-05-20 07:30:49 +0200 CEST
2023/05/20 07:30:48 ==> GoLift Discord: https://golift.io/discord <==
2023/05/20 07:30:48 ==> Startup Settings <==
2023/05/20 07:30:48  => Sonarr Config: 1 server: http://localhost:8989, apikey:true, timeout:10s, verify ssl:false, protos:torrent, syncthing: false, delete_orig: false, delete_delay: 5m0s, paths:["/downloads"]
2023/05/20 07:30:48  => Radarr Config: 1 server: http://localhost:7878, apikey:true, timeout:10s, verify ssl:false, protos:torrent, syncthing: false, delete_orig: false, delete_delay: 5m0s, paths:["/downloads"]
2023/05/20 07:30:48  => Lidarr Config: 1 server: http://localhost:8686, apikey:true, timeout:10s, verify ssl:false, protos:torrent, syncthing: false, delete_orig: false, delete_delay: 5m0s, paths:["/downloads"]
2023/05/20 07:30:48  => Readarr Config: 0 servers
2023/05/20 07:30:48  => Folder Config: 0 paths, event buffer: 20000
2023/05/20 07:30:48  => Using env variables only. Config file not found.
2023/05/20 07:30:48  => Parallel: 1
2023/05/20 07:30:48  => Passwords: 0 (rar/7z)
2023/05/20 07:30:48  => Interval: 2m
2023/05/20 07:30:48  => Start Delay: 1m
2023/05/20 07:30:48  => Retry Delay: 5m, max: 3
2023/05/20 07:30:48  => Debug / Quiet: false / false
2023/05/20 07:30:48  => Activity / Queues: false / 1m
2023/05/20 07:30:48  => Directory & File Modes: 0755 & 0644
2023/05/20 07:30:48  => Webhook Configs: 0 URLs
2023/05/20 07:30:48  => Command Hook Configs: 0 cmds
2023/05/20 07:30:48 [Lidarr] Updated (http://localhost:8686): 0 Items Queued, 0 Retrieved
2023/05/20 07:30:48 [Radarr] Updated (http://localhost:7878): 0 Items Queued, 0 Retrieved
2023/05/20 07:30:48 [Sonarr] Updated (http://localhost:8989): 0 Items Queued, 0 Retrieved
2023/05/20 07:31:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:31:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:32:48 [Lidarr] Updated (http://localhost:8686): 0 Items Queued, 0 Retrieved
2023/05/20 07:32:48 [Radarr] Updated (http://localhost:7878): 0 Items Queued, 0 Retrieved
2023/05/20 07:32:48 [Sonarr] Updated (http://localhost:8989): 0 Items Queued, 0 Retrieved
2023/05/20 07:32:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:32:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:33:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:33:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:34:48 [Lidarr] Updated (http://localhost:8686): 0 Items Queued, 0 Retrieved
2023/05/20 07:34:48 [Radarr] Updated (http://localhost:7878): 0 Items Queued, 0 Retrieved
2023/05/20 07:34:48 [Sonarr] Updated (http://localhost:8989): 0 Items Queued, 0 Retrieved
2023/05/20 07:34:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:34:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:35:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:35:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:36:48 [Lidarr] Updated (http://localhost:8686): 0 Items Queued, 0 Retrieved
2023/05/20 07:36:48 [Radarr] Updated (http://localhost:7878): 0 Items Queued, 0 Retrieved
2023/05/20 07:36:48 [Sonarr] Updated (http://localhost:8989): 0 Items Queued, 0 Retrieved
2023/05/20 07:36:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:36:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:37:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:37:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]
2023/05/20 07:38:48 [Lidarr] Updated (http://localhost:8686): 0 Items Queued, 0 Retrieved
2023/05/20 07:38:48 [Radarr] Updated (http://localhost:7878): 0 Items Queued, 0 Retrieved
2023/05/20 07:38:48 [Sonarr] Updated (http://localhost:8989): 0 Items Queued, 0 Retrieved
2023/05/20 07:38:48 [Unpackerr] Queue: [0 waiting] [0 queued] [0 extracting] [0 extracted] [0 imported] [0 failed] [0 deleted]
2023/05/20 07:38:48 [Unpackerr] Totals: [0 retries] [0 finished] [0|0 webhooks] [0|0 cmdhooks] [stacks; event:0, hook:0, del:0]

[davidnewhall]

Seems to be working. What are you expecting to happen/show up?

[davidnewhall]

Also, wait a minute, how does localhost work in a Docker container? hm, that URL isn't right..

[jclsn]

Well, I was hoping that it would find and unpack the zip files in the download directory, so they can be grabbed by Lidarr. The localhost is just a placeholder. I actually have the real host name in its place.

Maybe I am understanding this service wrong.

[davidnewhall]

I was hoping that it would find and unpack the zip files in the download directory,

It picks up things in the Starr app queues. According to the output, there's nothing in the Lidarr queue. Do you see something in the queue in the GUI?

[jclsn]

Yeah, there are things in the download queue if you mean that. After the download the zip files are lying in the folder and are not being grabbed. Unpackerr doesn’t recognize any of that though.

[Mladia]

Well, I was hoping that it would find and unpack the zip files in the download directory, so they can be grabbed by Lidarr. The localhost is just a placeholder. I actually have the real host name in its place. Maybe I am understanding this service wrong.

If you are not using the *arr applications, you don't need to have them in the config.

Also, I think I understand your problem, since I am facing it as well: There are archives in the watch folder. The archives are not added to the queue and as a consequence are not unpacked.

[davidnewhall]

HI @Mladia thanks for helping out. In your case, Unpackerr only sees "new" items in the watch folder. To make old things new, simply rename them. The easiest way is to make a new folder (after you start unpackerr) in the watch folder, and them move everything you want extracted into that folder. Once unpackerr is done, move the extracted items back, or to wherever you want them. If you still need assistance, please crack open a new issue, or join me on Discord.

@jclsn I feel like we're poorly communicating. Can you go into Lidarr, click on Activity and then Queue. The things in this list are what Unpackerr will attempt to extract. According to the logs, the Lidarr that is being checked has nothing in that queue. Can you share a screenshot?

An unrelated-to-this problem is that you have these lines in your compose file and they do not do anything, so your container is running unpackerr as root.

environment:
  - PUID=1000
  - PGID=1000

Instead of these lines, add a user: 1000:1000 parameter to the compose directives, similar to the example.

[Mladia]

Hi @davidnewhall. Thanks for your reply! I understand now and it worked. My initial understanding was that all archives in the watch folder will be unpacked. It turns out, that unpackerr looks for new folders in the watch folder with zips in them. I find this unintuitive, but I still understand that probably the most common use-case fits exactly into this scenario.

[jclsn]

Sorry, I lost interest for a while. No idea what I am doing wrong. Lidarr is downloading the files and they are immediately removed from the queue, although they have never been unpacked or grabbed. I really don't understand how this works.

[bakerboy448]

• in Starr speak - a grab is from an indexer to a download client....not sure what you mean by grabbed here.....imports or upgrades are imports.
• Lidarr would never automatically remove something from the queue that it did not import, so one of the following would be true:
  • Lidarr IS finding music files that match the release and importing them then changing the category or removing from queue as you configured lidarr to do. History in Lidarr would confirm this.
  • your download client is removing the downloads from queue which is not compatible with Lidarr nor Unpackerr using Starr
  • you or a third party app are removing the download from lidarr's queue and telling lidarr to ignore it. History in Lidarr would confirm this.
  • you or a third party app are changing the category of the download in the client so it is no longer in lidarr's download client category

[jclsn]

Well, I thought to grab means to move the files from the download folder to my music root folder. This never happens. The zip files just remain in the download folder and nothing is ever imported. Unpackerr also doesn't see anything in the queue.

No idea what is wrong here. It works well with Sonarr and Radarr, but those also don't need unpacking.

[bakerboy448]

Figure out why things are vanishing from Lidarr's queue. the possibilities have been provided.

[jclsn]

Yeah, all the files land in the history immediately and then never get imported. So I guess the first point is the case. I don't see any settings on what to tell Lidarr to import. Seems like it can't import zip files. I thought unpackerr would come into play here.

I just tried manually extracting the archive and then the files land in the album lands in the queue and gets imported afterwards. Seems like the only step missing is the extracting. I would be happy if unpackerr just blindly extracts all the zip files in the folder, but not even that works, although I have the folder config enabled.

What is weird is that unpackerr is also detecting files after I manually extracted them.

[bakerboy448]

Yeah, all the files land in the history immediately and then never get imported.

Screenshot. This doesn't make sense and if a release is showing in Lidarr history as imported then Lidarr is matching and importing music files in the folder.

[jclsn]

First entries are the tracks that got imported after manual extraciton. Everything after that is only zip files, which never get moved anywhere.

[bakerboy448]

Nothing in that screenshot indicates Lidarr is importing anything other than the Kings of Convenience tracks - all of those cloud icons are grabs so the releases were sent to your download client.

That means one of the following must be true for Beck and De La Soul given you indicated that Activity => Queue is empty even with Options => Shown Unknown Enabled.

• your download client is removing the downloads from queue which is not compatible with Lidarr nor Unpackerr using Starr
• you or a third party app are changing the category of the download in the client so it is no longer in lidarr's download client category

[jclsn]

Okay, it may have something to do with that I am not using torrents directly. I am sending them to a service which then downloads them via aria2 to the download folder. It is configured as a torrent blackhole download client. Then the starr apps monitor that folder and usually import well. Here it doesn't work for some reason. I wouldn't know how the download client would remove the files from the queue though. Is that maybe a sideeffect of the blackhole download client configuration?

[bakerboy448]

I feel like we're poorly communicating. Can you go into Lidarr, click on Activity and then Queue. The things in this list are what Unpackerr will attempt to extract. According to the logs, the Lidarr that is being checked has nothing in that queue. Can you share a screenshot?

Again as captain said originally - if nothing is in Starr's queue then unpackerr will not have anything to unpack. If you're using a blackhole client as you imply then they should still show in Starr Queue with show unknown enabled.

I'd suggest visiting Lidarr's Discord for further support with nothing ever showing in Lidarr's Activity => Queue even with show unknown enabled for a blackhole client. Bring your queue screenshots and lidarr trace logs

edit: Aria2 is also natively supported in Lidarr; so not sure why you're not just using it directly? Remote download client isn't an issue either - https://wiki.servarr.com/lidarr/troubleshooting#remote-path-mapping

[davidnewhall]

Sorry you're dealing with this @jclsn. I read through this conversation and it sounds like Lidarr is doing something strange. Items should not leave the queue unless they get imported, or deleted from your download client (or category changed). Figuring out what's happening with Lidarr should get Unpackerr working. Good luck!

[jclsn]

I would be happy if unpackerr would just blindly unzip everything in the folder. That shouldn't be related to Lidarr at all

[davidnewhall]

Extracting everything wouldn't solve the problem because by the time Unpackerr finishes extracting, Lidarr has already decided it's done caring about the thing.

[jclsn]

Actually it does solve the problem, as I mentioned above: After extracting the files land in the queue again and get imported.

[davidnewhall]

Your Lidarr works very differently than mine. Not sure what to make of it.

[bakerboy448]

Your Lidarr works very differently than mine. Not sure what to make of it.

it's 100% related to the blackhole client.....but the fact the blackhole client isn't detecting anything at all is the oddity to solve. it may not be looking for archived files to be honest.

but given Arira2 is natively supported in lidarr, hopefully jclsn can remove the blackhole client - which isn't recommended anyway :/ - from the equation

[jclsn]

@bakerboy448

No I can't use the aria2 download client. I am using my own service as a bridge between Lidarr and a Debrid service. It basically looks for torrent files, sends them to the Debrid service, waits for the caching to finish and then sends the direct download link to aria2 which downloads the files to the download folder that Lidarr is monitoring.

It is really neat, because I don't have to use torrents directly.

[bakerboy448]

Ah, well best of luck with everything then.

Debrid is unfortunately rather toxic to the torrent community as it is 100% leeching...and torrenting relies on having seeders. Usenet would be better route for Debrid users who cannot for whatever reason seed. :\

[jclsn]

I guess that is up to the Debrid service providers.

Anyway, how can I get unpackerr to blindly extract things? This is my current configuration and it doesn't work.

### Unpackerr docker-compose.yml Example
### See this URL for variable descriptions and options:
### https://github.com/Unpackerr/unpackerr#docker-env-variables
##################################################################
version: "3.7"
services:

  unpackerr:
    image: golift/unpackerr
    container_name: unpackerr
    volumes:
      - /data/aria2/downloads:/downloads
    restart: always
    user: 1000:1000
    environment:
      - TZ=Europe/Berlin

      # General config
      - UN_DEBUG=false
      - UN_LOG_FILE=
      - UN_LOG_FILES=10
      - UN_LOG_FILE_MB=10
      - UN_INTERVAL=2m
      - UN_START_DELAY=1m
      - UN_RETRY_DELAY=5m
      - UN_MAX_RETRIES=3
      - UN_PARALLEL=1
      - UN_FILE_MODE=0644
      - UN_DIR_MODE=0755

      # Folder Config
      - UN_FOLDER_0_PATH=/downloads
      - UN_FOLDER_0_DELETE_AFTER=10m
      - UN_FOLDER_0_DELETE_ORIGINAL=false
      - UN_FOLDER_0_DELETE_FILES=false
      - UN_FOLDER_0_MOVE_BACK=false

    security_opt:
      - no-new-privileges:true

Does it not support zip files?

[jclsn]

Ah what the heck. Gonna write me a shell script...