Error trying to resolve Service 'Emby.Kodi.SyncQueue.API.SyncAPI' or one of its autowired dependencies (see inner exception for details)., etc

[hrmhuh 0]

 Hey! Thanks for the software. I've been playing with Emby for almost a year now as an alternative to Plex. I'm enjoying it so far, however there seem to be a few issues which I cannot find detailed related forum threads.

 

These few issues, which I will briefly break down, all have one thing in common. It seems as though Emby-Sever detects an error/fault/crash but some how can't kill the original thread when it restarts the server, leaving 1 of my 2 core system pegged at 100%.  I think this particular issue is related to many similar sounding threads I have read as it applies to all 3 of the issues I experience. Might be worth looking at?

 

 

 

Example 1) dlna/upnp.  Not a big deal as I don't use either, and disabling dlna/upnp from within the server resolves this issue for me. For whatever reason, the dlna implementation that emby is using seems to not jive with my note3, lgtv, sonos, etc. devices. I forget/do not have handy the logs/error messages but the end result is that emby will crash with a dlna related issue and restart itself. The emby service restarts, but does not seem to be able to kill the old thread and keeps a cpu pegged at 100% until the server is manually restarted a-la service emby-server restart.  Server will be fine until the dlna checks happen again.

 

Example 2) Same issue with core peg. This relates to the other threads on this forum regarding "stuck at %whatever when scanning library." This has to do with metadata that emby doesn't seem to like. When emby crashes on an entry, server log claims the sever will restart, and does, however... yet again the original thread keeps a cpu pegged. This was resolved by monitoring the logs and when the server locks up,  replace  the offending file, restart emby and  re run scan, wait for the next metadata fault, replace file.. rinse and repeat. I have done this until my complete library has been scanned and no longer get lockups/faults of this kind. Full scan takes 5-7 minutes now! \o/ Hooray!

 

 

Example 3) Once again with core peg. This one has to do with Kodi Sync Queue, and is a relatively new issue for me(Somewhere in the last few server updates).  I believe this is related to this locked forum thread, combined with the issue of emby not being able to kill its previously crashed thread.

https://emby.media/community/index.php?/topic/36093-addon-broken-with-beta-server-currently-3133/

 

When I disable the addon, all is well again. Except for the annoying-ish constant full syncs.

 

Here is the relevant excerpt of the log:

 

2016-09-24 14:47:22.5107 Error ServiceStackHost: Error occured while Processing Request: Error trying to resolve Service 'Emby.Kodi.SyncQueue.API.SyncAPI' or one of its autowired dependencies (see inner exception for details).
        *** Error Report ***
        Version: 3.0.7200.0
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 4.4.0.38
        Processor count: 2
        64-Bit OS: True
        64-Bit Process: True
        Program data path: /var/lib/emby-server
        Mono: 4.4.2 (Stable 4.4.2.11/f72fe45 Tue Aug 30 16:43:57 UTC 2016)
        Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
        Error trying to resolve Service 'Emby.Kodi.SyncQueue.API.SyncAPI' or one of its autowired dependencies (see inner exception for details).
        System.Exception
          at Funq.Container.ResolveImpl[TService] (System.String name, Boolean throwIfMissing) <0x4116d9f0 + 0x00107> in <filename unknown>:0
          at Funq.Container.ResolveNamed[TService] (System.String name) <0x4116d9a0 + 0x00033> in <filename unknown>:0
          at Funq.Container.Resolve[TService] () <0x4116d960 + 0x00027> in <filename unknown>:0
          at (wrapper dynamic-method) System.Object:lambda_method (System.Runtime.CompilerServices.Closure,Funq.Container)
          at ServiceStack.Host.ContainerResolveCache.CreateInstance (System.Type type, Boolean tryResolve) <0x4116c320 + 0x00155> in <filename unknown>:0
          at ServiceStack.Host.ContainerResolveCache.CreateInstance (System.Type type) <0x4116c2f0 + 0x00013> in <filename unknown>:0
          at ServiceStack.Host.ServiceController+<>c__DisplayClass37_0.<RegisterServiceExecutor>b__0 (IRequest req, System.Object dto) <0x4116c030 + 0x000a5> in <filename unknown>:0
          at ServiceStack.Host.ServiceController.Execute (System.Object requestDto, IRequest req) <0x4116bb40 + 0x000c9> in <filename unknown>:0
          at ServiceStack.HostContext.ExecuteService (System.Object request, IRequest httpReq) <0x4116ba90 + 0x0005b> in <filename unknown>:0
          at ServiceStack.Host.Handlers.ServiceStackHandlerBase.ExecuteService (System.Object request, IRequest httpReq) <0x4116ba60 + 0x00013> in <filename unknown>:0
          at ServiceStack.Host.RestHandler.GetResponse (IRequest request, System.Object requestDto) <0x4116b600 + 0x00077> in <filename unknown>:0
          at ServiceStack.Host.RestHandler+<ProcessRequestAsync>d__13.MoveNext () <0x411630c0 + 0x005cb> in <filename unknown>:0
        InnerException: LiteDB.LiteException
        Timeout. Database is locked for more than 00:01:00
          at LiteDB.FileDiskService.TryExec (System.Action action) <0x40f5e000 + 0x002db> in <filename unknown>:0
          at LiteDB.FileDiskService.Open (Boolean readOnly) <0x40f5dab0 + 0x0029f> in <filename unknown>:0
          at LiteDB.TransactionService.Begin (Boolean readOnly) <0x40f5d920 + 0x0007e> in <filename unknown>:0
          at LiteDB.DbEngine.WriteTransaction[T] (System.String colName, Boolean addIfNotExists, System.Func`2 action) <0x40f5d7c0 + 0x0003f> in <filename unknown>:0
          at LiteDB.DbEngine.EnsureIndex (System.String colName, System.String field, LiteDB.IndexOptions options) <0x40f5d580 + 0x001d7> in <filename unknown>:0
          at LiteDB.LiteCollection`1[T].EnsureIndex (System.String field, LiteDB.IndexOptions options) <0x40f5d420 + 0x000b7> in <filename unknown>:0
          at LiteDB.LiteCollection`1[T].EnsureIndex[K] (System.Linq.Expressions.Expression`1 property, Boolean unique) <0x40f5a1b0 + 0x000a3> in <filename unknown>:0
          at Emby.Kodi.SyncQueue.Data.DbRepo..ctor (System.String dp, ILogger logger, IJsonSerializer json) <0x40f52500 + 0x00487> in <filename unknown>:0
          at Emby.Kodi.SyncQueue.API.SyncAPI..ctor (ILogger logger, IJsonSerializer jsonSerializer, IApplicationPaths applicationPaths) <0x40f521f0 + 0x00297> in <filename unknown>:0
          at (wrapper dynamic-method) System.Object:lambda_method (System.Runtime.CompilerServices.Closure,Funq.Container)
          at Funq.Container.ResolveImpl[TService] (System.String name, Boolean throwIfMissing) <0x4116d9f0 + 0x000a4> in <filename unknown>:0
 

-----------

 

Again, whatever these independent issue are, they all seem to have a common theme. Emby server will restart, while leaving its older, faulted thread to peg a cpu.

 

Not sure if this helps, or what I'm doing wrong.. But I thought I'd throw this out there. Happens to me on ubuntu 14.04 and 16.04, fresh&clean installs.

 

 

Cheers!

 

Bye.

Edited September 24, 2016 by hrmhuh

[Luke 37115]

Hi, welcome. You might like to know the upnp/dlna discovery layer has been rewritten for the next release and has a much, much lighter impact on the server.