Open alexbcberio opened 3 years ago
Not sure about the jellyfin side of things and how long request urls should be, but this might be fixed by increasing the size of the nginx client header buffer. The default is 8k bytes, which makes sense given that the failing request url is a bit above that. https://stackoverflow.com/questions/1067334/how-to-set-the-allowed-url-length-for-a-nginx-request-error-code-414-uri-too
Seems that nginx is not the one who is returning the error, I've increased the buffer size to 256 (large_client_header_buffers 4 256k;
), I have set it on the vhost inside the server
, and its still returning this same error.
2021/06/19 11:18:31 [error] 3271216#3271216: *60915 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.10, server: address.tld, request: "GET /web/index.html HTTP/2.0", upstream: "http://[::1]:8096/web/index.html", host: "address.tld"
I have checked if it still occurs while making a direct connection over the port 8096 and can confirm it.
I tried searching for any meaningful log by the jellyfin process but found nothing. Here are all the logs from the same date range as nginx (I think its safe to ignore the error but I post it just in case).
[2021-06-19 11:21:04.771 +02:00] [INF] WS "192.168.1.10" request
[2021-06-19 11:18:31.515 +02:00] [INF] WS "192.168.1.10" request
[2021-06-19 11:18:31.066 +02:00] [INF] WS "192.168.1.10" closed
[2021-06-19 11:17:24.061 +02:00] [INF] WS "192.168.1.10" request
at Jellyfin.Server.Middleware.ExceptionMiddleware.Invoke(HttpContext context)
at Jellyfin.Server.Middleware.ResponseTimeMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)
at Jellyfin.Server.Middleware.LegacyEmbyRouteRewriteMiddleware.Invoke(HttpContext httpContext)
at Jellyfin.Server.Middleware.RobotsRedirectionMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
at Swashbuckle.AspNetCore.ReDoc.ReDocMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)
at Jellyfin.Server.Middleware.LanFilteringMiddleware.Invoke(HttpContext httpContext, INetworkManager networkManager, IServerConfigurationManager serverConfigurationManager)
at Jellyfin.Server.Middleware.IpBasedAccessValidationMiddleware.Invoke(HttpContext httpContext, INetworkManager networkManager)
at Jellyfin.Server.Middleware.WebSocketHandlerMiddleware.Invoke(HttpContext httpContext, IWebSocketManager webSocketManager)
at Jellyfin.Server.Middleware.ServerStartupMessageMiddleware.Invoke(HttpContext httpContext, IServerApplicationHost serverApplicationHost, ILocalizationManager localizationManager)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
at lambda_method945(Closure , Object , Object[] )
at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
at Emby.Server.Implementations.AppBase.BaseConfigurationManager.<>c__DisplayClass43_0.<GetConfiguration>b__0(String k)
MediaBrowser.Common.Extensions.ResourceNotFoundException: Configuration with key cinemamode not found.
I moved the issue to the web repository since this should be fixed by not adding all id's to the url in the webclient. changes in the reverse proxy are just a workaround.
This error is there as well when launching a song from the album view : _I enter the album, all songs within are displayed _I click on a song : if there are too many songs ( 134 is ok but 236 is not for instance ) then => loading animation loops forever, nothing is loaded (414) _however if I launch the album ( play or shuffle button ) then it is ok, no matter how many songs are present
( on 10.7.7, issue experienced on http, https, local access without reverse-proxy and remote access with reverse-proxy )
( I know that above comment explains this behavior, just wanted to confirm that this bug is still present )
any update on this since it seems to be an issue if there is to much episodes in series as well
This seems to be a problem when trying to syncplay a series with too many episodes, even if they play with syncplay disabled
It is for sure it looks like either body or the url is to long / too big W dniu wt., 3.05.2022 o 20:00 tepiloxtl @.***> napisał(a):
This seems to be a problem when trying to syncplay a series with too many episodes, even if they play with syncplay disabled
— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-web/issues/2750#issuecomment-1116388838, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADTM4X2MXXUFLMLVR7RIAK3VIFSUXANCNFSM46644JIQ . You are receiving this because you commented.Message ID: @.***>
This issue still persists with version 10.8.5. any updates. Tracks play just fine when playing the hole album. But single tracks fail.
This issue still persists with version 10.8.5. any updates. Tracks play just fine when playing the hole album. But single tracks fail.
Yes, and soberly considered, the "music section" of Jellyfin is thus unfortunately useless (for me). :-/
True and especially for large audiobooks
Same problem here
Meanwhile this bug is fixed, is there a way to configure the Kestrel server started by Jellyfin in order to increase this limit ?
The configuration key seems referenced here :https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.server.kestrel.core.kestrelserverlimits.maxrequestlinesize?view=aspnetcore-3.1#Microsoft_AspNetCore_Server_Kestrel_Core_KestrelServerLimits_MaxRequestLineSize
But I don't have any idea about where we should specify this configuration...
This issue still exists "414 URI Too Long" adding to collection.
The issue still exists with too many episodes on 10.8.8.
The /Users/<id>/Items?Ids=...
API call in question for syncplay can be seen being invoked here:
https://github.com/jellyfin/jellyfin-web/blob/master/src/plugins/syncPlay/core/Helper.js#L75-L93
The problem is that the server is rejecting API requests with HTTP 414 when the URI is long. One of the ways this issue manifests itself is when a show with many episodes is being queued resulting in many ids getting appended as query parameters pushing the request over the limit.
To remediate this, it seems the ids
query parameter needs to be trimmed down to not contain more ids than can be supported.
The amount of ids would be determined from the total maximum allowable URI size minus the other required query parameters and data. I'm currently not sure what the maximum is. :thinking:
Since the API client is generated, a potential fix would be to update call sites of apiClient.getItems()
to handle trimming down the request. If many call sites should be updated it would be nice to centralize this operation.
There is a PR related to this open now. https://github.com/jellyfin/jellyfin-web/pull/4221
@thornbill any ETA on the pr being merged?
I'll be (mostly) afk for the next week but it's getting close. 🤞
Any eta on the version this is going to be added to? @thornbill
It won't be included until 10.9.0. The change is too complicated to backport to a bugfix release for 10.8 imho.
When I try to play any song the request fails under a 414 error having the "library page size" setting increased to 250 (defaults to 100).
System (please complete the following information):
To Reproduce
Expected behavior
The song should play as it does normally
Server Logs (nginx error.log)
Browser Console Logs
Screenshots
Error reported on the browser console Error displayed on network tab
Additional context
The Request URL itself (it has 8925 characters)