Custom Query (2447 matches)

One of the things that has always bugged me about the help output for deluge was the fact that the UI options were never spelled out. It looks like r4179 adds the UI options, but at a bare minimum. You will find attached a diff containing a fuller breakdown of the UI options. I tried to include a brief description of each option, however, I couldn't play with the 'null' option.

You will also notice that the end of the lines for each of the UI help options is padded with spaces. Due to the fact that my python coding skills are so beginner, this was the only way that I was able to get the format correct. If you have a better solution, I would be glad to hear it and implement it.

The diff has been made against the latest code from svn.

After pulling down and building the latest version from svn of deluge, I found that starting the app in classic_mode (without any configuration data present) caused the UI to appear, but not be completely instantiated. I was able to trace the problem down to the connectionmanager class and, more specifically, the get_localhost_auth_uri() method at line 159. The problem appears to be linked to the fact that, if the config-area file, 'auth', hadn't been created, then the get_localhost_auth_uri() will continually loop (which is bad). Therefore, the attached diff seeks to remedy this situation. More specifically, it seeks to take care of the three cases I thought were probable:
1) The 'auth' files doesn't exist and the UI is started in 'classic_mode'.
2) The 'auth' file exists, the UI is started in 'classic_mode', but the 'auth' file doesn't contain the 'localclient' username.
3) The 'auth' file exists, the UI is started in 'classic_mode', and the 'localclient' username exists.

Since the third case is clean sailing, I won't touch on it.

As regards the first case, the modification of the common file method, get_localhost_auth_uri(), sees if the 'auth' file exists, creates it if it doesn't (through a call to the authmanager start() method), and continues on. I also modified the URI string assemblage to make sure that the user is connecting from '127.0.0.1' (just to be on the safe side).

For the second case, I added the check of the returned URI in the connectionmanager so that, if the 'localclient' authorization wasn't found (i.e., the 'auth' file exists, but the username, 'localclient' isn't in it), the UI wouldn't just be left hanging forever (as happened with me) and would notify the user forthwith. Perhaps an exception isn't the best way to handle it (now that I think about it, perhaps an error message and app shutdown would have been better), but (from my standpoint) an exception is always the best way to get me attention. Also, you may want to make the same check within the 'autostart_localhost' block in order to guard against the UI hanging due to a faulty/missing 'auth' file (I didn't do this because it's late, and I'm tired).

BTW, if you should decide to keep the URI check with user notification of the problem (which I think would be good thing), you might want to put something up on the FAQ about how to fix it. That way, if the user should get the error-message, "Could not locate localclient authorization" (or a message like it), they would know how to fix it. Just my .02.

As before, the diff has been made against the latest svn code.

If you have a recheck running, and you close deluge, it stops the recheck. Thats fine.

But, when you start deluge again, it assumes that the recheck was completed, and starts downloading the file at the point where the recheck left off. Thus, if you have 3/4 of the file downloaded, and the recheck only completes 1/3 of the file, then next time you start deluge, it will think you only have 1/4 of the file (1/3 of 1/4)

I think that is what is happening, though, my math may be off. Regardless, deluge should finish rechecks when it is next started, instead of just leaving them unfinished.