[6.2.4] TV shows being written to cache, user share not configured to use cache

[miccos]

Hi,

All of a sudden my sickbeard is writing to the cache instead of my 'TV Series' user share. Although it shows up in both locations(cache and user share), when I delete the file from the cache side it removes the file from the user share.

I have the yellow triangle next to my 'TV Series' user share but it is not configured to use the cache disk.

 

Attached is system log and some images that hopefully help explain my issue.

Cheers

syslog.txt

[itimpi]

Hi,

All of a sudden my sickbeard is writing to the cache instead of my 'TV Series' user share. Although it shows up in both locations(cache and user share), when I delete the file from the cache side it removes the file from the user share.

I have the yellow triangle next to my 'TV Series' user share but it is not configured to use the cache disk.

 

Attached is system log and some images that hopefully help explain my issue.

Cheers

The /mnt/cache location refers to a physical drive, while /mnt/user is a logical view across all drives (including the cache drive).  This will be why deleting from /mnt/cache also removes the file from /mnt/user.  There is also /mnt/user0 which gives the logical view omitting the cache.

 

I suspect that your issue is arising frim the way you have sickbeard configured.  a screenshot of the sickbeard drive mappings might help here.

 

 

[lionelhutz]

You have Sickbeard pointed to /mount/cache/TV Series. Either in the Docker config or in the Sickbeard config. You need to change it to /mnt/user/TV Series.

 

[miccos]

Thanks,

Sickbeard isn't pointing to the cache. This has only started happening in the last few weeks.

[trurl]

What do you get from the command line with this?

ls -lah /mnt/cache

[miccos]

results;

 

drwxrwxrwx  8 nobody users 200 Nov 27 01:31 ./

drwxr-xr-x  9 root  root  180 Dec 12 20:56 ../

drwxr-xr-x 10 root  root  256 Nov  5 08:37 .PhAzE-Common/

drwxrwxrwx  6 root  root  168 Nov  5 08:05 .custom/

drwxr-xr-x  3 root  root  144 Aug  8  2013 .minidlna/

drwxrwxrwx 17 nobody users 544 Dec 12 14:24 TV\ Series/

[trurl]

results;

 

drwxrwxrwx  8 nobody users 200 Nov 27 01:31 ./

drwxr-xr-x  9 root  root  180 Dec 12 20:56 ../

drwxr-xr-x 10 root  root  256 Nov  5 08:37 .PhAzE-Common/

drwxrwxrwx  6 root  root  168 Nov  5 08:05 .custom/

drwxr-xr-x  3 root  root  144 Aug  8  2013 .minidlna/

drwxrwxrwx 17 nobody users 544 Dec 12 14:24 TV\ Series/

As you can see, the User share named "TV Series" is on cache.

 

Set that user share to Use cache: Yes, run mover, then set it back to Use cache: No.

 

Mover will not move a cache-No share. It only moves cache-Yes shares from cache to array, and moves cache-Prefer shares from array to cache.

[BurlyOaf]

I am having a similar drama with Sonarr and Mover.

 

mover is scheduled, but doesn't seem to run and has resulted in my cache drive running out of space.

 

i have tried quite a few times, invoking mover, letting it finish, then altering the TV share to not use cache. the next day there is TV present on the cache again, and i have to re-enable cache on the share to get mover to get them from there, then disable mover again.

 

Sonarr is set for

/config  /mnt/cache/appdata/nzbdrone2/

/mnt/  /mnt/

[itimpi]

I am having a similar drama with Sonarr and Mover.

 

mover is scheduled, but doesn't seem to run and has resulted in my cache drive running out of space.

 

i have tried quite a few times, invoking mover, letting it finish, then altering the TV share to not use cache. the next day there is TV present on the cache again, and i have to re-enable cache on the share to get mover to get them from there, then disable mover again.

 

Sonarr is set for

/config  /mnt/cache/appdata/nzbdrone2/

/mnt/  /mnt/

what are the settings within Sonar for writing data?    Since the disk mappings show you have given it access to everything under /mnt then the Sonar internal settings could be specifying the cache disk directly which would cause the symptoms you describe.

[miccos]

Yeah just did as Trurl recommended; turn use cache on form my share and ran mover. Shows moved off cache. So I set the share BACK to use cache NO.

Same thing, shows are being written to cache when settings are set not to.

[itimpi]

Yeah just did as Trurl recommended; turn use cache on form my share and ran mover. Shows moved off cache. So I set the share BACK to use cache NO.

Same thing, shows are being written to cache when settings are set not to.

That happens when the app writes directly to /mnt/cache bypassing the User share system.

[miccos]

My SB is not point to the cache. It is pointing to the share.

[itimpi]

You also need to make sure that the configuration is not one that means the app thinks it can use a rename on a file after downloading the file as renames always leave the file on the same drive. 

 

