Mysql or emby server on unraid server for centralized db
#1
I want to have a centralized database for all my kodi setups

However not sure which way to go
either 1. go headless kodi version from sparklyballs and mysql setup
or go 2. https://lime-technology.com/forum/index....ic=41207.0 with http://emby.media/community/index.php?/b...open-beta/

is there some sort of list for all (dis)advantages of both?

Which one is the best way to go?
Reply
#2
Well the emby kodi plugin is not in the official repo (last time I checked) and if I remember correctly it's due to violation of the repo rules.
Might want to keep this in mind.

Other than that I'm hearing great things, but the server is to depending for my synology NAS and it can't keep up. So it's unuseable when you have small hardware.
Reply
#3
(2015-08-27, 16:49)Skank Wrote: I want to have a centralized database for all my kodi setups

However not sure which way to go
either 1. go headless kodi version from sparklyballs and mysql setup
or go 2. https://lime-technology.com/forum/index....ic=41207.0 with http://emby.media/community/index.php?/b...open-beta/

is there some sort of list for all (dis)advantages of both?

Which one is the best way to go?


I'm using Emby as a central server to my 3 Kodi installs. It works great and requires very minimal setup. Best of both worlds. All the front end compatibility and skins of Kodi with the wonderful metadata management and transcoding of Emby. I've been using it since v1 came out, and haven't really experienced any major issues. If you're looking for a centralized database it really is a great solution.
Reply
#4
Huh, what repo rule did Emby violate?
Reply
#5
(2015-08-27, 20:57)Ned Scott Wrote: Huh, what repo rule did Emby violate?

Not emby, the emby kodi plugin. If I remember correctly from the kodi dev mailinglist it's

Quote:direct access to the Kodi database is not allowed. You must use JSON RPC for this.

As pointed out here http://kodi.wiki/view/Add-on_Rules#Requi...nd_plugins
Reply
#6
Ah yes, rigid rules that don't allow for reasonable, limited exceptions, for cases where our API is lacking. That is our (Kodi's) loss.
Reply
#7
From what I understand those rules are there for the very good reason that add-ons in the official repo should not be capable of corrupting the core databases hence JSON RPC must be used. I believe the offer has been made that if there any deficiencies in the JSON RPC interface then a detailed list of what's required should be provided and it'll be looked at, however even better would be the Emby devs submitting PR's to improve the JSON RPC interface themselves.
Reply
#8
Also, if you don't obey your own rules, then there probably is a real problem ahead
Reply
#9
We already mentioned we'd put a list together for what's missing. However I will say right now, the biggest problem we faced is how slow json-rpc performs because we can't process items in bulk. One json rpc query is one commit to the database, right?

When it takes 4 hours to import a medium sized library and takes only 4 mins for the same library to process with direct database writing, we opted for the faster way for the time being.

We still hope someday we can make it with json rpc, but the first step towards improving would be to allow for bulk processing in one transaction.
Reply
#10
(2015-08-27, 21:27)jjd-uk Wrote: From what I understand those rules are there for the very good reason that add-ons in the official repo should not be capable of corrupting the core databases hence JSON RPC must be used.

I'm skeptical that there was any evidence or actual risk of this happening. It's more likely that it was summarily dismissed. I have a lot of respect for our guys who handle repo submissions, but this wouldn't be the first time something was waved off without any real review, and attempts to appeal the decision are flat out rejected with even less review (as if it was a personal insult to ask for an exception).

Maybe that wasn't the case for Emby, but it feels like a lot of add-ons get needlessly rejected for overly rigid rules. I recall at least one example where an add-on was rejected for only reading the database, which holds no risk of corrupting the database. Yes, JSON-RPC should be used and expanded as needed, but people are left with nothing while waiting for that expansion.

(2015-08-27, 21:57)Razze Wrote: Also, if you don't obey your own rules, then there probably is a real problem ahead

Exceptions to rules are supposed to be made on a case by case basis. This is actually something Team Kodi has discussed in the past. The reason for a rule might not always apply to some situations, so reasonable and limited exceptions can and should apply. There's no problem with the occasional exception. We still control our own repository, so it won't suddenly allow everyone to break the rules. These rules are not morals, either. It's not like we'll lead by bad example, since the add-ons still exist. The Emby add-on is still available for download, it still works the same way, it just requires more hoops to jump through for the user to install it. I don't see how that serves anyone.
Reply
#11
(2015-08-27, 20:03)kmarq Wrote:
(2015-08-27, 16:49)Skank Wrote: I want to have a centralized database for all my kodi setups

However not sure which way to go
either 1. go headless kodi version from sparklyballs and mysql setup
or go 2. https://lime-technology.com/forum/index....ic=41207.0 with http://emby.media/community/index.php?/b...open-beta/

is there some sort of list for all (dis)advantages of both?

Which one is the best way to go?


