Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Morse]

And again I am going to ask the possibility to switch off the core without actually shutting it down. Although Kry already told once that he "doesnt see the point of making the option 'not to down-/up- load' for the app the sole purpose of which is down-/-up load" (do not remember where), but I still think that at least for amuled it's a good idea.

Now, I'm faced with the problem to teach my mother to use several p2p clients. And if amuleGUI is something she can comprehend, ssh console and other stuff is far from that. Not to say that i DO NOT want to give her sudo privileges.

There are some reasons why i don't want always to run amuled with 1/1 limits, most important being the shitting in NAT port forwarding table and ntop statistics.

Finally, if you decide that this is something that shouldn't be implemented, than may be you just will do automatic setting of limits to minimum values on hitting the "disconnect" button (with automatic restore on "connect" of course).

[Stu Redman]

Kry has a point here (tautology or not).

Finally, if you decide that this is something that shouldn't be implemented, than may be you just will do automatic setting of limits to minimum values on hitting the "disconnect" button (with automatic restore on "connect" of course).

You can accomplish that yourself by calling amulegui from a batch sandwiched between two calls to amulecmd setting the bandwidth limits to whatever you like. (Not below 1k/s however.)

Oh, and P2P apps are not exactly what I'd give innocent mothers to play with... 

[Morse]

You can accomplish that yourself by calling amulegui from a batch sandwiched between two calls to amulecmd setting the bandwidth limits to whatever you like. (Not below 1k/s however.)

No, i can't. I don't want to disconnect/reset limits every time amuleGUI is disconnected. I want to make "almost shut down"-state easier accessible.

[Stu Redman]

(moved this to feature requests where it belongs)

OK, I misunderstood you. Hm. So you don't want the sleeping period related to activity of amulegui. But you still can set it through amulecmd - same way you would trigger your "core inactivity" feature. SO I really don't see the point.

[Vollstrecker]

You remember the othher thread about the long shutdown? If you need your resources for an hour or so, it would be easier to just tell the core "go for breakfast, till I call you" instead of letting it all write to disk, just to read it all back an hour later.

[Stu Redman]

just tell the core "go for breakfast, till I call you

Isn't that exactly what capping the rates to 1k/s does?

[Vollstrecker]

1 > 0 isn't it. Plus overhead.

[Stu Redman]

OK. Not exactly of course, but for all practical purpose.
And I'd rather get to the source of the problem of the long shutdown than make a messy workaround.

[Morse]

actually even 1/1 is good enough if there was an easy option of reducing/restoring speed if not in one, then at least in two-three clicks. For now the only way is to call an option window and type the needed values by hand both for reducing and restoring. For instance toggable tray icon context menu item "reduce to minimum", that can be switched on and off.

[Vollstrecker]

I've been thinking about an option to toogle bw-limit on/off some time ago. Maybe this would be a solution. Setting limits to 1/1 (or whatever else someone wants), and then just a button switching between fullspeed and limited. Maybe in addition something like "amulecmd -c toogle bw-limit on"

[Stu Redman]

If you are using amulecmd anyway you can already do it, so I don't see an advantage.

[Vollstrecker]

I thought about an gui option, and as it makes sense to include it in remotegui and web, too, there'll be an handler in the ec-code anyways, so it's just logical to make in useable in cmd, too.

[Stu Redman]

So you need settings dialog for "alternate" up/down speed, and a "convenient" place in the gui to toggle them.
I'd say this clutters up the interface and increases the risk of misbehavior due to erroneous configuration. I'm against that.

[Vollstrecker]

No alternative. The settings as they are, and somewhere on the downloads page, or beside the connections globe say on or off. It's just a switch deciding if the usual bw-limits are applied or ignored.

[Stu Redman]

This is wrong in many ways.
- Whenever somebody whines "aMule is not downloading!!!" we will have to ask "did you accidentally click on that 'off'-thingy in the status line?". I don't need that, thank you.
- People will still queue up at you. Since the number of sources they ask is limited, their chance of downloading (and then sharing) is diminished with a dud source like you. So it hurts the network.
- You clutter up other Kad nodes publishing files you don't actually share.

Kry already told once that he "doesnt see the point of making the option 'not to down-/up- load' for the app the sole purpose of which is down-/-up load"

This sums it up pretty well.

Shut down your core when you don't want it to be active, and be done with it.