Jump to content
Division-M Community
Sign in to follow this  
The-Priest

Bug?:Sickbeard move file to pool doesn't update "modify date+time" on directory.

Recommended Posts

Hi There,

 

Just started using Drive Bender (trial mode for now) but i'm running into a snag with my automation proces.

I'll try to write it out as understandable as i can but if you need more info please ask.

 

My setup is the following:

 

SABnzbd, Sickbeard, Couchpotato and Plex Media server all installed on C:\ (physical disk outside off pool)

SABnzbd complete and incomplete folder on D:\Downloads\ (this is the pool)

Final folder D:\Series\$series\$season#

 

The proces on my machine is as follows:

 

[*]Sickbeard sends a NZB to SABnzbd.

[*]SABnzbd downloads,checks and unpacks and then sends it back to Sickbeard for post processing.

[*]Sickbeard renames the file and moves it to the final folder and then notify's Plex media server to run a library update.

 

The problem i'm running into:

 

In the final step (3) when sickbeard moves the file to D:\Series\$Series\$season# the modify date+time doesn't get updated on the $season# directory, and when the Plex media server runs the media scanner it checks the mtime of the folder to see if it needs updating.

 

Here is the quote from the Plex wiki regarding mtime:

 

Turbo Scan - This is the default scan and is designed to be the quickest. It does this by looking at the "modified time" (mtime) for a directory in the specified content location. If the mtime is not newer than the last scan, that directory and all content inside it is skipped in order to save time. Occasionally, this can cause issues for some people if their storage device/OS does not update the directory mtime when something inside it is added/removed/modified.

 

What did i test to fix the problem?

[*]Complete fresh install of my HTPC (where everything runs) since i also tried some other drive pooling apps, this didn't help.

 

[*]Checked to see what happend when i put a new file inside the $season# directory myself, now it did update mtime, so i started to suspect sickbeard.

 

[*]Installed SABnzbd and Sickbeard on another pc with the same config and directory setup but without DB and was expecting the same problem if it was due to Sickbeard, but the problem doesn't occur then. mtime get's updated to the date+time Sickbeard places the file in the $season# directory

 

[*]Went back to the HTPC and to the DB pool and under options enabled "map pooled drive to mounts folder" and browsed to the physical drive where the last added episode was, and sure thing the $season# had the correct mtime, but if i go to the drive to wich the pool is mapped (D:\) there is a much older date (please see the added screenshots)

 

My conclusion for now:

 

Somehow DB doesn't always update the mtime used in the pool to the mtime the corresponding directory on the physical drive has.

 

I'm not sure it's really a DB bug/problem or if it's somehow also connected to sickbeard but i'm wondering if someone else has also seen this behavior that has almost the same setup as mine?

 

System Specs:

 

Asus E35M1-M Pro

4Gb DDR3

Intel 320 40Gb SSD (C:\)

1 Storage Pool (D:\) consisting of:

Samsung HD204UI 2TB (1x)

Samsung HD154UI 1,5 TB (2x)

Samsung HD103SJ 1 TB (1x)

WDC WD10EACS 1Tb (1x)

 

Software:

Windows 7 Professional x64

Drive Bender 1.2.2.2

SABnzbd 0.6.14

Sickbeard 491

Plex Media Server 0.9.5.2

 

Edit 1 20-12-2011:

 

Problem seems intermittend, last night everything went okay, but as a test i put a new file in a random $season# directory (over the network not on the HTPC itself) and the mtime didn't update.

 

Went thru the physical disks to see on what drive  the file ended up. On the drive where the file was placed the mtime was updated to the correct date+time but i did notice the following.

 

On the other drives that also have the same $season# directory the mtime is not updated, this seems logical to me because on that physical disk nothing changed so mtime doesn't get updated.

 

But this also lets me conclude that somehow DB doesn't always show the correct mtime because it gets it mtime info from the wrong physical drive.

 

Example:

DB1 mtime = 5-12-11 0:20

DB2 mtime = 5-12-11 0:20

DB3 mtime = 5-12-11 0:20

DB4 mtime = 5-12-11 0:20

DB5 mtime = 20-12-11 13:45

 

Pool mtime = 5-12-11 0:20

 

The above example isn't alwys the case wich makes it hard to figure out exactly where it goes wrong.

 

I'll see if i can find something in logfiles (if DB logs every action)

 

Will get back to this when i get home from work.

post-2057-138978188634_thumb.png

post-2057-138978188635_thumb.png

Share this post


Link to post
Share on other sites

Welcome to the forums The-Priest, and a nice first post  8)

 

This has been raised before, as Media Browser uses a similar routine as your software.

 

Hopefully v1.3 will address this.

 

In the meantime, you could raise a Support Ticket just so it is raised with the techies.

 

 

 

 

Share this post


Link to post
Share on other sites

Done  :)

 

And i like to be thorough if i post something  ;D

 

I did search the forum for problems regarding modify dates, and did read read the topic you are referring to (i think) but i thought that problem had more to do with connecting to the pool over a network, and that when you switched to running everything on the same machine you didn't have problems.

 

Ahh well if it's a known problem let's hope 1.3 solves it.

Share this post


Link to post
Share on other sites

