swyn 0 Posted December 8, 2017 Share Posted December 8, 2017 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 More sharing options...
swyn 0 Posted December 9, 2017 Author Share Posted December 9, 2017 (edited) 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 December 9, 2017 by swyn Link to comment Share on other sites More sharing options...
Luke 37118 Posted December 10, 2017 Share Posted December 10, 2017 We're looking into it, thanks. 1 Link to comment Share on other sites More sharing options...
binhex 2 Posted December 15, 2017 Share Posted December 15, 2017 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. 1 Link to comment Share on other sites More sharing options...
Luke 37118 Posted December 15, 2017 Share Posted December 15, 2017 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 More sharing options...
binhex 2 Posted December 15, 2017 Share Posted December 15, 2017 (edited) . 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 December 15, 2017 by binhex 1 Link to comment Share on other sites More sharing options...
Luke 37118 Posted December 15, 2017 Share Posted December 15, 2017 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. 1 Link to comment Share on other sites More sharing options...
tehspede 1 Posted December 16, 2017 Share Posted December 16, 2017 I was able to downgrade the dotnet-runtime from https://archive.archlinux.org/packages/d/dotnet-runtime/ and save my trakt settings 1 Link to comment Share on other sites More sharing options...
Luke 37118 Posted December 16, 2017 Share Posted December 16, 2017 Yay, great work guys. Link to comment Share on other sites More sharing options...
monkeybeans 0 Posted March 2, 2018 Share Posted March 2, 2018 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 More sharing options...
Luke 37118 Posted March 2, 2018 Share Posted March 2, 2018 Thanks for the info. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now