sparklyballs

Any luck with moving to 10.1? I upgraded Kodi to Jarvis (16.0) and it keeps crushing. I checked Kodi forums and it says that MariaDB users should upgrade to 10.1.12. Please help! let's get one thing straight, this docker was never vulnerable to the 10.1 issues, because it was migrated straight from 10.0 branch to a 10.1 version later than the afflicted version. again, 10.1 versions prior to 10.1.12 were affected by a null table bug, hence mariadb 10.1 branch for kodi 16.1 requiring 10.1.12 and above. 10.0 is unaffected and still works. but this docker now has mysql Ver 15.1 Distrib 10.1.12-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Any luck with moving to 10.1? I upgraded Kodi to Jarvis (16.0) and it keeps crushing. I checked Kodi forums and it says that MariaDB users should upgrade to 10.1.12. Please help! let's get one thing straight, this docker was never vulnerable to the 10.1 issues, because it was migrated straight from 10.0 branch to a 10.1 version later than the afflicted version.

where ?

https

You mean this? Brought to you by linuxserver.io We do accept donations at: https://www.linuxserver.io/donations ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- finding fastest mirror 1. mirror.easyspeedy.com Latency: 8 ms Org: EasySpeedy Status: Up to date Speed: 20 Gbps 2. mirrors.telianet.dk Latency: 11 ms Org: Telia Denmark Status: Up to date Speed: 1 Gbps 3. ftp.klid.dk Latency: 11 ms Org: KLID Status: Up to date Speed: 1 Gbps New config file saved to /defaults/sources.list We are now refreshing packages from apt repositories, this *may* take a while Ign http://mirror.easyspeedy.com trusty InRelease Get:1 http://mirror.easyspeedy.com trusty-updates InRelease [65.9 kB] Ign http://ppa.launchpad.net trusty InRelease Get:2 http://mirror.easyspeedy.com trusty-security InRelease [65.9 kB] Ign http://ppa.launchpad.net trusty InRelease Get:3 http://mirror.easyspeedy.com trusty Release.gpg [933 B] Get:4 http://ppa.launchpad.net trusty Release.gpg [316 B] Get:5 http://mirror.easyspeedy.com trusty-updates/main Sources [331 kB] Get:6 http://ppa.launchpad.net trusty Release.gpg [316 B] Get:7 http://ppa.launchpad.net trusty Release [15.1 kB] Get:8 http://mirror.easyspeedy.com trusty-updates/restricted Sources [5,217 B] Get:9 http://mirror.easyspeedy.com trusty-updates/universe Sources [190 kB] Get:10 http://ppa.launchpad.net trusty Release [15.1 kB] Get:11 http://ppa.launchpad.net trusty/main amd64 Packages [921 B] Get:12 http://ppa.launchpad.net trusty/main amd64 Packages [5,864 B] Get:13 http://mirror.easyspeedy.com trusty-updates/multiverse Sources [5,942 B] Get:14 http://mirror.easyspeedy.com trusty-updates/main amd64 Packages [918 kB] Get:15 http://mirror.easyspeedy.com trusty-updates/restricted amd64 Packages [23.5 kB] Get:16 http://mirror.easyspeedy.com trusty-updates/universe amd64 Packages [440 kB] Get:17 http://mirror.easyspeedy.com trusty-updates/multiverse amd64 Packages [14.3 kB] Get:18 http://mirror.easyspeedy.com trusty-security/main Sources [137 kB] Get:19 http://mirror.easyspeedy.com trusty-security/restricted Sources [3,920 B] Get:20 http://mirror.easyspeedy.com trusty-security/universe Sources [39.1 kB] Get:21 http://mirror.easyspeedy.com trusty-security/multiverse Sources [2,547 B] Get:22 http://mirror.easyspeedy.com trusty-security/main amd64 Packages [550 kB] Get:23 http://mirror.easyspeedy.com trusty-security/restricted amd64 Packages [20.2 kB] Get:24 http://mirror.easyspeedy.com trusty-security/universe amd64 Packages [162 kB] Get:25 http://mirror.easyspeedy.com trusty-security/multiverse amd64 Packages [4,853 B] Get:26 http://mirror.easyspeedy.com trusty Release [58.5 kB] Get:27 http://mirror.easyspeedy.com trusty/main Sources [1,335 kB] Get:28 http://mirror.easyspeedy.com trusty/restricted Sources [5,335 B] Get:29 http://mirror.easyspeedy.com trusty/universe Sources [7,926 kB] Get:30 http://mirror.easyspeedy.com trusty/multiverse Sources [211 kB] Get:31 http://mirror.easyspeedy.com trusty/main amd64 Packages [1,743 kB] Get:32 http://mirror.easyspeedy.com trusty/restricted amd64 Packages [16.0 kB] Get:33 http://mirror.easyspeedy.com trusty/universe amd64 Packages [7,589 kB] Get:34 http://mirror.easyspeedy.com trusty/multiverse amd64 Packages [169 kB] Fetched 22.1 MB in 4s (4,641 kB/s) Reading package lists... (Reading database ... 16454 files and directories currently installed.) Preparing to unpack .../openssl_1.0.1f-1ubuntu2.18_amd64.deb ... Unpacking openssl (1.0.1f-1ubuntu2.18) over (1.0.1f-1ubuntu2.17) ... Setting up openssl (1.0.1f-1ubuntu2.18) ... using keys found in /config/keys Already up-to-date. Mar 20 21:40:41 32729db51032 syslog-ng[159]: syslog-ng starting up; version='3.5.3' all normal.