I'm using Emby as a central server to my 3 Kodi installs. It works great and requires very minimal setup. Best of both worlds. All the front end compatibility and skins of Kodi with the wonderful metadata management and transcoding of Emby. I've been using it since v1 came out, and haven't really experienced any major issues. If you're looking for a centralized database it really is a great solution.

I like the idea too of using kodi as frontend and emby as backend for database buidling
Are you using it with direct or plugin path?
Cause it seems when using plugin path , i cant make "path" filters in smartplaylists
Thats a shame
Reply
#12
(2015-08-28, 04:00)Ned Scott Wrote:
(2015-08-27, 21:27)jjd-uk Wrote: From what I understand those rules are there for the very good reason that add-ons in the official repo should not be capable of corrupting the core databases hence JSON RPC must be used.

I'm skeptical that there was any evidence or actual risk of this happening. It's more likely that it was summarily dismissed. I have a lot of respect for our guys who handle repo submissions, but this wouldn't be the first time something was waved off without any real review, and attempts to appeal the decision are flat out rejected with even less review (as if it was a personal insult to ask for an exception).

Maybe that wasn't the case for Emby, but it feels like a lot of add-ons get needlessly rejected for overly rigid rules. I recall at least one example where an add-on was rejected for only reading the database, which holds no risk of corrupting the database. Yes, JSON-RPC should be used and expanded as needed, but people are left with nothing while waiting for that expansion.

(2015-08-27, 21:57)Razze Wrote: Also, if you don't obey your own rules, then there probably is a real problem ahead

Exceptions to rules are supposed to be made on a case by case basis. This is actually something Team Kodi has discussed in the past. The reason for a rule might not always apply to some situations, so reasonable and limited exceptions can and should apply. There's no problem with the occasional exception. We still control our own repository, so it won't suddenly allow everyone to break the rules. These rules are not morals, either. It's not like we'll lead by bad example, since the add-ons still exist. The Emby add-on is still available for download, it still works the same way, it just requires more hoops to jump through for the user to install it. I don't see how that serves anyone.

I would think the main problem with direct access is that version bumps and changes in the internal tables, will likely cause big breakages if not even a unuseable database.

For e.g.:
Addon X is reading the id field.
We change the id field to not only holding one id but potentially X ids, wrapping the ids in XML or json or whatever.
Addon X does not compute.


Addon X is writing the id field.
We change the id field to not only holding one id but potentially X ids, wrapping the ids in XML or json or whatever.
Addon X writes one id back to the field without XML or json around it.
Kodi can't read this set of data anymore, might also crash due to a bad conversion.
Only way to recover from this scenario might be to access the database and fix this value by hand. So every casual user would be lost.

In both cases, the JSON RPC interface wouldn't have changed, so it would not be a problem.

I thought the offical repo is trying to protect users, like you guys said in one of the last kordcutters I think and letting devs break this rule, is the absolute opposite.
Reply
#13
(2015-08-28, 11:01)Skank Wrote:
(2015-08-27, 20:03)kmarq Wrote:
(2015-08-27, 16:49)Skank Wrote: I want to have a centralized database for all my kodi setups

However not sure which way to go
either 1. go headless kodi version from sparklyballs and mysql setup
or go 2. https://lime-technology.com/forum/index....ic=41207.0 with http://emby.media/community/index.php?/b...open-beta/

is there some sort of list for all (dis)advantages of both?

Which one is the best way to go?


I'm using Emby as a central server to my 3 Kodi installs. It works great and requires very minimal setup. Best of both worlds. All the front end compatibility and skins of Kodi with the wonderful metadata management and transcoding of Emby. I've been using it since v1 came out, and haven't really experienced any major issues. If you're looking for a centralized database it really is a great solution.

I like the idea too of using kodi as frontend and emby as backend for database buidling
Are you using it with direct or plugin path?
Cause it seems when using plugin path , i cant make "path" filters in smartplaylists
Thats a shame

I'm using direct with the SMB shares. I believe the addon has things called Smart Shortcuts. If you setup your Emby library the right way they may allow you to go to your paths. I haven't really used them though so can't say much.
Reply
#14
I'm having troubles with building db in emby
I think having all nfo files and jpg files in my movie folders might cause it

what did you do?
Remove everything , including nfo files before building library in emby?
Reply
#15
I had set up EMBY after a fresh install of Isengard on three machines but i found that it didn't display the music library correctly (they are working on this the last time I checked) or music videos correctly. I went back to a MySQL database and it still works pretty flawlessly. The only thing I have noticed with the MySQL setup is the need to set Movie Sets posters manually from time to time on the different machines. But if you install Trentf's Movie Set Artwork Automator script on each machine, it will easily make those adjustments for you.
Reply

Logout Mark Read Team Forum Stats Members Help
Mysql or emby server on unraid server for centralized db0