Sync job setup

[lorac 100]

I'm sure I'm missing something but I'm not understanding how folder / google drive sync is supposed to be configured. I don't see any general sync option as described in the sync jobs / folder sync KB or anywhere within the server dashboard.

I have the google drive plugin configured & all my media is already backed up to the cloud (just media, no nfo or images). The folder sync plugin is installed but there's nothing to configure apart from adding a name / path.

What I would like to do is have remote users play from the cloud and my household play directly from the server. Sounds simple enough?

 

[Carlo 4330]

Hi, folder sync doesn't do this.  It's for creating alternate versions of your files in a different location than the media.  Example all your movies are stored on drive F:\.  With Folder sync you can have a background process creating mobile (just an example) versions of all movies but stored on drive G:\MobileSync and could have another job creating TV versions limited to 4Mb stored in H:\TVSync.

All media still goes through the server in order to be played on the client.

The Google Drive plugin is rather hard to setup thanks to the run around Google makes you do with the setup and API access on their side. This plugin would essentially make a copy of your local media to Google Drive. All media needs to remain local in order to stay synced.

If using Google Drive plugin some clients can play directly from Google Drive but you have to understand that's a bonus and not the main reason to use this plugin.  No client available in a store can play direct so Roku's, Xbox, Windows Store Theater, Android, Android TV, Amazon Firesticks as examples would all have to play the media back through your server.

[lorac 100]

OK. I'll just go with the workaround of mapping network drives that have the Google Drive content and then I test to see if emby plays from local or cloud.

I use rclone to keep everything synced already.

[Carlo 4330]

Emby is going to play directly from the Emby Server which will retrieve the media via rclone.

[lorac 100]

thanks.

[lorac 100]

I still don't understand how / if you can configure what gets synced to Google drive as some media is already exclusive to GD already.

I don't see anything in the plug in or general emby settings.

[Luke 37045]

56 minutes ago, lorac said:

I still don't understand how / if you can configure what gets synced to Google drive as some media is already exclusive to GD already.

I don't see anything in the plug in or general emby settings.

HI, you have to send media to google drive using the "Download to..." menus throughout the server. Have you done that?

[lorac 100]

That seems clumsy and isn't explained very well (IMO) in the KB.

Why not just have the option for setting up the syncing directly in the plug in to make things simpler?

The media is already on GD. I'll have to play around with it to see how it saves to GD when emby syncs media. 

 

[Carlo 4330]

https://support.emby.media/support/solutions/articles/44001161893-sync-introduction

Remember this doesn't just copy the files but can convert your media to a different format for direct streaming when appropriate.

You may not want to have a job that copies all Movies to the cloud as that could require far too much bandwidth and storage.  You may want to keep only the 25 most recent movies added or 10 most popular or box office hits synced like this.

Emby allows you to setup these jobs as needed to sync/download to the cloud provider only the media you want synced.

[Luke 37045]

Quote

Why not just have the option for setting up the syncing directly in the plug in to make things simpler?

Because what content would you transfer? The plugin would have to provide a whole user interface for that, when we already have one.

[lorac 100]

Libraries. You don't really have an interface for it, rather you have a convoluted sync option outside the admin settings.

I already have all the media on GD and wouldn't bother creating different profiles. The media is the media and if it needs to be transcoded so be it but that seems far simpler than creating different profiles based on different devices. I have 125 TB of media locally & synced to GD along with probably another 20TB that only exists on GD. So if clients can play directly from GD that would be awesome.

I understand it makes sense to you but to me it really doesn't.

[Carlo 4330]

But it really does make sense once you use it as it's the same regardless if your "download to" or sync to a cloud provider, phone, tablet, Windows Store Theater, folder sync or any other download to/sync function as they all use the same UI.  The only difference is the destination chosen.

You just described exactly why this is good to have this way.  You could for example setup one job that creates 1080 -8MB versions of files and also a 720-2MB version.  Now you have the original plus two alternate direct playable versions.

You may want a different "sync" for 4K media then your TV recordings. You may want a different format for music files that uses less room on the phone.

All of this can be setup per job to match your needs. 

[Luke 37045]

@lorac has this answered your questions?

[lorac 100]

Well there's still the matter of the media already being present on Google Drive.

It would be nice to point emby to that existing media since it wouldn't make sense to snyc it all again. Currently the root of GD has the top level media folders of Movies, Music, TV, etc. Creating media in alternate formats could be looked at down the road but isn't a high priority.

[Carlo 4330]

When you sync media you can transform/convert it as it's being copied.  This allows making Mobile versions and low bitrate TV versions that can direct play and all have common codecs that direct play assuming the client has adequate bandwidth.

This can make it easier on your server as each file theoretically need only be transcoded once or twice (depending on number of versions) instead of every time it's played.

You're trading storage for processing power long term.

Regardless if your media is local or on a cloud this doesn't factor into what "Download to" is designed to do so there is no "pointing to it".  You may have the wrong idea what this is for.

[lorac 100]

It really doesn't sound useful IMO.

Oh well.

Thanks anyway.

[Carlo 4330]

It's really useful when you understand how to use it wisely. As an example you can setup jobs to take the most current added content and create a Mobile and TV versions that will direct play for remote users while you still have a 40Mb ripped version for local use. This can be a better quality version than what would happen with a real-time transcode.

The power of this feature is how you setup the criteria for the sync job.
 

As an Example say the new Top Gun Maverick was just released and you ripped it to a 50Mb file.  Chances are none of your remote clients are going to be able to stream this file at that rate so you create a TV version at 1080/8Mb that looks good and is small enough that it direct plays to the remote clients.

Now the 10 people you share with all play it during the first week or two you've got this so you converted it one time and made a better version than what could be done in real-time.  So instead of transcoding this file each and every time (10 times) it was converted once.

If this 50Mb file was hosted in the cloud then every time your server had to transcode it you would have to pull the full file essentially using up your bandwidth vs pulling down the 8Mb version for each client as needed.  See how that can work for you?

You're trading CPU/GPU up front for storage so that you later save both.  This is why it's useful to setup sync jobs specific to your media and how your users will play it.

Another example might be syncing popular TV shows that multiple users play.  Game of Thrones was a good example of this as everyone of my peeps were following this.

[Luke 37045]

On 7/26/2021 at 7:25 PM, lorac said:

Well there's still the matter of the media already being present on Google Drive.

 

In can utilize existing content that was previously transferred, if that's what you mean. But the original has to still exist in your main emby library.

[lorac 100]

Ok. Thanks.

[Luke 37045]

Have your questions been answered?

[lorac 100]

Sure why not. Lol.

Although I think instead of ripping it myself it might be easier to just grab alternate versions.

Anyway food for thought on how to best set all this up as Sonarr and Radarr aren't designed for multiple files.

Thanks for the support.