There have not been any instances I have seen posted where this issue cannot be traced to a configuration issue so giving as much info as possible on your settings will help with spotting what might be the issue.

[miccos]

the root directory for SB is;

Root Directories *

Edit /mnt/user/TV Series => /mnt/user/TV Series

 

[BRiT]

Did you make sure to delete the empty "TV Series" directory off the /mnt/cache/ hierarchy after mover ran?

[JonathanM]

the root directory for SB is;

Root Directories *

Edit /mnt/user/TV Series => /mnt/user/TV Series

To what path is the nzb or torrent client saving the file? Does that path exist on the cache drive?

[Squid]

All of these posts are all implying that its the docker client which is misconfigured. 

 

But the path mappings pointing to /mnt/user for TV Shows also implies that its impossible for the client to put anything on the cache drive if the share settings are correct.

 

What we have to do to really determine what's going on is two things:

 

echo "Test" > "/mnt/user/TV Shows/test"

 

Where is the file test created?

 

And secondly:

 

echo "Test" > "/mnt/cache/test1"
mv /mnt/cache/test1 "/mnt/user/TV Shows/test1"

 

Where is the file test1 sitting at after the second command?

 

If the share settings are correct, then both files should not be on the cache drive (and its something within the volume paths for the container).  If either of those files are on the cache drive, then something is up with the share settings.

[miccos]

I ran;

echo "Test" > "/mnt/user/TV Series/test"

 

Created a test file on the TV series share (\\tower\TV Series)

 

I ran;

echo "Test" > "/mnt/cache/test1"

 

Created a test1 file on the cache (\\tower\cache)

 

I ran;

mv /mnt/cache/test1 "/mnt/user/TV Series/test1"

 

Moved test1 to the TV Series share (\\tower\TV Series)

 

 

I have gone into SB and redone the following; but it is not the first time I have done it and SB has never point to cache previously; (SB is Phaze's plugin)

Root Directories *

Edit /mnt/user/TV Series => /mnt/user/TV Series

[lionelhutz]

"Root Directories" like you are describing isn't a SickBeard setting so it must be something to do with the plugin settings???

 

What does Sickbeard show here?

 

 

Go to a show that is on the cache disk and see what is under the location here?

 

 

This is a Docker so /tv is mapped to the user share by the Docker settings.

[miccos]

Attached is where SB is looking at.

 

All my shows have this(/mnt/user/TV Series/) location set as their location. And any new episode is being written to the cache.

[lionelhutz]

I have turned the use cache setting on and off on my TV share and files are not written to the cache with it turned off. You have a setup problem. What downloader and how is is the post-processing being done?

 

 

[miccos]

Using SAB and Sickbeard does the post-processing.

 

[trurl]

I ran;

echo "Test" > "/mnt/user/TV Series/test"

 

Created a test file on the TV series share (\\tower\TV Series)

 

I ran;

echo "Test" > "/mnt/cache/test1"

 

Created a test1 file on the cache (\\tower\cache)

 

I ran;

mv /mnt/cache/test1 "/mnt/user/TV Series/test1"

 

Moved test1 to the TV Series share (\\tower\TV Series)

But after you did that did you check whether or not these are on cache?

If the share settings are correct, then both files should not be on the cache drive (and its something within the volume paths for the container).  If either of those files are on the cache drive, then something is up with the share settings.

As has already been explained, cache is included in user shares, so seeing that the files end up in /mnt/user does not mean they are not in /mnt/cache.

 

What do you get with this?

ls -lah /mnt/cache

[miccos]

Results from ls -lah /mnt/cache

results;

 

drwxrwxrwx  8 nobody users 200 Nov 27 01:31 ./

drwxr-xr-x  9 root  root  180 Dec 12 20:56 ../

drwxr-xr-x 10 root  root  256 Nov  5 08:37 .PhAzE-Common/

drwxrwxrwx  6 root  root  168 Nov  5 08:05 .custom/

drwxr-xr-x  3 root  root  144 Aug  8  2013 .minidlna/

drwxrwxrwx 17 nobody users 544 Dec 12 14:24 TV\ Series/

 

Yes I confirmed that both test files were on the share.

[trurl]

Results from ls -lah /mnt/cache

results;

 

drwxrwxrwx  8 nobody users 200 Nov 27 01:31 ./

drwxr-xr-x  9 root  root  180 Dec 12 20:56 ../

drwxr-xr-x 10 root  root  256 Nov  5 08:37 .PhAzE-Common/

drwxrwxrwx  6 root  root  168 Nov  5 08:05 .custom/

drwxr-xr-x  3 root  root  144 Aug  8  2013 .minidlna/

drwxrwxrwx 17 nobody users 544 Dec 12 14:24 TV\ Series/

 

Yes I confirmed that both test files were on the share.

We're not asking if the test files are in the user share. We are asking if they are on the cache drive. They would be in the user share even if they are on the cache drive. And as we noted before "TV Series" is on cache.