Plugin Update/Uninstall is failing on Windows #839

Closed
opened 2025-12-21 17:25:50 +01:00 by backuprepo · 29 comments
Owner

Originally created by @seniorm0ment on GitHub (Aug 14, 2019).

Describe the bug

'Check For Plugin Updates Failed'

To Reproduce

  1. Go to 'Scheduled Tasks'
  2. See error

Log

Access to the path 'Jellyfin.Plugin.Anime.dll' is denied.
at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel)
at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive)
at Emby.Server.Implementations.Updates.InstallationManager.PerformPackageInstallation(IProgress`1 progress, String target, PackageVersionInfo package, CancellationToken cancellationToken)
at Emby.Server.Implementations.Updates.InstallationManager.InstallPackageInternal(PackageVersionInfo package, Boolean isPlugin, IProgress`1 progress, CancellationToken cancellationToken)
at Emby.Server.Implementations.Updates.InstallationManager.InstallPackage(PackageVersionInfo package, Boolean isPlugin, IProgress`1 progress, CancellationToken cancellationToken)
at Emby.Server.Implementations.ScheduledTasks.PluginUpdateTask.Execute(CancellationToken cancellationToken, IProgress`1 progress)
at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.ExecuteInternal(TaskOptions options)

Expected behavior

Expected to properly update lol.

Screenshots

https://b.catgirlsare.sexy/tboM.png

System:

  • OS: [Windows 10]
  • Browser: [Firefox]
  • Jellyfin Version: [10.3.7]
