Stuck at "Torrent waiting for file selection"

[logtho]

It seems sometimes specific torrents will hang at "Torrent waiting for file selection."

I've tried the following settings:

• Only download available files enabled; minimum file size 100MB
• Only download available files disabled; minimum file size 100MB
• Only download available files enabled; minimum file size 0MB

I also tried restarting the RealDebridClient service but that did not seem to help.

I checked the logs and I found this which seems to be causing the above issue:

2021-02-08 13:41:10.874 +00:00 [ERR] Unexpected error occurred in TorrentDownloadManager.Tick
Newtonsoft.Json.JsonSerializationException: Cannot deserialize the current JSON array (e.g. [1,2,3]) into type 'System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[System.Collections.Generic.Dictionary`2[System.String,RDNET.TorrentInstantAvailabilityFile]]]' because the type requires a JSON object (e.g. {"name":"value"}) to deserialize correctly.
To fix this error either change the JSON to a JSON object (e.g. {"name":"value"}) or change the deserialized type to an array or a type that implements a collection interface (e.g. ICollection, IList) like List<T> that can be deserialized from a JSON array. JsonArrayAttribute can also be added to the type to force it to deserialize from a JSON array.
Path '8b3dee9818bb9c91a8505af803349f32590d5885', line 2, position 46.
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.EnsureArrayContract(JsonReader reader, Type objectType, JsonContract contract)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateList(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, Object existingValue, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateDictionary(IDictionary dictionary, JsonReader reader, JsonDictionaryContract contract, JsonProperty containerProperty, String id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
   at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
   at RDNET.RdNetClient.Get[T](String url, Boolean repeatRequest)
   at RDNET.RdNetClient.GetAvailableFiles(String id)
   at RdtClient.Service.Services.Torrents.GetAvailableFiles(String hash) in C:\Projects\rdt-client\server\RdtClient.Service\Services\Torrents.cs:line 165
   at RdtClient.Service.Services.TorrentRunner.Tick() in C:\Projects\rdt-client\server\RdtClient.Service\Services\TorrentRunner.cs:line 274
   at RdtClient.Service.Services.TaskRunner.ExecuteAsync(CancellationToken stoppingToken) in C:\Projects\rdt-client\server\RdtClient.Service\Services\TaskRunner.cs:line 36

[rogerfar]

I wonder if the API returns an empty list of even NULL when the torrent hasn't been downloaded yet. Let me find an real obscure torrent and see if I can reproduce.

[logtho]

The torrent I am trying to download definitely has been downloaded to RD. I tried putting the magnet link through the RD site manually and that works just fine.

[rogerfar]

If you try it again in RdClient does it error out again? If so can you send me the magnet through email? Should be in my profile.

[logtho]

I tried it again (put the magnet link directly into RdClient, and had the below settings enabled) and it still hangs at "Torrent waiting for file selection."

I checked the logs again and see the same error, including the same value in the Path 'xxxxxxxxx' part.

I thought the Path 'xxxxxxxxxxx', line 2, position 46 might have been the hash but I compared it to the one in Real-Debrid and it doesn't seem to be the hash. Or at least not the same hash as the torrent I'm trying to download.

I'm happy to send you the magnet link through email, however I can't seem to find it on your profile.

[rogerfar]

Can you maybe upload it in a Pastebin and send the link here? Just make sure it expires within 24 hours or so.

[logtho]

Sure! Here it is: https://pastebin.com/Q0UbAVJP

[rogerfar]

Strange, I just loaded it in myself and it works fine, it gives me a list of 10 files that are available.

[logtho]

I just left it and it eventually selected the files and started downloading. Very strange.

[logtho]

To add to the above, my internet has been very bad lately. We called our ISP and they said there is a problem in the area that they are working on fixing. So it's very possible that whatever went wrong was related to my internet. However, I'm not sure if you want to look into the issue anyway just in case, so I'll leave the thread open. Feel free to close it if you think it was just a problem on my end.

Thanks for all your work on this client; it's great!

[logtho]

Update: I seem to be getting this problem a lot more often.

I also sometimes have finished downloads that sonarr/radarr do not seem to do anything with. I check the Activity tab and it shows it's downloading with an empty progress bar. When I hover over the progress bar, it says it's at "Infinity%". I'm not sure if this might just be something weird with my sonarr/radarr configurations or if maybe RDClient isn't telling sonarr/radarr that the download is complete. Moving them manually to where sonarr/radarr are supposed to move the file(s) to works just fine.

[logtho]

Did a little investigating. I believe the issue with stuff not importing after its finished might be related to this error I see in radarr.

HTTP Error - Res: [GET] http://127.0.0.1:6500/api/v2/torrents/categories: 500.InternalServerError
An item with the same key has already been added. Key: radarr

Running the test for the qbittorrent client in sonarr says the test was successful, but running the test on radarr gives me that error. I seem to get the exact same error (including "Key: radarr") even when changing the category in radarr's settings to something else.

However, while I was playing around with this, the finished movie finally imported itself. No idea what I did to cause that, except for maybe starting another download through radarr.

---

And then regarding the "torrent waiting for file selection" issue, I decided to re-check the torrents in Real-Debrid. I checked one and this one wasn't actually downloaded to RealDebrid, so for that file at least, it does not seem to be related to my initial issue in this post.

I was going to check the rest of the files, but accidentally cleared the queue somehow. I grabbed a torrent that wasn't downloaded on Real-Debrid and tested the hash with the /torrents/instantAvailability/{hash} API and like you thought, it does indeed return an empty list if the torrent has not been downloaded to RealDebrid before.

{
    "(hash)": {
        "rd": []
    }
}

It would be nice if in the case that no files are instantly available, RDClient would start the download through RealDebrid instead - or maybe even have a toggleable option that would allow you to tell sonarr/radarr that the torrent failed so that sonarr/radarr could try a different torrent instead.

[rogerfar]

Yeah their API is a little messed up, when there are no files you get

{
    "f20c3936c1dc57bb832929f3c9537c86bf41c13a": [

    ]
}

Here the hash key returns an array.

But when there are files you get

{
    "dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c": {
        "rd": [
            {
                "2": {
                    "filename": "Big Buck Bunny.mp4",
                    "filesize": 276134947
                }
            }
        ]
    }
}

Here the hash set returns a dictionary.

I'll update the RD.NET library to handle this.

[rogerfar]

@logtho what version of Radarr are you using? I can't reproduce this behaviour in v3.

[logtho]

when there are no files you get

{
  "f20c3936c1dc57bb832929f3c9537c86bf41c13a": [

  ]
}

When I tried it, I got {"hash": {"rd": []}}. The hash returned a dictionary. So that's very bizarre.

what version of Radarr are you using? I can't reproduce this behaviour in v3.

I'm using v2. Up until last night I didn't know there was a v3 for Sonarr and updated to that - but for some reason never thought to check Radarr. I'll update Radarr now and get back to you with the results.

EDIT: Nevermind, turns out I'm already using Radarr v3. Sorry for the confusion.

[logtho]

About things not importing, I am now having the same issue with a season pack through Sonarr v3. I ran the download client test on Sonarr and now I'm getting the same error I got from Radarr, just with "Key: sonarr" instead.

HTTP Error - Res: [GET] http://127.0.0.1:6500/api/v2/torrents/categories: 500.InternalServerError
An item with the same key has already been added. Key: sonarr

I went and tested Radarr's download client but I'm still getting the error there too. Very bizarre behaviour. I have no idea what could be causing it.

EDIT: I'm running RDClient as a Windows service, if that matters. Using 1.5.1 - although I just realised you've released a 1.5.2. I'll try it out.

[logtho]

I just tried 1.5.2 (built it myself following the guide in the readme) and the "torrent waiting for file selection" problem still exists- except with a different error in the logs this time:

2021-02-10 13:57:28.665 +00:00 [ERR] Unexpected error occurred in TorrentDownloadManager.Tick
System.Exception: {
    "error": "parameter_missing",
    "error_details": "{files} is missing",
    "error_code": 1
}
   at RDNET.RdNetClient.Post(String url, KeyValuePair`2[] data, Boolean repeatRequest)
   at RDNET.RdNetClient.SelectTorrentFilesAsync(String id, String[] fileIds)
   at RdtClient.Service.Services.Torrents.SelectFiles(String torrentId, IList`1 fileIds) in F:\rdt-client\rdt-client-1.5.2\server\RdtClient.Service\Services\Torrents.cs:line 170
   at RdtClient.Service.Services.TorrentRunner.Tick() in F:\rdt-client\rdt-client-1.5.2\server\RdtClient.Service\Services\TorrentRunner.cs:line 286
   at RdtClient.Service.Services.TaskRunner.ExecuteAsync(CancellationToken stoppingToken) in F:\rdt-client\rdt-client-1.5.2\server\RdtClient.Service\Services\TaskRunner.cs:line 36

I noticed it says F:\rdt-client-1.5.2\. I built it on my PC in that directory and transferred it to the device I'm using to run RDClient, Radarr/Sonarr, etc. This device does not have an F:\ drive, so I guess that's what's causing the problem. However, I did the same with 1.4 and didn't have this issue. I'll move the files to the same directory I would have them on my other device and build them there and see what happens.

[rogerfar]

I pushed 1.5.3 that will fix the issue when no files are available for selection.

For the An item with the same key has already been added. Key: sonarr error, are there more entries around it in the log? Like a stacktrace?

[logtho]

Thanks for the fix!

For the An item with the same key has already been added. Key: sonarr error, are there more entries around it in the log? Like a stacktrace?

I'm not sure. I'm trying to reproduce the error by testing the download client in both Radarr and Sonarr but both the tests are working properly all of a sudden. I'll keep playing around with it and let you know if the error happens again or if I figure anything out.

[logtho]

I just got a failed test in Radarr, and found this (error from Radarr events page):

NzbDrone.Core.Download.Clients.DownloadClientException: Failed to connect to qBittorrent, check your settings.
 ---> NzbDrone.Common.Http.HttpException: HTTP request failed: [500:InternalServerError] [GET] at [http://127.0.0.1:6500/api/v2/torrents/categories]
   at NzbDrone.Common.Http.HttpClient.Execute(HttpRequest request) in D:\a\1\s\src\NzbDrone.Common\Http\HttpClient.cs:line 96
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxyV2.ProcessRequest(HttpRequestBuilder requestBuilder, QBittorrentSettings settings) in D:\a\1\s\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxyV2.cs:line 331
An item with the same key has already been added. Key: sonarr
   --- End of inner exception stack trace ---
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxyV2.ProcessRequest(HttpRequestBuilder requestBuilder, QBittorrentSettings settings) in D:\a\1\s\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxyV2.cs:line 331
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrentProxyV2.GetLabels(QBittorrentSettings settings) in D:\a\1\s\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrentProxyV2.cs:line 205
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrent.TestCategory() in D:\a\1\s\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrent.cs:line 408
   at NzbDrone.Core.Download.Clients.QBittorrent.QBittorrent.Test(List`1 failures) in D:\a\1\s\src\NzbDrone.Core\Download\Clients\QBittorrent\QBittorrent.cs:line 311
   at NzbDrone.Core.Download.DownloadClientBase`1.Test() in D:\a\1\s\src\NzbDrone.Core\Download\DownloadClientBase.cs:line 129

Along with this:

HTTP Error - Res: [GET] http://127.0.0.1:6500/api/v2/torrents/categories: 500.InternalServerError
An item with the same key has already been added. Key: sonarr

As you can see, it says the key is sonarr, even though this is a test for the download client from Radarr. I double checked and the category definitely says Radarr. So this is very weird.

EDIT: I changed nothing and tried the test again - and now it passes just fine. Very odd.

[logtho]

The above error was an error from Radarr. I'm looking through the RDClient logs and I found this, which will probably be a lot more useful to you:

2021-02-10 21:36:22.235 +00:00 [INF] Executed action RdtClient.Web.Controllers.QBittorrentController.TorrentsCategories (RdtClient.Web) in 21.0814ms
2021-02-10 21:36:22.235 +00:00 [INF] Executed endpoint 'RdtClient.Web.Controllers.QBittorrentController.TorrentsCategories (RdtClient.Web)'
2021-02-10 21:36:22.236 +00:00 [ERR] An unhandled exception has occurred while executing the request.
System.ArgumentException: An item with the same key has already been added. Key: sonarr
   at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector, IEqualityComparer`1 comparer)
   at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable`1 source, Func`2 keySelector, Func`2 elementSelector)
   at RdtClient.Service.Services.QBittorrent.TorrentsCategories() in C:\Projects\rdt-client\server\RdtClient.Service\Services\QBittorrent.cs:line 454
   at RdtClient.Web.Controllers.QBittorrentController.TorrentsCategories() in C:\Projects\rdt-client\server\RdtClient.Web\Controllers\QBittorrentController.cs:line 309
   at lambda_method453(Closure , Object )
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.AwaitableObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Awaited|12_0(ControllerActionInvoker invoker, ValueTask`1 actionResultValueTask)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at RdtClient.Web.Startup.<>c__DisplayClass5_0.<<Configure>b__0>d.MoveNext() in C:\Projects\rdt-client\server\RdtClient.Web\Startup.cs:line 113
--- End of stack trace from previous location ---
   at RdtClient.Service.Middleware.AuthorizeMiddleware.Invoke(HttpContext context) in C:\Projects\rdt-client\server\RdtClient.Service\Middleware\AuthorizeMiddleware.cs:line 30
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
2021-02-10 21:36:22.249 +00:00 [INF] Request finished HTTP/1.1 GET http://127.0.0.1:6500/api/v2/torrents/categories - - - 500 - application/json 90.1851ms

I got this error from testing the download client in Sonarr. I had a movie import correctly in Radarr but I have a few episodes that have finished in RDClient but Sonarr isn't importing them and I can only assume it must be related to this error.

[Oorweeg]

I'm seeing this 'stuck at file selection' today as well on two downloads for at least the last 5 hours.

[05:24:17 ERR] Unexpected error occurred in TorrentDownloadManager.Tick
Newtonsoft.Json.JsonSerializationException: Cannot deserialize the current JSON array (e.g. [1,2,3]) into type 'System.Collections.Generic.Dictionary`2[System.String,System.Collections.Generic.List`1[System.Collections.Generic.Dictionary`2[System.String,RDNET.TorrentInstantAvailabilityFile]]]' because the type requires a JSON object (e.g. {"name":"value"}) to deserialize correctly.
To fix this error either change the JSON to a JSON object (e.g. {"name":"value"}) or change the deserialized type to an array or a type that implements a collection interface (e.g. ICollection, IList) like List<T> that can be deserialized from a JSON array. JsonArrayAttribute can also be added to the type to force it to deserialize from a JSON array.

Checking the RD website directly shows this same state.

[Oorweeg]

Nevermind, looks like 1.5.3 fixed it. :) Both stuck downloads are now moving again with this update.

[Oorweeg]

@rogerfar New problem, these downloaded but then couldn't extract. rdt-client is looking for paths containing %20 but the filename is normal whitespace. I'm guessing this is a result of the recent change regarding whitespace handling?

[logtho]

I'm having an issue where one thing in the queue says that it's finished, others are finished but say "queued for unpacking" (including torrents that don't need unpacking - for example are a single .mkv file). The others say either "downloading," "queued for downloading," "torrent finished, waiting to download," or "torrent waiting for file selection," which I believe is normal behaviour.

I did have this issue before and it seemed to solve itself as soon as everything in the queue had finished downloading. I assume this isn't intentional behaviour? Surely torrents that are finished should be imported via Sonarr as soon as they're finished? And there doesn't seem to be anything unpacking - just things that are queued for unpacking. I'm wondering if it's waiting for the finished torrent to be imported before it starts unpacking the next ones?

I checked the logs and see no errors.

I have maximum parallel downloads set to 3 and maximum unpack processes set to 2 if that is relevant.

EDIT: I tried seeing what would happen if I manually removed that finished download from the RDClient. Sonarr removed it from the activity queue and in the series it was marked as "missing from disk." I manually moved it over from the RDClient downloads folder to where Sonarr would've imported it and then used Sonarr's manual import and that seemed to work fine. The rest are still just stuck at "queued for unpacking."

EDIT: I tried changing maximum unpack process from 2 to 1, no difference. Then tried changing it from 1 to 30 and still no difference. Strange.

EDIT: I stopped the RealDebridClient service and took a look in rdtclient.db - the Downloads table to be specific. It seems like not a single row has the UnpackingStarted column set to anything but NULL. So it looks like something is preventing the unpacking from starting at all.

EDIT: I tried the same as I tried before when I removed the finished download from RDClient, except removed one of the "queued for unpacking" torrents and the exact same thing happened. It got removed from the activity page of Sonarr, and missing from disk on the series page. Manual importing worked just fine.

[logtho]

I tried looking through the code but I'm obviously not knowledgeable enough in C# or the RDClient codebase to understand why this might happen.

For now I've decided to remove all of the "queued for unpacking" torrents from RDClient and move and import them to Sonarr manually.

[rogerfar]

This might be because of the issue @timcoop3r reported above. I'll fix that and push an update, see if that fixes unpacking.

[logtho]

I'll fix that and push an update, see if that fixes unpacking.

Unfortunately it didn't fix my issue. I updated and kept the same database but that didn't work. So I tried deleting the database and starting from scratch but downloads are still getting stuck at "queued for unpacking." I took a look in the logs and again there are no errors. Strange.

[logtho]

I did have this issue before and it seemed to solve itself as soon as everything in the queue had finished downloading. I assume this isn't intentional behaviour?

Like I thought, I let everything finish downloading. I had 2 movies downloading and a season pack. The two movies downloaded first and stayed at "queued for unpacking." Once the season pack finished downloading, they all changed to "finished." The movies imported through Radarr like they should, and then the season pack imported afterwards through Sonarr. Once everything had finished importing, the season pack removed itself from the RDClient but the two movies still show up there - marked as "finished."

Hopefully this can give some more info for you to be able to look into things. I know an error message would probably be most useful but unfortunately there doesn't seem to be any.

EDIT: The two movies have been removed from the /downloads/radarr folder but hasn't been removed from RDClient. Not sure if this is useful info or not, but thought I should mention it just in case.

[Oorweeg]

fwiw, I have this behaviour as well. If an activity is in progress then other activities, such as unpacking or torrent file selection, wait until the other activities have finished. A download and an unpack will not happen at the same time. This isn't a huge problem for me though as these things happen generally in the background unattended. I could see why this could be a problem if you want a completed download to unpack while another download takes place though.

I have no issues with rdt-client not being cleaned up by sonarr/radarr/lidarr though. Once a download is finished and imported sonarr/radarr/lidarr will remove it, depending on those config settings. It sounds like you might not have radarr set to 'remove imported downloads from download client history', but in sonarr this setting is enabled? This is a hidden advanced setting and is disabled by default iirc? I don't think this is related to the problem of unpacking/downloading states waiting for each other?

[logtho]

It sounds like you might not have radarr set to 'remove imported downloads from download client history', but in sonarr this setting is enabled?

You were right with this; thanks!

If an activity is in progress then other activities, such as unpacking or torrent file selection, wait until the other activities have finished. A download and an unpack will not happen at the same time. This isn't a huge problem for me though as these things happen generally in the background unattended. I could see why this could be a problem if you want a completed download to unpack while another download takes place though.

I see how this wouldn't be a problem in most cases. But if you have a lot of downloads going at once, it can get a little annoying. Like I tried downloading the entirety of The Simpsons and you can imagine how that went lol. Technically still not a huge issue - unless you have limited storage on the drive that you're downloading to.

[Oorweeg]

I see how this wouldn't be a problem in most cases. But if you have a lot of downloads going at once, it can get a little annoying. Like I tried downloading the entirety of The Simpsons and you can imagine how that went lol. Technically still not a huge issue - unless you have limited storage on the drive that you're downloading to.

Yeah I suppose actually if you download two things, and you want to watch the first one, you have to wait for the next download to finish before the first one unpacks. If you are sat there waiting for it that could be annoying.

I've not tried playing with increasing the unpack/download processes, I have both mine set to 1, I'm not sure if the behaviour is different with different unpack process settings?

[logtho]

Yeah I suppose actually if you download two things, and you want to watch the first one, you have to wait for the next download to finish before the first one unpacks. If you are sat there waiting for it that could be annoying.

Yeah, exactly.

I've not tried playing with increasing the unpack/download processes, I have both mine set to 1, I'm not sure if the behaviour is different with different unpack process settings?

Mine is currently set to 4 download processes and 2 unpacking processes so I doubt this is what's causing the problem. I even tried it at 30 unpacking processes and it made no difference. lol

[logtho]

Things have suddenly decided to import while other things are still downloading. I never changed any settings or anything. Very strange.

[rogerfar]

Are we talking about downloads or separate torrents? If 1 torrent contains 8 separate episodes for example then it won't report completed until all 8 of those files are downloaded.

If you're saying you have 3 separate torrents and you have to wait for all 3 to complete before them marking as completed, that's no good.

[logtho]

Separate torrents is what I'm talking about.

[Oorweeg]

Yeah, this is happening with separate torrents, rather than multiple files in the same one.

[rogerfar]

I added a bunch of logging in the torrent runner state machine so you can see where it's hanging.

While I was going through that I found 2 places where it was jumping out instead of continuing, so I'm assuming that was the issue.

That also solves the problem of the GUI not auto updating while it's doing a bunch of stuff.

[rogerfar]

1.5.5 should resolve this issue now!

[logtho]

1.5.5 did fix that problem, thanks!

For a little while after I updated, when things were importing to Radarr/Sonnar, it would tell me it couldn't find the file on disk but had already been imported correctly. Although I suspect this is much more likely to be a Radarr/Sonarr issue, and it seems to have fixed itself now.

Besides that, everything has been working mostly perfectly for me. The only other thing I've noticed is that when I had "only download available files" enabled and "minimum file size to download" set to 0MBs, it was still downloading a sample file alongside the actual movie, even though Real-Debrid didn't have this downloaded. So it would start downloading the entire torrent again through Real-Debrid.

Changing "minimum file size to download" to 100MBs while still having "only download available files" checked seems to be working fine so far.

[logtho]

when I had "only download available files" enabled and "minimum file size to download" set to 0MBs, it was still downloading a sample file alongside the actual movie, even though Real-Debrid didn't have this downloaded. So it would start downloading the entire torrent again through Real-Debrid. Changing "minimum file size to download" to 100MBs while still having "only download available files" checked seems to be working fine so far.

I'm not sure how I got this information so wrong. But it turns out what actually happened is a little weirder.

With "only download available files" enabled and "minimum file size to download" set to 0, it was redownloading the entire torrent to RD. But it was because the sample file was downloaded to RD, and RDClient was excluding the sample file (even though minimum file size was set to 0).

The other thing I got wrong was saying I'd set the minimum file size to 100MBs - turns out I actually set it to 10MBs.

So with only downloading instantly available files and minimum file size set to 0, it was excluding the sample file, causing RD to need to redownload the entire torrent. But with downloading instantly available files and minimum file size set to 10MBs, it did download the 90MB sample file it needed to.

[rogerfar]

It shouldn't do that. If you have both settings enabled it created a list of files which are available in RD, THEN it will apply the minfilesize filter.

So if there is a file that is 150MB but not available on RD then it should not download that file.

[logtho]

I don't seem to have this issue anymore, so I'll close this.