Hey, at what point will it start to use the other disks? or have I misconfigured something?  

 

 

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Thanks for the info.  I have attached the diagnostics.

 

defiant-diagnostics-20230617-1228.zip

I have just set the minimum free space to 20% to see if that changes anything

Cannot see any obvious reason why the files are only going to the first drive   Maybe somebody else will spot something  just as a check are you sure you are. Opting the files to the User Share and not explicitly to disk1?

 

on a completely different issue I can see entries in your syslog of the form:

/usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

is there any chance you could do the following for me:

1. enable the Testing mode of logging in the settings for the Parity Check Tuning plugin
2. go to Tools->PHP Settings and set the Error Reporting Level to All
3. let the system run for a while until the plugin’s Monitor task runs again.
4. let me have new diagnostics at that point and also any entries in the PHP logs that reference the plugin.
5. set the items you changed in 1) and 2) back to their original settings to avoid excessive logging.

Hopefully this will give me the information to stop those log messages appearing as they indicate some sort of issue with that plugin that I have not managed to reproduce on my test system.

 

I also notice that Fix Common Problems is reporting some issues with the scheduling options for the CA Update plugin - not sure what but probably worth looking at.

8 minutes ago, itimpi said:

Cannot see any obvious reason why the files are only going to the first drive   Maybe somebody else will spot something  just as a check are you sure you are. Opting the files to the User Share and not explicitly to disk1?

 

on a completely different issue I can see entries in your syslog of the form:

/usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

is there any chance you could do the following for me:

1. enable the Testing mode of logging in the settings for the Parity Check Tuning plugin
2. go to Tools->PHP Settings and set the Error Reporting Level to All
3. let the system run for a while until the plugin’s Monitor task runs again.
4. let me have new diagnostics at that point and also any entries in the PHP logs that reference the plugin.
5. set the items you changed in 1) and 2) back to their original settings to avoid excessive logging.

Hopefully this will give me the information to stop those log messages appearing as they indicate some sort of issue with that plugin that I have not managed to reproduce on my test system.

 

I also notice that Fix Common Problems is reporting some issues with the scheduling options for the CA Update plugin - not sure what but probably worth looking at.

Thanks for info and advice.  

 

global share setting look ok to me

 

I have made the two changes and will send the new diagnostics in a few mins. 

 

defiant-diagnostics-20230617-1337.zip

 

@itimpi new diagnostics. Hopefully it has the info you need.

Just now, mayberts said:

defiant-diagnostics-20230617-1337.zip 222.73 kB · 0 downloads

 

@itimpi new diagnostics. Hopefully it has the info you need.

That is useful, but does not quite pin things down.   There may be an entry in the PHP log that gives a specific line number in the source so any chance of checking for that?

PHPlog.txt

is this what you after? I saved it as .txt

Just to make sure you are writing directly to the user share, not a disk share, right?

1 hour ago, JorgeB said:

Just to make sure you are writing directly to the user share, not a disk share, right?

How can I be sure? From this screenshot I would say it's a user share. It's the media share in question

 

2 hours ago, mayberts said:

PHPlog.txt 14.86 kB · 1 download

is this what you after? I saved it as .txt

Thanks - exactly what I needed.   It shows an error in some code that is triggered if you manually pause a running manual check and I can see a typo on the line indicated.   Ironically it is just attempting to add to the log a message that says it had detected that manual pause   I now know how to recreate the issue so I can test out the fix, and I will issue a fixed version of the plugin either later today or some time tomorrow.  
 

 I am also going to see if I can incorporate a request to only issue a pause on manual checks and start running in increments if either you a manual pause has been issued or the check had reached the time the that the increment is scheduled for.    Thinking about it this is unlikely to break things for anyone else.   Funnily enough the actual line that caused the problem above is where I would have to make a change relating to this anyway  

29 minutes ago, mayberts said:

From this screenshot I would say it's a user share. It's the media share in question

Where are you writing to? Is it over SMB or locally? And in any case post the path you are using, like //tower/media or /mnt/user/media

It's all local. if I look at Sonarr for instance, the path variable it `/mnt/disk1/media/tv/`

 

haha I think I see my error. I need to change Sonarr from `/mnt/disk1/media/tv/` to `/mnt/user/media/tv/`?

 

If so, how will that affect the data on disk1?

Edited June 17, 20233 yr by mayberts

1 minute ago, mayberts said:

haha I think I see my error. I need to change Sonarr from `/mnt/disk1/media/tv/` to `/mnt/user/media/tv/`?

Yep

Thanks @JorgeB and @itimpiI feel like an idiot, not once did I think to check Docker containers.

58 minutes ago, mayberts said:

If so, how will that affect the data on disk1?

It will not affect it at all.   Unraid does not move data between array drives by itself.