Originally created by @seniorm0ment on GitHub (Aug 14, 2019). **Describe the bug** 'Check For Plugin Updates Failed' **To Reproduce** 1. Go to 'Scheduled Tasks' 2. See error **Log** ``` Access to the path 'Jellyfin.Plugin.Anime.dll' is denied. at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel) at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive) at Emby.Server.Implementations.Updates.InstallationManager.PerformPackageInstallation(IProgress`1 progress, String target, PackageVersionInfo package, CancellationToken cancellationToken) at Emby.Server.Implementations.Updates.InstallationManager.InstallPackageInternal(PackageVersionInfo package, Boolean isPlugin, IProgress`1 progress, CancellationToken cancellationToken) at Emby.Server.Implementations.Updates.InstallationManager.InstallPackage(PackageVersionInfo package, Boolean isPlugin, IProgress`1 progress, CancellationToken cancellationToken) at Emby.Server.Implementations.ScheduledTasks.PluginUpdateTask.Execute(CancellationToken cancellationToken, IProgress`1 progress) at Emby.Server.Implementations.ScheduledTasks.ScheduledTaskWorker.ExecuteInternal(TaskOptions options) ``` **Expected behavior** Expected to properly update lol. **Screenshots** https://b.catgirlsare.sexy/tboM.png **System:** - OS: [Windows 10] - Browser: [Firefox] - Jellyfin Version: [10.3.7]
backuprepo 2025-12-21 17:25:50 +01:00
Author
Owner

@cvium commented on GitHub (Aug 15, 2019):

Looks like a permission issue.

@cvium commented on GitHub (Aug 15, 2019): Looks like a permission issue.
Author
Owner

@seniorm0ment commented on GitHub (Aug 15, 2019):

Yeah, but it shouldn't have permission issues. I installed it under admin.
Plus I have no issues actually installing new plugins. Just seems like the plugin updater is having issues.

@seniorm0ment commented on GitHub (Aug 15, 2019): Yeah, but it shouldn't have permission issues. I installed it under admin. Plus I have no issues actually installing new plugins. Just seems like the plugin updater is having issues.
Author
Owner

@anthonylavado commented on GitHub (Aug 16, 2019):

What happens if you remove the anime plugin and install it again?

@anthonylavado commented on GitHub (Aug 16, 2019): What happens if you remove the anime plugin and install it again?
Author
Owner

@seniorm0ment commented on GitHub (Aug 16, 2019):

So, I tried with OpenSubtitles plugin first.

I uninstalled it, upon clicking uninstall it just showed a buffering icon and just sat there. I gave it a bit, then refreshed the page. It was gone. I went to catalog to reinstall it and clicked install and it just buffered again. Gave it time and eventually refreshed the page, went to check if it was installed and it didn't. I tried it a few more times no cigar.

I then tried installing another plugin (One that was never installed before), and it installed in seconds no buffer symbol.

I tried going to the catalog and installing the latest anime plugin (Clicking the latest release then clicking install), without removing the old version (I assume it would just update it) but it just buffers and buffers.

So I'm not sure what's going on.. I really don't want to do a Jellyfin reinstall though .-.

@seniorm0ment commented on GitHub (Aug 16, 2019): So, I tried with OpenSubtitles plugin first. I uninstalled it, upon clicking uninstall it just showed a buffering icon and just sat there. I gave it a bit, then refreshed the page. It was gone. I went to catalog to reinstall it and clicked install and it just buffered again. Gave it time and eventually refreshed the page, went to check if it was installed and it didn't. I tried it a few more times no cigar. I then tried installing another plugin (One that was never installed before), and it installed in seconds no buffer symbol. I tried going to the catalog and installing the latest anime plugin (Clicking the latest release then clicking install), without removing the old version (I assume it would just update it) but it just buffers and buffers. So I'm not sure what's going on.. I really don't want to do a Jellyfin reinstall though .-.
Author
Owner

@anthonylavado commented on GitHub (Aug 17, 2019):

Sounds like you’ll need to actually delete the plugins yourself from the folder they are located in. After that, you can try installing them again. You don’t have to completely reinstall Jellyfin.

@anthonylavado commented on GitHub (Aug 17, 2019): Sounds like you’ll need to actually delete the plugins yourself from the folder they are located in. After that, you can try installing them again. You don’t have to completely reinstall Jellyfin.
Author
Owner

@seniorm0ment commented on GitHub (Aug 17, 2019):

@anthonylavado This will remove all of the plugin preferences though correct? It will probabl work, I'll try later, but This shouldnt need to be done to simply update a plugin without error. Seems like something else is going on.

Edit: This did work, but reset all my preferences for the plugin so I had to go back and manually set it up. Still annoying. This shouldn't have had to be done to update it.

@seniorm0ment commented on GitHub (Aug 17, 2019): @anthonylavado This will remove all of the plugin preferences though correct? It will probabl work, I'll try later, but This shouldnt need to be done to simply update a plugin without error. Seems like something else is going on. Edit: This did work, but reset all my preferences for the plugin so I had to go back and manually set it up. Still annoying. This shouldn't have had to be done to update it.
Author
Owner

@anthonylavado commented on GitHub (Aug 18, 2019):

The preferences should have been in separate files, I had meant for you only to remove the .DLL files.

At any rate, something changed from when it was first installed to now, otherwise there wouldn’t have been a permission error. When doing an update, the program actually goes and downloads the new plugin, deletes the old one, and puts the new one in its place. The error message “Access to the path 'Jellyfin.Plugin.Anime.dll' is denied” definitely sums up what was happening. If it can’t do it, it can’t do it.

I do apologize, but it’s one of the few things that’s out of our control. The best we can do is log the error and not crash when it happens :-(

@anthonylavado commented on GitHub (Aug 18, 2019): The preferences should have been in separate files, I had meant for you only to remove the .DLL files. At any rate, something changed from when it was first installed to now, otherwise there wouldn’t have been a permission error. When doing an update, the program actually goes and downloads the new plugin, deletes the old one, and puts the new one in its place. The error message “Access to the path 'Jellyfin.Plugin.Anime.dll' is denied” definitely sums up what was happening. If it can’t do it, it can’t do it. I do apologize, but it’s one of the few things that’s out of our control. The best we can do is log the error and not crash when it happens :-(
Author
Owner

@anthonylavado commented on GitHub (Aug 18, 2019):

Reading back a little more - I’m not sure about what context Jellyfin is running in (this depends on how you installed it/started it up), but it’s entirely possible that you set it up as Admin, but it’s running as you/a different user now. Hence why it couldn’t delete what was originally set up as Admin. Just thinking out loud.

@anthonylavado commented on GitHub (Aug 18, 2019): Reading back a little more - I’m not sure about what context Jellyfin is running in (this depends on how you installed it/started it up), but it’s entirely possible that you set it up as Admin, but it’s running as you/a different user now. Hence why it couldn’t delete what was originally set up as Admin. Just thinking out loud.
Author
Owner

@seniorm0ment commented on GitHub (Aug 19, 2019):

The preferences should have been in separate files, I had meant for you only to remove the .DLL files.

Yes I saw they were in a seperate folder, I copied them in case, and then deleted them, reinstalled. Then they were still in that folder, they didn't save. I then tried replacing them with the ones I backed up, didn't work either for some reason.

It’s entirely possible that you set it up as Admin, but it’s running as you/a different user now. Hence why it couldn’t delete what was originally set up as Admin. Just thinking out loud.

Unless it changed something by itself, it was installed as Admin, and there isn't even any other accounts on this computer.

@seniorm0ment commented on GitHub (Aug 19, 2019): >The preferences should have been in separate files, I had meant for you only to remove the .DLL files. Yes I saw they were in a seperate folder, I copied them in case, and then deleted them, reinstalled. Then they were still in that folder, they didn't save. I then tried replacing them with the ones I backed up, didn't work either for some reason. >It’s entirely possible that you set it up as Admin, but it’s running as you/a different user now. Hence why it couldn’t delete what was originally set up as Admin. Just thinking out loud. Unless it changed something by itself, it was installed as Admin, and there isn't even any other accounts on this computer.
Author
Owner

@dkanada commented on GitHub (Sep 5, 2019):

What user and group is Jellyfin running as when you open htop or a similar program? What are the user, group, and file permissions for OpenSubtitles.dll and the plugin directory?

@dkanada commented on GitHub (Sep 5, 2019): What user and group is Jellyfin running as when you open htop or a similar program? What are the user, group, and file permissions for OpenSubtitles.dll and the plugin directory?
Author
Owner

@anthonylavado commented on GitHub (Sep 5, 2019):

Use Task Manager since you’re on Windows

@anthonylavado commented on GitHub (Sep 5, 2019): Use Task Manager since you’re on Windows
Author
Owner

@seniorm0ment commented on GitHub (Sep 6, 2019):

What user and group is Jellyfin running as when you open htop or a similar program? What are the user, group, and file permissions for OpenSubtitles.dll and the plugin directory?

Use Task Manager since you’re on Windows

It's running under 'SYSTEM' if that's what you're asking.
It has admin permissions, I only have one account on this computer and it's an admin account. But yeah in the group it shows admins, my account and System.

@seniorm0ment commented on GitHub (Sep 6, 2019): > What user and group is Jellyfin running as when you open htop or a similar program? What are the user, group, and file permissions for OpenSubtitles.dll and the plugin directory? > Use Task Manager since you’re on Windows It's running under 'SYSTEM' if that's what you're asking. It has admin permissions, I only have one account on this computer and it's an admin account. But yeah in the group it shows admins, my account and System.
Author
Owner

@oddstr13 commented on GitHub (Oct 4, 2019):

This issue has also been reported by another user on reddit.

Steps to reproduce

  • Install plugin
  • Restart server
  • Attempt to uninstall plugin

(credit @anthonylavado)

The result is an infinite loading screen, and an error in the logfile.

Workaround

  • Stop the Jellyfin Server service
  • Delete the offending plugin from C:\ProgramData\Jellyfin\Server\plugins\
  • Start the Jellyfin Server service again

It does not seem to be a filesystem permission issue.
The service is running as NETWORK SERVICE, and that is also the owner of C:\ProgramData\Jellyfin\ with all it's content.
Also has list and traverse permissions on C:\ and C:\ProgramData\.

[2019-10-05 00:09:57.692 +02:00] [INF] Deleting plugin directory "C:\ProgramData\Jellyfin\Server\plugins\Bookshelf"
[2019-10-05 00:09:57.805 +02:00] [ERR] Error processing request
System.UnauthorizedAccessException: Access to the path 'Jellyfin.Plugin.Bookshelf.dll' is denied.
   at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel)
   at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive)
   at Emby.Server.Implementations.Updates.InstallationManager.UninstallPlugin(IPlugin plugin)
   at MediaBrowser.Api.PluginService.Delete(UninstallPlugin request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.<>c__DisplayClass5_0.<CreateExecFn>b__0(Object service, Object request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.Execute(Type serviceType, IRequest request, Object instance, Object requestDto, String requestName)
   at Emby.Server.Implementations.Services.ServiceController.Execute(HttpListenerHost httpHost, Object requestDto, IRequest req)
   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IRequest httpReq, HttpResponse httpRes, ILogger logger, CancellationToken cancellationToken)
   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IHttpRequest httpReq, String urlString, String host, String localPath, CancellationToken cancellationToken)
@oddstr13 commented on GitHub (Oct 4, 2019): This issue has also been reported [by another user on reddit][1]. ### Steps to reproduce - Install plugin - Restart server - Attempt to uninstall plugin (credit @anthonylavado) The result is an infinite loading screen, and an error in the logfile. ### Workaround - Stop the `Jellyfin Server` service - Delete the offending plugin from `C:\ProgramData\Jellyfin\Server\plugins\` - Start the `Jellyfin Server` service again [1]: https://old.reddit.com/r/jellyfin/comments/dcw4ma/things_that_need_to_be_improved_on_fixed/f2dlslr/ ----- **It does not seem to be a filesystem permission issue.** The service is running as `NETWORK SERVICE`, and that is also the owner of `C:\ProgramData\Jellyfin\` with all it's content. Also has list and traverse permissions on `C:\` and `C:\ProgramData\`. ``` [2019-10-05 00:09:57.692 +02:00] [INF] Deleting plugin directory "C:\ProgramData\Jellyfin\Server\plugins\Bookshelf" [2019-10-05 00:09:57.805 +02:00] [ERR] Error processing request System.UnauthorizedAccessException: Access to the path 'Jellyfin.Plugin.Bookshelf.dll' is denied. at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel) at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive) at Emby.Server.Implementations.Updates.InstallationManager.UninstallPlugin(IPlugin plugin) at MediaBrowser.Api.PluginService.Delete(UninstallPlugin request) at Emby.Server.Implementations.Services.ServiceExecGeneral.<>c__DisplayClass5_0.<CreateExecFn>b__0(Object service, Object request) at Emby.Server.Implementations.Services.ServiceExecGeneral.Execute(Type serviceType, IRequest request, Object instance, Object requestDto, String requestName) at Emby.Server.Implementations.Services.ServiceController.Execute(HttpListenerHost httpHost, Object requestDto, IRequest req) at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IRequest httpReq, HttpResponse httpRes, ILogger logger, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IHttpRequest httpReq, String urlString, String host, String localPath, CancellationToken cancellationToken) ```
Author
Owner

@anthonylavado commented on GitHub (Oct 5, 2019):

So the reason the plugin file can't be deleted is because it's in use. I'll give you one guess as to what process is tying up the file...

@anthonylavado commented on GitHub (Oct 5, 2019): So the reason the plugin file can't be deleted is because it's in use. I'll give you one guess as to what process is tying up the file...
Author
Owner

@anthonylavado commented on GitHub (Oct 5, 2019):

So as far as I can tell, this has never worked in Windows. I just tested both 10.4(nightly-2019-10-04), 10.3.7, and 10.2.0 (where we first introduced plugins).

@anthonylavado commented on GitHub (Oct 5, 2019): So as far as I can tell, this has never worked in Windows. I just tested both 10.4(nightly-2019-10-04), 10.3.7, and 10.2.0 (where we first introduced plugins).
Author
Owner

@anthonylavado commented on GitHub (Oct 5, 2019):

Not sure where else to go here. @Bond-009 or @cvium, any ideas?

@anthonylavado commented on GitHub (Oct 5, 2019): Not sure where else to go here. @Bond-009 or @cvium, any ideas?
Author
Owner

@n00bhax commented on GitHub (Nov 10, 2019):

I can confirm that this problem has always been there. I have to completely delete a plugin manually to update one.

@n00bhax commented on GitHub (Nov 10, 2019): I can confirm that this problem has always been there. I have to completely delete a plugin manually to update one.
Author
Owner

@JustAMan commented on GitHub (Nov 22, 2019):

This is because how Windows itself works (it doesn't allow you to overwrite a file which is an executable or a DLL when the application using this exe/DLL still runs).

We don't have a proper fix for that yet...

@JustAMan commented on GitHub (Nov 22, 2019): This is because how Windows itself works (it doesn't allow you to overwrite a file which is an executable or a DLL when the application using this exe/DLL still runs). We don't have a proper fix for that yet...
Author
Owner

@mark-monteiro commented on GitHub (Jan 27, 2020):

Did a quick bit of research on this and loading/unloading DLLs at runtime is now supported in .NET Core 3.0. The plugin DLLs will need to be loaded via AssemblyLoadContext. Then when updating, the assembly can be unloaded again with AssemblyLoadContext.Unload.

The assembly is unloaded asynchronously whenever garbage collection completes so it might be difficult to delete the old assembly file right away. Maybe a better option would be to create a new subfolder for each plugin version and then delete the old one with a scheduled task or next server startup, etc. Alternatively, the version number could be appended to the assembly name so they can all continue to exist in the same folder.

@mark-monteiro commented on GitHub (Jan 27, 2020): Did a quick bit of research on this and loading/unloading DLLs at runtime is now supported in .NET Core 3.0. The plugin DLLs will need to be loaded via [AssemblyLoadContext](https://docs.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext?view=netcore-3.1). Then when updating, the assembly can be unloaded again with `AssemblyLoadContext.Unload`. The assembly is unloaded asynchronously whenever garbage collection completes so it might be difficult to delete the old assembly file right away. Maybe a better option would be to create a new subfolder for each plugin version and then delete the old one with a scheduled task or next server startup, etc. Alternatively, the version number could be appended to the assembly name so they can all continue to exist in the same folder.
Author
Owner

@mark-monteiro commented on GitHub (Mar 15, 2020):

FYI I took a stab at this to see if we could use AssemblyLoadContext approach, but there is a bug with the XML serialization assembly that prevents this from working that isn't going to be fixed until .NET 5: https://github.com/dotnet/runtime/issues/1388. So it looks like well have to take another approach.

My branch is here in case anyone wants to take a look: https://github.com/jellyfin/jellyfin/compare/master...mark-monteiro:test-assembly-load-context

@mark-monteiro commented on GitHub (Mar 15, 2020): FYI I took a stab at this to see if we could use `AssemblyLoadContext` approach, but there is a bug with the XML serialization assembly that prevents this from working that isn't going to be fixed until .NET 5: https://github.com/dotnet/runtime/issues/1388. So it looks like well have to take another approach. My branch is here in case anyone wants to take a look: https://github.com/jellyfin/jellyfin/compare/master...mark-monteiro:test-assembly-load-context
Author
Owner

@BaronGreenback commented on GitHub (May 8, 2020):

Don't know if this is of any use, but according to what i've read the MoveFileEx windows API call will allow dll's that are in use to be renamed.

using System.Runtime.InteropServices;
[DllImport("Kernel32.dll", CharSet = CharSet32.Unicode)]
public static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName, int dwFlags);
[CODE]
MoveFileEx(file, file + ".bak", 4); // MOVEFILE_DELAY_UNTIL_REBOOT

Haven't looked at the code in detail to see how this could be implimented (if at all)

@BaronGreenback commented on GitHub (May 8, 2020): Don't know if this is of any use, but according to what i've read the MoveFileEx windows API call will allow dll's that are in use to be renamed. ``` using System.Runtime.InteropServices; [DllImport("Kernel32.dll", CharSet = CharSet32.Unicode)] public static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName, int dwFlags); [CODE] MoveFileEx(file, file + ".bak", 4); // MOVEFILE_DELAY_UNTIL_REBOOT ``` Haven't looked at the code in detail to see how this could be implimented (if at all)
Author
Owner

@JustAMan commented on GitHub (May 13, 2020):

The problem with MoveFileEx() is we want to move the file away immediately, not upon next computer reboot, and also that flag requires administrative privileges which we cannot take for granted. Thus it doesn't seem to be a solution, alas :(

@JustAMan commented on GitHub (May 13, 2020): The problem with `MoveFileEx()` is we want to move the file away immediately, not upon next computer reboot, and also that flag requires administrative privileges which we cannot take for granted. Thus it doesn't seem to be a solution, alas :(
Author
Owner

@BaronGreenback commented on GitHub (May 13, 2020):

The admin privilege is a problem - but you can rename the file immediately with MoveFileEx() - just not delete it immediately.

"There are several applications, such as service packs and hotfixes, that must replace a file that's in use and is unable to. Windows therefore provides the MoveFileEx API to rename or delete a file and allows the caller to specify that they want the operation to take place the next time the system boots, before the files are referenced." - from sysinternals docs.

As i read that - movefileex called twice, once as a rename, then with the MOVEFILE_DELAY_UNTIL_REBOOT param - will rename the one you cannot delete - then nuke it at the next reboot.

@BaronGreenback commented on GitHub (May 13, 2020): The admin privilege is a problem - but you can rename the file immediately with MoveFileEx() - just not delete it immediately. "There are several applications, such as service packs and hotfixes, that must replace a file that's in use and is unable to. Windows therefore provides the MoveFileEx API to rename or delete a file and allows the caller to specify that they want the operation to take place the next time the system boots, before the files are referenced." - from sysinternals docs. As i read that - movefileex called twice, once as a rename, then with the MOVEFILE_DELAY_UNTIL_REBOOT param - will rename the one you cannot delete - then nuke it at the next reboot.
Author
Owner

@JustAMan commented on GitHub (May 13, 2020):

Again, we need to update the files without rebooting the server. I understand that in Windows world reboot is a universal solution, but rebooting a server just because one application in it wanted to update a plugin is still a bit of an overkill... I think we'd need to revise how we update plugins and streamline that instead.

@JustAMan commented on GitHub (May 13, 2020): Again, we need to update the files without rebooting the server. I understand that in Windows world reboot is a universal solution, but rebooting a server just because one application in it wanted to update a plugin is still a bit of an overkill... I think we'd need to revise how we update plugins and streamline that instead.
Author
Owner

@BaronGreenback commented on GitHub (Jun 21, 2020):

Design change that would solve the problem. #3401

@BaronGreenback commented on GitHub (Jun 21, 2020): Design change that would solve the problem. #3401
Author
Owner

@smidley commented on GitHub (Sep 4, 2020):

I can confirm that I've had this issue with every version of JF server. https://github.com/jellyfin/jellyfin/issues/4052

@smidley commented on GitHub (Sep 4, 2020): I can confirm that I've had this issue with every version of JF server. https://github.com/jellyfin/jellyfin/issues/4052
Author
Owner

@stale[bot] commented on GitHub (Jan 3, 2021):

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

@stale[bot] commented on GitHub (Jan 3, 2021): This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on [Matrix or Social Media](https://docs.jellyfin.org/general/getting-help.html).
Author
Owner

@mark-monteiro commented on GitHub (Jan 3, 2021):

@BaronGreenback Was this resolved with #3401?

@mark-monteiro commented on GitHub (Jan 3, 2021): @BaronGreenback Was this resolved with #3401?
Author
Owner

@BaronGreenback commented on GitHub (Jan 3, 2021):

yes

@BaronGreenback commented on GitHub (Jan 3, 2021): yes
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#839
No description provided.