Immediate crash: EpisodeFileMovingService: Unable to set last write time

Hello,

Running under Debian Linux, ND ver. 2.0.0.1632. For the past week or so, ND crashes right after starting. The complete log:

[Info] Bootstrap: Starting NzbDrone - /opt/NzbDrone/NzbDrone.exe - Version 2.0.0.1632                                                      [Info] MigrationLogger: *** Migrating data source=/home/nzb/.config/NzbDrone/nzbdrone.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal ***
[Info] MigrationLogger: *** Migrating data source=/home/nzb/.config/NzbDrone/logs.db;cache size=-10485760;datetimekind=Utc;journal mode=Wal ***
[Info] Router: Application mode: Interactive
[Info] OwinHostController: Listening on the following URLs:
[Info] OwinHostController:   http://*:8989/
[Info] NancyBootstrapper: Starting NzbDrone API
[Warn] EpisodeFileMovingService: Unable to set last write time

System.IO.IOException: Invalid parameter
  at System.IO.File.SetLastWriteTime (System.String path, DateTime lastWriteTime) [0x00000] in <filename unknown>:0
  at System.IO.Directory.SetLastWriteTime (System.String path, DateTime lastWriteTime) [0x00000] in <filename unknown>:0
  at System.IO.Directory.SetLastWriteTimeUtc (System.String path, DateTime lastWriteTimeUtc) [0x00000] in <filename unknown>:0
  at NzbDrone.Common.Disk.DiskProviderBase.FolderSetLastWriteTimeUtc (System.String path, DateTime dateTime) [0x00000] in <filename unknown>:0
  at NzbDrone.Core.MediaFiles.EpisodeFileMovingService.TransferFile (NzbDrone.Core.MediaFiles.EpisodeFile episodeFile, NzbDrone.Core.Tv.Series series, System.Collections.Generic.List`1 episodes, System.String destinationFilename, Boolean copyOnly) [0x00000] in <filename unknown>:0

Stacktrace:

The stacktrace is empty. May have started after an update, can’t say for certain. Any ideas?

Please tell me it’s reproducible! Don’t do anything, we need to debug this one.

I’m at work atm, so don’t have time to write out the required commands. should be something like:
mono --debug --trace=T:System.IO.File /var..../nzbDrone.exe

Unfortunately it is reproducible. It happens every time I start ND. I’m not home either, will wait for debug instructions.

Been thinking about this one. It most likely has something to do with permission issues on that folder.
Edit the ~/.config/NzbDrone/config.xml file and set loglevel to Trace.
If you run drone again the log will now contain more details about which folder it’s trying to set the date for. Which you should check (for the user that runs drone, of course).

If that doesn’t help:
Running mono --debug --trace=T:System.IO.File /var/NzbDrone/NzbDrone.exe (under the correct user account) should output details about those method calls. (and a bunch of other stuff)
What I’m concerned about is that it’s trying to set the folder date to an invalid value. I want to know what value that is. Not sure if the trace is gonna output it, but it’s worth a shot.

Which folder? I guess it’s NZBGet download folder. This shouldn’t happen as NG and ND run under the same useraccount and the filemask gives any newly created file full permissions for the owner, but I’ve repaired an archive manually there as the root user, so some of the files there would have root as their owner.

I’ve ran ND again last night (just a bit before your last reply, damn…) with the debug switches, with the output redirected to a file. This time ND did not crash. Hmm. I also emptied NG destination folder from all of the leftover files - I remember doing this after starting ND, but I could be mistaken. So if it was a file permissios problem and I’ve erased those files prior to starting ND, this could explain why it is running properly now.

Thanks!

It’s about the destination series folder. With Log Level to Trace the log file would contain the path that it’s trying to set the lastwritetime for.

Right, it happened again. It was reproducible, so I have a debug log (over 300KB of it, too large for pastebin). I ran ‘aptitude update’ and got a new version of mono - 3.2.8 - and on a subsequent run, ND did not carsh. So either it does not happen with the new mono version or the two previous crashes had already handled the two new downloaded episodes - I’ll know which is true on Monday, when a new episode is scheduled to be downloaded. IN the meantime, the debg log can be found here:

http://filebin.ca/1TpkFCS31kLl/log.txt

Which version of mono did you have previously?

Errr… not 3.2.8. No idea.

I think it was 2.something. Anyway, it’s Monday, a new episode have been downloaded and ND did not crash. I guess the problem is solved.