Considering moving from Plex, what do I need to know?
#1
I have a healthy Plex setup with multiple servers, PVR, Live TV, Music, Amazon Echo integration, and a ton of video content from OTA recordings and rips of my various DVD's and BluRay's.

While Plex served me well for quite some time, there are a number of reasons why it no longer does. So, I need an alternative and I'd like to retain as much functionality as I can. But, I don't really know the in's and out's of how a Kodi deployment would look, especially since I want it to run on top of OpenSUSE (my preferred distro). Is there a good starting point where I can understand the specific features and functions that will be available to me?

One very basic thing I'm trying to understand is this: Do I actually run a server or am I really only building clients and letting them connect directly to the media? Seems there's a lot of discussion around things like NFS and CIFS/SAMBA, so I'm not 100% sure of the architecture.

Thanks in advance.
Reply
#2
The wiki -> https://kodi.wiki/view/Main_Page is an excellent place to start, but for a quick few pointers.

If you want your media accessible in multiple rooms and want watched status to be replicated there, plus the ability to stop a tv show/movie in one room and resume it from where you left off in another, then you need to use some form of MySQL/MariaDB and some method of sharing your files across your network.  You then point all your clients at the db and use ONE of them to add and scrape your media.  This then appears on all the other clients.  This is how my setup works.  I share my files over both samba and nfs.  All my kids stuff is on samba shares and all mine on nfs.  This helps me keep it separate whilst also allowing one machine to update every client.

You can put your media where you want.  Either on one machine or spread it across multiple machines. As long as you add the media to one Kodi instance using the network paths then all machines will find it.  You can also do things like  path substitution, which I use on 3 machines to replicate the 'favourites' file from the main machine.  This means that updating anything in that file is automatically replicated on the others.

I'd suggest initially, getting just one machine to work with a central database and then add another client.

As regards PVR, I set up TVHeadend as my backend and then it's just a question of installing the pvr.hts addon in Kodi and pointing each client to the tv server.  Each one can access live tv, recordings etc and all that is handled by the backend - Kodi just provides a nice interface to it.

There ARE a lot of features to Kodi and it can take a while to 'tweak' it to your satisfaction, but it is extremely powerful and flexible.  Have a read of the Wiki, then jump in !!
Learning Linux the hard way !!
Reply
#3
(2018-09-18, 09:35)black_eagle Wrote: The wiki -> https://kodi.wiki/view/Main_Page is an excellent place to start, but for a quick few pointers.

If you want your media accessible in multiple rooms and want watched status to be replicated there, plus the ability to stop a tv show/movie in one room and resume it from where you left off in another, then you need to use some form of MySQL/MariaDB and some method of sharing your files across your network.  You then point all your clients at the db and use ONE of them to add and scrape your media.  This then appears on all the other clients.  This is how my setup works.  I share my files over both samba and nfs.  All my kids stuff is on samba shares and all mine on nfs.  This helps me keep it separate whilst also allowing one machine to update every client.

You can put your media where you want.  Either on one machine or spread it across multiple machines. As long as you add the media to one Kodi instance using the network paths then all machines will find it.  You can also do things like  path substitution, which I use on 3 machines to replicate the 'favourites' file from the main machine.  This means that updating anything in that file is automatically replicated on the others.

I'd suggest initially, getting just one machine to work with a central database and then add another client.

As regards PVR, I set up TVHeadend as my backend and then it's just a question of installing the pvr.hts addon in Kodi and pointing each client to the tv server.  Each one can access live tv, recordings etc and all that is handled by the backend - Kodi just provides a nice interface to it.

There ARE a lot of features to Kodi and it can take a while to 'tweak' it to your satisfaction, but it is extremely powerful and flexible.  Have a read of the Wiki, then jump in !!
 Thank you.

This is exactly the sort of thing that I needed.

I will definitely dig into the Wiki, but I have one additional question about what you've written... 