change the host side port mapping, unraid webui is port 80.

I've been working on my own rtorrent + rutorrent image and have seen the above when the plugins folder is either soft linked or had been deleted, worth checking guys? the only links we have are for config files.. i'm sure the user said somewhere he deleted his config folder, "don't quote" me on it.

Port mappings attached. Although I can connect through 5051, I'm still getting port in use errors, which I assume is coming from the renamer. The folders in question end up with .ignore files and the movies never get moved. DON'T change the container port, just the host side.

there's a possibility that it could be browser side problems... i don't know to be honest, but recommend a clean cache and cookies etc.

drop to an ssh shell and can you run docker ps -a and docker images please. paste the output here.

i'd backup your database just to be on the safe side, i clean my database about once every 6 months tops... so i have little experience. but it is the general consensus that sources.xml fixes it, hence the big red warning on the OP for this thread.

google tells me it's a sonarr issue..... https://forums.sonarr.tv/t/xbmc-library-not-being-cleaned-on-update/729

why do you need to clean on startup ?

only to those with unraid, now it seems.....

Because I want to make things easier for both users and developers. Why force the manual edit of a template if we can make that available from within the webgui? The "Dry Run" will expose the XML, that can be copied/pasted in any text editor directly, so there will be no need to edit by hand lots of code... I'll add a dropdown menu for all those categories you have in place at the Categorizer plugin,and add a Status:Beta|Stable category there. Other thing I'm considering implementing is the ability to update the current user template with the default template on GitHub. It will work like this: I'll add a <Template> element with the template URL. Once you hit Edit, it will download the default template, add any "Config" element that is new and update all attributes like Name, Mode etc... This way, we can keep things in sync between developers and users. What do you think? we (linuxserver.io) have 50 + containers , i don't even know how many i personally have as well. that's a helluva lot of work to make those kinds of changes via cumbersome webui interaction. as squidly rightly said, in the real world we are going to be doing manual edits because it's just the easiest way to manage all our templates.

zero problems here... ran through the wizard on a fresh install and now have the sabnzbd webui.

muximux is not a reverse proxy.

this docker is currently using the 10.0 repository, so whatever you're seeing it seems it's not that, that seems to affect 10.1 versions. currently (as in literally right at this very moment, working on moving over to 10.1)

unraid is on port 80..... change the port 80 assignment (host side only) to something other than 80.

ask over at sabnzbd forums why their ppa is behind the times.

i don't understand the desire to practically purposefully break something by messing about with dev branches. plus you regress just as much as you gain sometimes. stupid. Please don't take this as me trying to be a jerk or antagonistic, because I do respect differences of opinion and such, and the work you have done (both the linuxserver.io people and sparklyballs'), but when I see a line saying working with dev branches is stupid, and right under that statement is a link to beta branches in your sig, Kiiinda makes me go Hmmmm. Yes I do understand the differences between dev and beta (20+ years dealing with software and hardware development), and yes I agree using dev branches is risky, but someone asked if it could be done. I agree with CHBMB, it will 'void the warranty', and maybe I should have stated that in my reply. But to tell someone it is stupid without knowing that person's reasoning is, to me, well, stupid. And I would Love to see the ls.io people throw in a DEVELOPMENT flag option in the next release (+/- 4 lines of code would do it, as they have done in some of their other containers). Again, I don't mean to come off as an ass. I really do like the work put into all this. Making it easier for people to get into this stuff and getting more people using an FOSS solution for life is good stuff. who said anything about anyone's reasoning, my personal opinion was stated.

lxml is already in our python baseimage we build this container from.

i'm not seeing it mentioned anywhere on their site.

No Yes I just changed /etc/my_init.d/30_update.sh to add the change branch, so cd /app/mylar git pull git checkout development chown -R abc:abc /app ? Works fine OK, but for the record, this is unsupported.... Any problems and the party line is going to be nuke and pave and reinstall the master branch..... Just so we all know where we stand... i don't understand the desire to practically purposefully break something by messing about with dev branches. plus you regress just as much as you gain sometimes. stupid.

Sparklyballs is normally very quick at these. Give it 24 hours max I reckon. it's uploaded. change VERSION variable to 16 and away you go.