Jump to content

Can not save plugin configuration changes


swyn

Recommended Posts

I have been having issues saving configuration changes to any plugins for Emby (Auto Box Sets, Cover Art, Emby for Kodi, Backup & Restore, and trakt).  In the GUI, the circle will spin forever.  If I go back, and back into the plugin, it looks like the change was saved, however, they are gone on the next server restart.  I have re-installed Emby fresh several times, cleaning out the Emby folder.  I thought it may be a file permissions problem at first, but on start, Emby will make the proper directory structure and files without issue.  I am using Arch Linux and this is occurring with both 3.2.40 and 3.2.50.  This seems to only be affecting plugin configuration.  Main Emby configuration changes works fine.

 

Here are permissions for the directory structure that Emby is creating and they look ok:

 

[swyn@@NET emby]$ ls -l
total 8
drwxr-xr-x 5 emby emby   92 Dec  8 10:33 cache
drwxr-xr-x 4 emby emby   63 Dec  8 10:33 config
drwxr-xr-x 7 emby emby 4096 Dec  8 10:37 data
drwxr-xr-x 2 emby emby 4096 Dec  8 10:33 localization
drwxr-xr-x 2 emby emby   66 Dec  8 10:37 logs
drwxr-xr-x 3 emby emby  139 Dec  8 10:37 plugins
drwxr-xr-x 3 emby emby   21 Dec  8 10:33 root
drwxr-xr-x 2 emby emby   79 Dec  5 12:57 ssl
 
I'm seeing the following error for the various plugins when I attempt to change the settings.  I have attached the full server log.

 

2017-12-08 10:42:52.444 Error HttpServer: Error processing request
*** Error Report ***
Version: 3.2.50.0
Command line: /usr/lib/emby-server/EmbyServer.dll -programdata /var/lib/emby -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe
Operating system: Unix 4.14.3.1
64-Bit OS: True
64-Bit Process: True
User Interactive: True
Processor count: 3
Program data path: /var/lib/emby
Application directory: /usr/lib/emby-server
System.ArgumentException: The path is not of a legal form.
Parameter name: path
   at System.IO.Path.GetDirectoryName(String path)
   at System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly(Type type, String defaultNamespace, XmlSerializerImplementation& contract)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.GetSerializer(Type type)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToWriter(Object obj, XmlWriter writer)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToStream(Object obj, Stream stream)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToFile(Object obj, String file)
   at MediaBrowser.Common.Plugins.BasePlugin`1.SaveConfiguration()
   at AutoBoxSets.Plugin.UpdateConfiguration(BasePluginConfiguration configuration)
   at MediaBrowser.Api.PluginService.Post(UpdatePluginConfiguration request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.<>c__DisplayClass4_0.<CreateExecFn>b__0(Object service, Object request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.<Execute>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Emby.Server.Implementations.Services.ServiceHandler.<ProcessRequestAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Emby.Server.Implementations.HttpServer.HttpListenerHost.<RequestHandler>d__72.MoveNext()
System.ArgumentException
   at System.IO.Path.GetDirectoryName(String path)
   at System.Xml.Serialization.TempAssembly.LoadGeneratedAssembly(Type type, String defaultNamespace, XmlSerializerImplementation& contract)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, String defaultNamespace)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.GetSerializer(Type type)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToWriter(Object obj, XmlWriter writer)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToStream(Object obj, Stream stream)
   at Emby.Server.Implementations.Serialization.MyXmlSerializer.SerializeToFile(Object obj, String file)
   at MediaBrowser.Common.Plugins.BasePlugin`1.SaveConfiguration()
   at AutoBoxSets.Plugin.UpdateConfiguration(BasePluginConfiguration configuration)
   at MediaBrowser.Api.PluginService.Post(UpdatePluginConfiguration request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.<>c__DisplayClass4_0.<CreateExecFn>b__0(Object service, Object request)
   at Emby.Server.Implementations.Services.ServiceExecGeneral.<Execute>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Emby.Server.Implementations.Services.ServiceHandler.<ProcessRequestAsync>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Emby.Server.Implementations.HttpServer.HttpListenerHost.<RequestHandler>d__72.MoveNext()
 

emby_logs.txt

Link to comment
Share on other sites

I did another fresh install for testing.  I attempted to change the configuration of the plugins with the same result.  I took a peek at the plugin configuration folder and when I tried to configure a newly installed plugin (I'm testing with backup, kodi, and autoboxsets), it creates an empty xml file.  It seems odd that it can create the xml file, but not put any data into it.

 

[swyn@@NET configurations]$ pwd
/emby/plugins/configurations
[swyn@@NET configurations]$ ls -l
total 0
-rw-r--r-- 1 emby emby 0 Dec  9 09:41 AutoBoxSets.xml
-rw-r--r-- 1 emby emby 0 Dec  9 09:41 Emby.Kodi.SyncQueue.xml
-rw-r--r-- 1 emby emby 0 Dec  9 09:42 MBBackup.xml
[swyn@@NET configurations]$ 
 
For the heck of it, I tried changing the permissions to 777 but with no change in the behavior.
 
Fresh log from the new install attached.  Same errors as above.

emby_log.txt

Edited by swyn
Link to comment
Share on other sites

We're looking into it, thanks.

 

Hate to push you on this, but any update?, ive got the exact same problem running on the same linux distro.

  • Like 1
Link to comment
Share on other sites

We have traced it to a defect in newer versions of the .net core runtime. This only happens on arch linux because we don't embed the runtime and therefore use whatever version happens to be on your system. That is the arch linux way. on other distros we embed the runtime and we're able to choose the version that we want. So by using arch linux you said you wanted latest and greatest of everything, even if unstable, and that is what you're getting. If you need immediate resolution then you'll need to use another distro.

Link to comment
Share on other sites

 

 

. So by using arch linux you said you wanted latest and greatest of everything, even if unstable

i don't agree, whilst arch linux DOES indeed pull down the latest and greatest, the state of the software is "stable", or at least its marked as a official github "release" by the developer, so i think its a bit unfair to say arch linux utilities unstable software, ive been using arch linux as my base OS for a number of years (including Emby since ver 3.2.22.0) and this is the first issue ive run into.

 

That aside, can i ask what version of dotnet runtime you bundle with other distro's, as i do have control over the package version i use (docker image), so at least i can get this going again

Edited by binhex
  • Like 1
Link to comment
Share on other sites

2.0.0 is what we're shipping. And yes newer builds are marked stable, but with the pace the entire industry is moving at right now it's not always a safe assumption that latest is going to just work. That's why I prefer the ability to control the version.

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
monkeybeans

Thanks for the help, downgrading dotnet worked for me too.

 

All versions after dotnet-runtime-2.0.0-2-x86_64.pkg.tar.xz (07-Nov-2017 20:23) were broken.

 

The precise command I used to downgrade was :

sudo pacman -U https://archive.archlinux.org/packages/d/dotnet-runtime/dotnet-runtime-2.0.0-2-x86_64.pkg.tar.xz

Best,

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...