My Plex setup uses a server, and that's the sort of model that I want to continue with. Meaning... The machine with all of the content will be tucked away and headless. In this scenario, how do I put a "client" onto the machine with the content and have it operate to pull in all of the media and update the database? I know that many folks will set up their content system connected to a TV as a HTPC, but that's not the model I am working with. My primary content machine sits "out of sight".
Reply
#4
What you can do is have a NAS or similar central storage hub, on which you can run a MySQL (wiki) database (or alternatively you can run that elsewhere on your network).

Then put your Kodi devices onto the same network, and you can set them all up to use that same shared database (and if you must you can use path substitution (wiki) to share other bits). Then all your devices will have common watched statuses and stuff like that. The devices can be PCs, media boxes or stuff like the Raspberry Pi or a firestick.

It's not really the same client/server mechanism that Plex uses, but it can be moulded into something along those lines. It's more accurately centralised network storage which is accessed in the same way you would do from a PC and fileserver set-up. What you want should fit into that scenario nicely.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
#5
(2018-09-18, 15:31)DarrenHill Wrote: What you can do is have a NAS or similar central storage hub, on which you can run a MySQL (wiki) database (or alternatively you can run that elsewhere on your network).

Then put your Kodi devices onto the same network, and you can set them all up to use that same shared database (and if you must you can use path substitution (wiki) to share other bits). Then all your devices will have common watched statuses and stuff like that. The devices can be PCs, media boxes or stuff like the Raspberry Pi or a firestick.

It's not really the same client/server mechanism that Plex uses, but it can be moulded into something along those lines. It's more accurately centralised network storage which is accessed in the same way you would do from a PC and fileserver set-up. What you want should fit into that scenario nicely.
 Thanks.

But, is there a way to put a client onto that main storage system for the purpose of -IT- being the client that imports information about new content and such? What I don't want to have happen is designate a primary client that is actually a client, and then not be able to see new content on a secondary client because the primary hasn't been connected recently. Does that question make sense?
Reply
#6
Every connected Kodi device will act as a client. Once the new videos/music are scraped into the Kodi libraries, all other clients will update their local cache data/thumbs once they are connected again.
Reply
#7
That's sort of what I don't want to have happen, though... I don't want to connect with a mobile client from outside the house and have -that- client be the one that updates the system (too much data transfer on a metered plan).
Reply
#8
There's nothing to stop the same device being client and storage, of course presuming the hardware is capable. For example there are several NAS boxes out there which have the capability to run Kodi.

And depending on how you set it up, you can have one client or any/all of them as a "master" which can update the database in terms of adding new content etc. But of course as it's a centralised database, in the end it doesn't really matter (and all will be able to update the watched statuses anyway).

As I said, the key difference is between client/server and player/source-storage - the former being the Plex and the latter the Kodi. Indeed there's nothing to stop you storing media wherever you like, as you can set up as many sources on your network as you wish.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
#9
(2018-09-18, 17:24)DarrenHill Wrote: There's nothing to stop the same device being client and storage, of course presuming the hardware is capable. For example there are several NAS boxes out there which have the capability to run Kodi.

And depending on how you set it up, you can have one client or any/all of them as a "master" which can update the database in terms of adding new content etc. But of course as it's a centralised database, in the end it doesn't really matter (and all will be able to update the watched statuses anyway).

As I said, the key difference is between client/server and player/source-storage - the former being the Plex and the latter the Kodi. Indeed there's nothing to stop you storing media wherever you like, as you can set up as many sources on your network as you wish.
 Thanks.

I run my storage systems on OpenSUSE Linux. So, as long as I can get a client installed on that same box, it should handle the workload without issue.
Reply
#10
(2018-09-18, 16:26)ember1205 Wrote: That's sort of what I don't want to have happen, though... I don't want to connect with a mobile client from outside the house and have -that- client be the one that updates the system (too much data transfer on a metered plan).
Just to interrupt: each client will have client-specific settings, so your mobile client can be set NOT to update databases and leave the home-based systems perform the update.

I have a colleague who moved his Kodi databases to MySQL so that shows were synched between different installs, but I believe only one does the updating on behalf of all the others.  His motivation was simply that if he wanted to watch a TV series on his PC or in the bedroom, the list reflected "last watched" from the lounge - so it was the lounge build that did all the heavy work.

