allanp81

Doing some more testing, and it seems that while copying to a non-cache enable share still slows down significantly, it doesn't seem to cripple the server like copying to a cache enabled share does. It still suffers exactly the same speed drop from ~110Mb/sec to anywhere between 10 and 50 meg/sec, it fluctuates constantly.

OK, see attached. downloadbox-diagnostics-20200120-2205.zip

For some reason, since upgrading to 6.8.x it seems that my server becomes somewhat unresponsive if I copy large files (10Gb+) across my network to it. I have tried copying to a share that has cache enabled and also to a share with no cache enabled. I see the same symptoms whereby for about the first 20-30 seconds it copies at ~110Mb/sec, maxing out a gigabit connection but then starts to drop massively, sometimes down to single digit Mb/sec. While this is happening it becomes almost completely unresponsive at times. Dockers become inaccessible, or just take a very long time to respond. I know I need to attach my syslog, but there are literally zero errors stated in it.

I kinda guessed that, but I couldn't figure out the docker run command as it fails when I try.

I mean even just getting the docker installed.

Did you get this working? I'm really struggling.

Does your kodi headless have access to that nfs path? And you've added the sources.xml etc?

Can't say I've noticed any issues like that personally.

Yes, via the command line: Update: curl --data-binary '{ "jsonrpc": "2.0", "method": "VideoLibrary.Scan", "id": "mybash"}' -H 'content-type: application/json;' http://username:[email protected]:8081/jsonrpc Clean: curl --data-binary '{ "jsonrpc": "2.0", "method": "VideoLibrary.Clean", "id": "mybash"}' -H 'content-type: application/json;' http://username:[email protected]:8081/jsonrpc

The main reason I use it is because things like Sonarr and Radarr can instruct a kodi client to update the DB when things are downloaded. This means your kodi headless docker can do this so that when you turn on your clients they will already be updated.

Fixed it for me as well after editing the DockerClient.php file.

Mine are configured as file:///picons/%C.png

I think I configured my client first and then copied over advancedsettings.xml and sources.xml to the headless docker. When you say nothing happens, what do you mean?

@SquidThanks for the info, I've set up a scheduled task to balance the btrfs filesystem on the cache drive once a week. Strange I've never even heard of having to do this.

Hmm, I wonder if it's related to my cache pool running out of space that I corrected much earlier that day. My cache pool at the moment has well over 100Gb of free space on it. I'll have a look at the external drive, it's probably failing as it was a cheap piece of kit that's not exactly new! Thanks

Thanks, sorry forgot to post the whole thing. downloadbox-diagnostics-20190701-1246.zip

I seem to be having out of memory issues that I've never had before. Everything appears to be working ok, first time I had the out of memory error it seemed to kill my VM that I had running. downloadbox-syslog-20190701-0831.zip

So strangely this now seems to be working... No idea why as I tried starting afresh and same issue so reverted back to my previous advancedsettings.xml and sources.xml and now it's seemingly working!

Nothing to see here...

I've tried trashing my appdata entirely and same issue. Either sonarr/lidarr/radarr are sending something weird (which can't be the case as my other clients all respond to a test) or the headless docker has an issue somewhere.

Unfortunately nothing in that link seems relevant to my issue. The webserver on my headless docker is working and shows new items that other full clients have added.

OK, enabled debug logging and I get this when sending a test from sonarr/radarr/lidarr etc: 2019-05-25 16:15:11.607 T:22479361640192 DEBUG: CWebServer[8080]: request received for /jsonrpc 2019-05-25 16:15:11.621 T:22479361640192 DEBUG: Previous line repeats 1 times. 2019-05-25 16:15:11.621 T:22479361640192 DEBUG: JSONRPC: Value does not match any of the enum values in type

Yep, they both claim they were able to successfully talk to it, if I change a port etc. then they say they've failed. Worked fine with the krypton tag. Unfortunately I can't find many logs on the docker etc. to see where it's failing. There may be a way to enable verbose logging on the docker to get more of a clue.

Nevermind, opening on a mobile shows the page differently. I have added the leia tag to the run command already and I know it's working as the headless web interface shows updates that I've added via other clients.

Oh, the link just seems to take me to the root of the github page