Is there some info on how to read the *.sil files?

 

troubleshooting tonight but other than the fact that sometimes the correct and sometimes the incorrect mtime is displayed and totally random is all im getting so far  >:(

 

some other usefull info might be is:

 

File duplication = Nope

File balancing = Yep

Share this post


Link to post
Share on other sites

  I'm running Sickbeard, Sabnzbd, Couchpotato, Media Browser (running as service except Media Browser) and I don't see the problem. I know you don't want to see another "works fine here" reply but there's more to it. I have a drive outside of the pool used as a 'landing zone' that Sab downloads to and the files are written to the pool during post processing as they are renamed etc. This cuts down on reads and writes to the pool that are constantly changing and seems to work fine. Try setting your download path to a non pooled drive and copying during the rename stage, see if that helps.

Share this post


Link to post
Share on other sites

  I'm running Sickbeard, Sabnzbd, Couchpotato, Media Browser (running as service except Media Browser) and I don't see the problem. I know you don't want to see another "works fine here" reply but there's more to it. I have a drive outside of the pool used as a 'landing zone' that Sab downloads to and the files are written to the pool during post processing as they are renamed etc. This cuts down on reads and writes to the pool that are constantly changing and seems to work fine. Try setting your download path to a non pooled drive and copying during the rename stage, see if that helps.

 

Tried that also but it doesn't help.

Even when i place a single 1 kb text file while nothing else is going on in the pool (except maybe actions DB does by itself) i see this behavior.

 

Tonight i'll try running a batch file that moves text files from my C:\ to the pool  and the same batch file to move files inside the pool while i have logging set to medium and see if i can make some sense of it.

 

Thanks all for the suggestions and tips.

Share this post


Link to post
Share on other sites

Okay did some more testing by using the following method.

 

Created 4 batch files: (files attached)

 

test_copy.cmd (copy files from c:\software\test\$filename#.txt to d:\series\$serie\$season#\ with a pause of 60sec between each copy)

del_files.cmd (delete the files from d:\series\$serie\$season#\ that were placed by the copy)

test_move_to.cmd (move files from c:\software\test\$filename#.txt to d:\series\$serie\$season#\with a pause of 60sec between each move)

test_move_from.cmd (move files from d:\series\$serie\$season#\ to c:\software\test\$filename#.txt)

 

If i run test_copy.cmd and test_move_to.cmd on my normal computer (no DB) i get the result in the screenshot below

 

no_db_1.png

 

To make a long story short, each modified date of a directory is 1 minute newer. (this is the result i expected)

 

If i run del_files.cmd and test_move_from.cmd on my normal computer (no DB) i get the result in the screenshot below.

no_db_2.png

 

To make a long story short, each modified date of a directory is the date and time the files got deleted or moved back to c:\software\test\ (this is the result i expected)

 

Now if i run the same batch files on the HTPC (with DB where the D:\ is the pool) the results are as follows:

 

First the starting point of the directory modified date and time.

 

start_situation.png

 

In all cases it's 20-12-2011 21:30

 

Running test_copy.cmd the following is displayed after the batch file completes and i refreshed (F5) my explorer window.

 

after_copy_to_pool.png

 

The first copy action gets the modified date and time the file was copied to the directory, BUT every copy after that gets a modified date and time that is the same as the modified date and time of the file itself and this is not the behavior we see if DB isn't involved.

 

Okay next batch file, del_files.cmd and again a refresh (F5) in explorer.

 

after_delete_from_pool.png

 

Now the result should be that the modified date and time of the directory's is the same again, instead nothing changed. This is again not the behavior we see if DB isn't involved.

 

Running test_move_to.cmd and test_move_from.cmd results in the same behavior, but i'll let the screenshots talk for itself.

 

after_move_to_pool.png

 

after_move_from_pool.png

 

This leads me to believe that somehow DB looks at the wrong physical drives to determine the modified date and time of a directory. I also suggested this in the support ticket i made and this is the reply i got from Mrsmith (i hope this is allowed.)

 

First the fact that one of the drives folder has a different time stamp is odd... my first though is something else is modifying the time stamp. The other thing to note is DB will always pull the time stamp from the master node (the first drive in the pool), so this should not be changing unless each folder on each drive changes. Also please ensure that there are no Windows drive letter mapped to any of the physical hard drives in the pool, or that the "Map pooled drives" option is not set in the Drive Bender options. If Windows has access to any of the drives (outside of the pool), there can be issues.

 

Now what i find puzzeling in this reply is this part:

 

The other thing to note is DB will always pull the time stamp from the master node (the first drive in the pool), so this should not be changing unless each folder on each drive changes.

 

The way i read this is that: "unless there is a new file in the same directory on all the physical disks that the pool consists of, the modified date and time will not be updated on the master node and thus not be shown in explorer if you look at the pool drive" But this is not the behavior i'm seeing with the tests i did so my interpetation might be wrong?

 

Have any of you got an idea why this is happening or what i could look into to maybe nail it down a little more?

 

p.s. sorry for the wall of text and pictures  :-[

 

Edit 1:

 

Hmm been going thru the sil file but on the medium setting you can't see the drive/mountpoint the file is created on.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...