You may also want to consider an install of some kind on the NAS itself to periodically perform updates.  I have a scheduled nightly job that refreshes content remotely then calls a quick "update-library()" command using kodi-send.
Reply
#11
(2018-09-22, 12:19)Preacher Wrote:
(2018-09-18, 16:26)ember1205 Wrote: That's sort of what I don't want to have happen, though... I don't want to connect with a mobile client from outside the house and have -that- client be the one that updates the system (too much data transfer on a metered plan).
Just to interrupt: each client will have client-specific settings, so your mobile client can be set NOT to update databases and leave the home-based systems perform the update.

I have a colleague who moved his Kodi databases to MySQL so that shows were synched between different installs, but I believe only one does the updating on behalf of all the others.  His motivation was simply that if he wanted to watch a TV series on his PC or in the bedroom, the list reflected "last watched" from the lounge - so it was the lounge build that did all the heavy work.

You may also want to consider an install of some kind on the NAS itself to periodically perform updates.  I have a scheduled nightly job that refreshes content remotely then calls a quick "update-library()" command using kodi-send. 
 Understood, and I would agree that installing a client on the storage system (or one that has access to all storage if it's across multiple systems - I have six 6TB drives across two different computers with all of my music, DVD rips, and OTA recordings) to perform updates would be desirable. I would want the updates to be more "real-time" so that as shows gets recorded, they are in the system and only the main client does updating.

The use of a DB is appealing so that I could potentially connect to different servers with the same content (replicated) and "pick up where I left off".
Reply
#12
(2018-09-23, 03:54)ember1205 Wrote:
(2018-09-22, 12:19)Preacher Wrote:
(2018-09-18, 16:26)ember1205 Wrote: That's sort of what I don't want to have happen, though... I don't want to connect with a mobile client from outside the house and have -that- client be the one that updates the system (too much data transfer on a metered plan).
Just to interrupt: each client will have client-specific settings, so your mobile client can be set NOT to update databases and leave the home-based systems perform the update.

I have a colleague who moved his Kodi databases to MySQL so that shows were synched between different installs, but I believe only one does the updating on behalf of all the others.  His motivation was simply that if he wanted to watch a TV series on his PC or in the bedroom, the list reflected "last watched" from the lounge - so it was the lounge build that did all the heavy work.

You may also want to consider an install of some kind on the NAS itself to periodically perform updates.  I have a scheduled nightly job that refreshes content remotely then calls a quick "update-library()" command using kodi-send.   
 Understood, and I would agree that installing a client on the storage system (or one that has access to all storage if it's across multiple systems - I have six 6TB drives across two different computers with all of my music, DVD rips, and OTA recordings) to perform updates would be desirable. I would want the updates to be more "real-time" so that as shows gets recorded, they are in the system and only the main client does updating.

The use of a DB is appealing so that I could potentially connect to different servers with the same content (replicated) and "pick up where I left off".  
 Recordings are updated in real time.  At least, they are with TVHeadend.  Once a recording is completed, it is automatically available to all clients under the 'recordings' tab on the TV menu.  There is no need to trigger Kodi's 'update library' routines for this.  You only need to do that if you add what I call 'more permanent content' - movies, music etc.

TVH has its own 'recording' directory where it stores everything it records and this is (certainly on my system) completely separate from any media directories that Kodi can see.  Of course, it's possible that you may wish to permanently keep your recordings and add them to Kodi's database of TV shows.  TVH can trigger both pre-recording and post-recording scripts (mine triggers comskip to cut out commercials) so you can easily write shell script to move stuff into the correct directories for Kodi and then trigger an update library on whichever instance you decide is the 'main'.

If you're using a MySQL shared database, watched status and play position are automatically recorded in the db.  So, if you play part of a movie or tv show in one room and then stop it, you can resume it in another room from where you left off.  The only caveat to this is that you must add all the content to your 'main' kodi instance using network paths.  MySQL (wiki) provides a walkthrough and explains what you can and can't sync between machines.
Learning Linux the hard way !!
Reply

Logout Mark Read Team Forum Stats Members Help
Considering moving from Plex, what do I need to know?0