mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
Plugin Update/Uninstall is failing on Windows #839
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#839
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @seniorm0ment on GitHub (Aug 14, 2019).
Describe the bug
'Check For Plugin Updates Failed'
To Reproduce
Log
Expected behavior
Expected to properly update lol.
Screenshots
https://b.catgirlsare.sexy/tboM.png
System:
@cvium commented on GitHub (Aug 15, 2019):
Looks like a permission issue.
@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.
@anthonylavado commented on GitHub (Aug 16, 2019):
What happens if you remove the anime plugin and install it again?
@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 .-.
@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.
@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.
@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):
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.
@seniorm0ment commented on GitHub (Aug 19, 2019):
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.
Unless it changed something by itself, it was installed as Admin, and there isn't even any other accounts on this computer.
@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?
@anthonylavado commented on GitHub (Sep 5, 2019):
Use Task Manager since you’re on Windows
@seniorm0ment commented on GitHub (Sep 6, 2019):
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.
@oddstr13 commented on GitHub (Oct 4, 2019):
This issue has also been reported by another user on reddit.
Steps to reproduce
(credit @anthonylavado)
The result is an infinite loading screen, and an error in the logfile.
Workaround
Jellyfin ServerserviceC:\ProgramData\Jellyfin\Server\plugins\Jellyfin Serverservice againIt does not seem to be a filesystem permission issue.
The service is running as
NETWORK SERVICE, and that is also the owner ofC:\ProgramData\Jellyfin\with all it's content.Also has list and traverse permissions on
C:\andC:\ProgramData\.@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 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):
Not sure where else to go here. @Bond-009 or @cvium, any ideas?
@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.
@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...
@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 (Mar 15, 2020):
FYI I took a stab at this to see if we could use
AssemblyLoadContextapproach, 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
@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.
Haven't looked at the code in detail to see how this could be implimented (if at all)
@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 :(@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.
@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.
@BaronGreenback commented on GitHub (Jun 21, 2020):
Design change that would solve the problem. #3401
@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
@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.
@mark-monteiro commented on GitHub (Jan 3, 2021):
@BaronGreenback Was this resolved with #3401?
@BaronGreenback commented on GitHub (Jan 3, 2021):
yes