Jump to content
Division-M Community

The-Priest

Members
  • Content Count

    6
  • Joined

  • Last visited

  1. Did you have time to test? maybe even with the batchfiles i supplied? I'm wondering what results you get
  2. 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 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. 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. 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. 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. 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. 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.) Now what i find puzzeling in this reply is this part: 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.
  3. 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.
  4. 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
  5. Done And i like to be thorough if i post something 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.
  6. 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: 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.
×
×
  • Create New...