hotio

The Plex Autoscan github has all the information you need written down in detail. "it doesnt even load" is meaningless without logs unfortunately.

Glad to see it helped somebody...it also took me a while before I found the solution....never thought limetech wouldn't have thought about this usecase, although on ubuntu I also had to override the default systemd service. You'd expect an UI toggle to include all use cases and not just usb....

The image was changed, no longer using s6 and the default entrypoint is now "rar2fs -f -o auto_unmount" and it's now based on Alpine. The readme was updated to reflect those changes....if you would prefer the old way until you figure things out it's as easy as using an older tag with a commit before the changes. Unraid template/support has been dropped however, because the templating system imo isn't really fit to pre configure this changed behaviour. Could have told you this within a minute on discord....for some reason I'm not always getting a notification email from the forum....

There is / should be an edit function if advanced mode is enabled.....

You did enable advanced mode, right?

Modifying (or deleting and creating one manually) the default mount setting /downloads from the template, so that the files would also appear in /data inside the unpackerr container, should also solve the problem.

Try adjusting the variable to UN_SONARR_0_PATH /downloads/completed

I got confused there for a minute, I'm asking the developer....I'm not seeing it either.

sonarr says that the file is located in /data, you are mounting them in unpackerr container in /downloads

ok thanks, I don't think sweeping everything under the carpet is a good way forward especially when we are talking about something so delicate as another mans reputation. Not exactly sure why this can't be cleared up in a single post without hiding posts etc.

Why are my posts and other people's post being removed?

https://github.com/davidnewhall/unpackerr/issues

What did the app developer had to say? Did you file a bug report?

Struggling for a week? Then why not ask for support? Also from all these responses, I'm getting the impression that exactly 0 people have read the instructions.

It is not a hidden section... Using /torrents as default is a very bad idea, I can't know what the user prefers...besides for lidarr that doesn't work and neither for sonarr or radarr when/if their api gets updated to report the path in a reliable way.

What exactly is so confusing besides the most basic docker concepts of volumes and environment variables? It's almost the same steps as you had to do for sonarr, radarr, etc. Feel free to make suggestions on how to make this even easier...

Add your downloads volume and use /downloads for the env variable. Iirc I've mentioned this several times already.

It'll keep monitoring the *arr queue and when it has been imported, it'll clean up the extracted files. The ..._unpackerred folder is normal while extracting, after extraction it moves the extracted files in the original folder, so that *arr doesn't try to copy a partially extracted file.

Can't help without a log and your full settings.

I can confirm that this plugin is giving false positives....got several "corrupted" files when doing a check. Did a b2sum on the "corrupted" file and compared that with a known good version of the file, they matched. The b2sum in the hash export file is completely different...double checked this too. For tsome reason it's exporting hashes that are not correct.

You'll have to mount your downloads as "/mnt/user/Downloads/Torrents/Complete/" inside the container if you want to use that value for UN_SONARR_0_PATH. Might I suggest you use UN_SONARR_0_PATH=/torrents ....and create your volume as /mnt/user/Downloads/Torrents/Complete -> /torrents Also while you're at it, set the advanced setting DEBUG to yes or no explicitely under "Show more settings", you can pick "no" unless you know why you want "yes"...in an upcoming update, there'll likely be support for writing to a log file. The unraid template system doesn't seem to set a correct default when a multiple choice is used in the template, that's why in your log, you see "DEBUG=no|yes".

Just like @casperse said or by clicking the LOGS icon in the Unraid UI on the docker tab, but using the CLI gives a bit better formatting and none of the distracting colors...but to be honest, this is all basic "how to use unraid" stuff. I'd suggest a more appropiate thread for basic unraid usage, more people will likely answer or answer faster if it's urgent. Just to repeat myself again, whatever you did to get *arr to see your downloads, the same applies for unpackerr, except for radarr/sonarr who would get the download location from the download client, you have to provide it now with the environment variable or .conf if you'd prefer to use that. Lidarr outputs the downloads location in the API, so therefore it's not required to fill it in. In the future when radarr/sonarr also support giving this location via the API, it'll likely go away for those too. If you think you've found a bug, bug reports can be created of the app developer's github https://github.com/davidnewhall/unpackerr/issues

It's already removed from the updated template, at this moment it likely never will be used.

From the containers perspective...if your download client puts the downloads in the volume /downloads and radarr sees them in /downloads, then unpackerr needs to have the path set to /downloads and the volume should also be mounted in /downloads, whatever you did to get it working with radarr, the same applies to unpackerr. The variable ....0_PATH just tells unpacker, "go look in this folder". I also like to suggest to read whats written on your screen, the fact that you are adding a red arrow to the UN_LIDARR_0_PATH suggests you didn't read the orange text....

I can't know for sure what paths you use or prefer using...so it's a bad idea to include them in the template. I think your last solution is going to work....