Former volume not mounted (continued?)

[console.cowboy]

This is my .log:

[20160505 23:16:33] GetNodeID failed, using /dev/random
...
[20160505 23:16:33] IPv6 is installed
[20160505 23:17:05] File not found during integrity check: /opt/utorrent//webcache.dat
[20160505 23:17:05] File not found during integrity check: /opt/utorrent//webcache.dat.new
[20160505 23:17:05] File not found during integrity check: /opt/utorrent//webcache.dat.old
...
[20160505 23:17:57] Error: <torrent name> - Former volume not mounted.
...
[20160505 23:18:57] ReadFile error: <file name>:661651456:214761:214761:3
...

I'm trying to save files over the network on a NFS drive from a ZFS root partition.  Local paths 'work' but obviously trigger some kind of ReadFile error.

Thoughts? Suggestions?

I don't know how to debug problems like these, but I'm willing to learn.

[mcdonald]

I encourage you to use a local disk for the location of your download directory.  Once uTorrent Server for Linux completes the download, you can then set up some sort of process to transfer the downloaded file(s) from the local disk to the eventual destination of a remote disk drive.  One option is to use the finish_cmd setting in the configuration file; see the docs in the downloaded archive for more information.  Whatever transfer program you invoked would need to monitor the transfer, retrying if necessary.

[console.cowboy]

See, I don't understand why no one wants to fix this problem... in the age of gigabit networks, clouds, servers, etc, I want to centralize my data.  I'm trying to download, use, and share bittorrent data from one place with different computers and protocols, all at the same time.

Of course 'I can' setup post download scripts to create checksums, copy data around, and then clean it up, but that is putting the burden on me, the user.

Thing is, if I wanted to do that, I wouldn't be asking this question.

If there was some official documentation that says "utorrent-server can only download data to a local system path", sure, I get it, but this is something I was already doing for a couple years.

If this was an open source project on github I'd gladly compile a version of the project and see for myself what is going on.

I like the utorrent-server app.  I like being able to add a torrent of anything from anywhere onto a remote server.  I just assumed saving data across networks was considered an important feature.

[mcdonald]

Based on what I recall, we have placed a higher priority on download speed and reliability.  We have found downloads to be fastest and most reliable when the files being downloaded are stored on a drive local to the computer performing the download.  Also, computers running our BitTorrent clients often have enough to handle supporting file transfers without also adding the job of simultaneously transferring downloaded data to a networked drive; this is especially true of embedded devices running our clients.  There might not be official documentation describing this priority choice.

I suspect a number of us do not want to officially support direct writes from client to networked drive, because then we'd need to take on the cost of testing that, and handling error cases by retrying/resuming, which could add a lot of work to an already-busy engineering organization.  That's probably at least one reason we've added the feature of being able to run a program upon torrent file set download completion so at least users can set up the file transfers themselves.

[JeffJolley]

console.cowboy-

Did you ever get an answer to this? I have the same need/issue.

Edit: I might add that I have been doing this for years with the uTorrent Windows client and my Lacie NAS. Worked great. I decided to switch to a linux based server and was disappointed to find I can't do the same thing.