Is there a point to cache/mover for plex box?

[jebusfreek666]

Just wondering if I am doing this wrong? I get the concept behind having a cache drive so that you can load files to the server faster. And I can see the convenience of allowing mover to put those files on the array while your asleep. But, if you use unraid primarily as a media server, and all of your downloads are handled by sonarr/radarr with deluge, it kind of seems like it never gets to do it's job. What I mean is, files are downloaded to the cache in an "incomplete" folder. When they are completed, deluge moves them to a "complete" folder. At that time it's my understanding that sonarr/radarr move it over to the array immediately so it is available for plex to use as soon as its available. This, to me, seems to cut out the entire function of mover. Unless I am just not reading how this is working correctly. Seems like everything should sit on the cache until mover runs.... But I guess I could be wrong on this. 

[itimpi]

What makes you think that sonarr/radarr move the files to the array?   It would depend on exactly how they are configured and how the User Shates are configured.    I would normally think they would get moved to a share set as Use Cache=Yes and then later mover moves the files to the array.   

[jebusfreek666]

30 minutes ago, itimpi said:

What makes you think that sonarr/radarr move the files to the array? 

The media share is set up as "cache: no". Sonarr/radarr monitor the container path data set to the download share. The media container path is set to the media share which is on the array. I thought that it was seeing the downloaded file, moving it and renaming it, and that was how the process worked. Something moves it immediately. Plex only looks at the media share, which is only on the array. And 5 seconds after deluge finishes downloading a file, it is available on plex. So it is not waiting for the unraid mover to do its thing. 

[trurl]

If sonarr/radarr is moving the data to a cache-no share then of course it is moving it to the array since that share doesn't use cache.

 

What was the question?

[jebusfreek666]

What do I need to change to make things stay on the cache until mover runs instead? I don't care if the media is not available until the next day, I would prefer efficiency for the server and downloads. 

Edited January 29, 2019 by jebusfreek666

[trurl]

Make the share sonarr/radarr is moving the data to use the cache disk?

[jebusfreek666]

So, if I set the media share (which contains Tv and Movies folders) to use cache: yes it will keep everything on the cache. Then when mover runs it will shift it from the SSD cache to the HDD array drives with the same folder name? Worried that I will fill up the cache with media quickly if not. Also, with that setting, it seems like things would still be available immediately, just read from the cache instead? 

[kizer]

Make sure you use the Help button in your shares to get the best idea of what each of settings are on your cache drive.

I personally have an uploads folder on my Cache Drive. FileBot reads from it and then puts it in appropriate Share being either TV or Movie. I also use the Mover Tuner Plugin and told my Cache not to empty unless its at least 50%. So my newest files live on my SSD drive which gives me instant access to my shows or movies. To my Family they can care less if what they are watching is on the array or on the SSD.

 

[trurl]

1 hour ago, jebusfreek666 said:

when mover runs it will shift it from the SSD cache to the HDD array drives with the same folder name?

The user shares are just the combined top folders on cache and array disks with the same name, so yes that's right. Cache-yes user shares are moved from cache to the array when mover runs.

 

1 hour ago, jebusfreek666 said:

with that setting, it seems like things would still be available immediately, just read from the cache instead? 

Cache is part of the user shares, so any read from a user share will include any of the files for that share that are on cache, so yes that's also right.