Multiple Root Folders - Import behaviour if one is temporarily offline

Sonarr version (exact version): 4.0.1.929
Mono version (if Sonarr is not running on Windows): 6.0.13
OS: Debian 12
Debug logs:
Description of issue:

Hi,
i have two root folders mounted via nfs in an debian lxc system.
One for kids media which is online 24/7.
One for all other media which is only online in the evening hours.
My problem/question is:
as long as the root folder for all other content is offline no import starts.
even if the media is for the 24/7 kids root folder. the media stays in status
“waiting for import” even if it is for the online 24/7 root folder.
as soon as the offline root folder comes online the import starts and moves
the files to the correct root folder.
is this a wanted behaviour?
is there a possibility to get some logic so that media which can be imported
will be imported and all others will start when the “missing/offline” root folder(s)
comes online?

thanks!
greetings
hans

Unless something is causing the import to get hung it should just skip to the next item, trace logs of the issue would be helpful to see what’s going on.

Also check System: Tasks for which tasks are currently executing.

Hi, thanks for reply

i just did a test again

two files
one file (lets say fileon) with import destination online root folder
one file (lets say fileoff) with import destination offline root folder

both files get loaded by download client
fileon finishes and sonarr gehts the info from downloadclient
fileon stays in status “waiting for import”
fileoff finishes and sonarr should get the info from downloadclient but
activity queue doesnt refresh looks like it is hanging
fileoff stays in status downloading
restart of sonarr through webinterface
both files now showing “waiting for import”
but no import happens even not for the fileon where the root folder is available

after the restart of sonarr i got following errors in the debug log

2024-01-26 08:54:48.3|Error|EventAggregator|TaskManager failed while processing [CommandExecutedEvent]

[v4.0.1.929] System.NullReferenceException: Object reference not set to an instance of an object.
  at NzbDrone.Core.Jobs.TaskManager.Handle(CommandExecutedEvent message) in ./Sonarr.Core/Jobs/TaskManager.cs:line 217
  at NzbDrone.Core.Messaging.Events.EventAggregator.PublishEvent[TEvent](TEvent event)
2024-01-26 08:54:54.6|Error|Microsoft.AspNetCore.Server.Kestrel|Connection id "0HN0U8G8OOV4H", Request id "0HN0U8G8OOV4H:00000002": An unhandled exception was thrown by the application.

[v4.0.1.929] System.InvalidOperationException: Response Content-Length mismatch: too many bytes written (281773 of 278078).
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.VerifyAndUpdateWrite(Int32 count)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.WritePipeAsync(ReadOnlyMemory`1 data, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponseStream.WriteAsync(ReadOnlyMemory`1 source, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionBody.WriteAsync(ReadOnlyMemory`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Http.StreamCopyOperationInternal.CopyToAsync(Stream source, Stream destination, Nullable`1 count, Int32 bufferSize, CancellationToken cancel)
   at Microsoft.AspNetCore.Internal.FileResultHelper.WriteFileAsync(HttpContext context, Stream fileStream, RangeItemHeaderValue range, Int64 rangeLength)
   at Microsoft.AspNetCore.Mvc.Infrastructure.FileResultExecutorBase.WriteFileAsync(HttpContext context, Stream fileStream, RangeItemHeaderValue range, Int64 rangeLength)
   at Microsoft.AspNetCore.Mvc.Infrastructure.FileStreamResultExecutor.ExecuteAsync(ActionContext context, FileStreamResult result)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResultFilterAsync>g__Awaited|30_0[TFilter,TFilterAsync](ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNext[TFilter,TFilterAsync](State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeResultFilters>g__Awaited|28_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Sonarr.Http.Middleware.BufferingMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/BufferingMiddleware.cs:line 27
   at Sonarr.Http.Middleware.IfModifiedMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/IfModifiedMiddleware.cs:line 40
   at Sonarr.Http.Middleware.CacheHeaderMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/CacheHeaderMiddleware.cs:line 32
   at Sonarr.Http.Middleware.StartingUpMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/StartingUpMiddleware.cs:line 37
   at Sonarr.Http.Middleware.UrlBaseMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/UrlBaseMiddleware.cs:line 26
   at Sonarr.Http.Middleware.VersionMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/VersionMiddleware.cs:line 28
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.InvokeCore(HttpContext context)
   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 Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.HandleException(HttpContext context, ExceptionDispatchInfo edi)
   at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
   at Sonarr.Http.Middleware.LoggingMiddleware.InvokeAsync(HttpContext context) in ./Sonarr.Http/Middleware/LoggingMiddleware.cs:line 33
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

and if the offline root folder gets available again the import of the files starts correctly.

my personal opinion is that something breaks the import workflow because of the offline root folder.

Can you post the full trace log somewhere and link it here? The errors alone aren’t enough to see what’s actually happening.

hi, is there a way to provide you the logs more private? don’t want to publish my internal logs somewhere public (sysadmin’s paranoia) :upside_down_face:

Logs are cleansed by sonarr, there’s nothing in there besides maybe some directory names…

@markus101 is there a way to send you the log file directly? pm or euqal?
and even if thirrian means theres nothing “useful” (which i don’t see so) in the logs
i don’t want to discuss the “whats in the logs or not” i just want to provide info to the devs but not in a public way :wink:

Sonarr cleanses secrets and user information, if you’re concerned with might be in them it’d be worth reviewing the contents before posting them, but we don’t do support or receive logs through DMs.

@markus101
heres the debug log
https://www.swisstransfer.com/d/42de265b-aa23-4d95-9c2d-a5bb03fafb63
only one time downloadable and 7 days valid.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.