Flood could use better feature detection

[afontenot]

Since Flood is supposed to be compatible with many different clients, including vanilla rtorrent, it would be useful to come up with some way of doing feature detection.

For example:

• When an rtorrent client is connected, Flood surfaces a "Sequential Download" feature in the Add Torrent modal. This setting is a no-op unless you happen to be using jesec's fork of rtorrent and libtorrent. I'd argue that surfacing the feature at all is misleading, as casual users have no way of knowing that this is not a feature available in vanilla rtorrent. (I assume / hope that supporting vanilla rtorrent will continue to be important to the Flood project.)

• Maybe the debs enforce this (for users on Debian), but users installing from source or otherwise may or may not have mediainfo installed. The mediainfo button could be removed if Flood is unable to find mediainfo.

• Feature detection is really the ideal solution to the problem presented here. The real issue is that several features break if Flood is not on the same platform (with the same /path/to/file) as rtorrent (with the same access permissions as rtorrent as well). But there's no reason for this, as these features are totally optional. Just hide them (with a warning dialogue to the user during the initial setup) if Flood is being run in a non-standard configuration.

Edited to add: I think that this fork of Flood requires a directory to put the .torrent in that rtorrent can pull from. This used not to be the case with the old version. One barrier to implementing the third suggestion above (allowing Flood to run as an isolated user or on a different system entirely) is that the old way of doing it would need to be restored as a fallback method in case of a non-standard installation. (Doesn't network.xmlrpc.size_limit.set get rid of the RPC payload limit anyway?)

[jesec]

It is on the roadmap: https://github.com/jesec/flood/projects/5#card-50707873.

Note that it is not relevant to the unsupported case where Flood and torrent client are deployed on Linux and Windows respectively. There are clear distinction between unsupported cases and supported cases.

[afontenot]

Good to know, thanks! (You're using so many new / obscure Github features, I didn't realize there was a roadmap either. Would have linked it here if I had known about it.)

I think that user makes a pretty good point, though, that the only reason it's not supported is that it breaks several expectations and (if you removed the check) a few features would break as a result. With feature detection there's no reason not to allow users to set things up this way if they like, even if it's clearly suboptimal. I think it makes sense to try to support the broadest array of setups as possible.

[jesec]

It is not about any check. It is about the different behaviors of path expansion function on different platforms.

[afontenot]

So the thing where I can't create a user in Flood while running it under a different (unix) user than rtorrent because of a "verification failure" is a different issue than what that user meant by a path check? Should I file a different issue for this?

[jesec]

No. There is no such check. It is more likely a plain filesystem permission trouble, which is your problem.

[afontenot]

That's certainly what it is. But previous versions of Flood didn't check for filesystem permissions before letting you add a user, they just failed silently (e.g. when trying to delete a file), which was preferable to me.

Edit: I'm talking about "Connection could not be verified." It's frankly a terrible error message, as the user is given zero help in figuring out what it means. (To me, "verify" suggests that the initial connection with rtorrent succeeds, but then some kind of "verification" is done to make sure Flood has a working connection.) I found that the issue went away when I ran Flood under the same user as rtorrent, so I'm mostly working on the assumption (since the error message is unclear) that Flood is trying to verify that it has the necessary permissions. I haven't tried reading the code to check this, but then again as a user the error message should be clear enough that I don't have to. It's possible I misunderstood this error, but if so it's because the language took me down the wrong path.

If it's not reasonable to try to work out exactly what went wrong and present that to the user, I suggest at least changing it to "Connection failed" which is at least explicit that something the user did is probably wrong, instead of suggesting that Flood isn't happy about something.