PDA

View Full Version : Small addition to Schedule (tiny)


logos
12-07-2001, 07:39 AM
Would it be possible to enhance the scheduler so that it could be programmed to resume downloading/uploading queues with the schedule being to transfer only during out of work hours for example, so it would stop downloading during work hours + start again the next day/weekend until the queue was done?

Its a really simple change i think and would make for a far more versatile scheduler (sorta like a VCR i guess, in a way).

Thanks

Fusion
12-07-2001, 07:43 AM
Can't you just have it start at 1700 and end at 0800, or whichever time-frame suits your needs? That is what you're asking? Only now it doesn't repeat, it's a run-once thing. Maybe you want to be able to define what days it should be in effect too, so that it'll remain online during the weekends. Heh, that's lazy, even by my standards. :)

logos
12-07-2001, 07:54 AM
no point having a tool if u work for it is there?, besides it sits on a machine far, far away and its either i find a commercial solution or i wind up writing a client that will do it.

Fusion
12-07-2001, 07:58 AM
Hey, it's a good idea, but let's see what bigstar says.

bigstar
12-07-2001, 05:06 PM
If you need to transfer a queue at a specific time or multiple times, the best way is to use the build in windows schedule.

The reason i suggest the windows schedule is because it's always running where as FlashFXP isn't.

logos
12-07-2001, 05:22 PM
OK, i can see how that would work for starting a queue running, but what about stopping it again? (without just running the process down with a murderous intent @ 0800 every day) :)

logos
12-07-2001, 05:28 PM
screw it, 5 minutes with toolhelp API and its a goner, ok thx then m8 (although i still think its a good idea)

Fusion
12-07-2001, 05:58 PM
With the scheduler you can decide when to start the app and how long it should be allowed to run before it's killed. Not sure how friendly that kill is opposed to ffxp killing itself, but if the big man says it's fine, it probably is.

logos
12-07-2001, 08:14 PM
and your positive that Flash actually works with Scheduler?, cos on 2k Server, i can't get it to actually download the queue, i can see the process running, but it doesn't bother to do anything (no files appear, no tcp traffic out from it, etc.)

Linkster
12-07-2001, 08:40 PM
I do have to agree with logos that start and stop/and restart capability in the scheduler would be really nice :)

Fusion
12-08-2001, 10:08 AM
Yea, but as bigstar said it makes more sense to use the scheduler. Keeping an idle program up for hors is resource-ineffective. :)

logos
12-08-2001, 10:48 AM
don't be silly.

Shark
12-08-2001, 06:22 PM
I personally I doubt i'd use the feature. But I also do not see a problem in FlashFXP running.... it uses piss all resources.

And if your going to download, you usually have it open anyways.

Shark.

bigstar
12-08-2001, 08:21 PM
Well I didn't say that.. Just that the build in windows schedule does everything one could imagine when it comes to scheduling, I've never personally used it for FlashFXP. As i've never needed to schedule a download on my 33.6 dialup connection. I see your point about stopping the transfer. That could pose a problem.

To create a full featured schedule would take alot of time and energy, Something I have very little of lately. If I were to create a full featured schedule it would be external, Run FlashFXP via the command line and perhaps send special a Window Message to stop the transfer and exit FlashFXP. I will add it to the list of things to do..

If someone is interested in creating an external schedule for FlashFXP I'll add some Window Message events that will allow FlashFXP to gacefully close when the time limit has been reached, Or perhaps even changing the speed limit depending on the time of day.

logos
10-07-2002, 02:59 PM
If someone is interested in creating an external schedule for FlashFXP I'll add some Window Message events that will allow FlashFXP to gacefully close when the time limit has been reached, Or perhaps even changing the speed limit depending on the time of day.

did u ever get around to doing this?

bigstar
10-07-2002, 04:20 PM
Originally posted by logos
did u ever get around to doing this?

Nope, no one was interested.

logos
10-07-2002, 04:59 PM
I never noticed your reply offering it or i would have expressed an interest, sorry :\ (i have no idea why i never saw it tbh, think i musta wandered off).

Would be a handy control system for creating a customisable 'batch' tool as well.

If u were to implement it i would certainly be quite happy to write a scheduling control system around it + publish it.

/me hits subscribe this time :\

bigstar
10-07-2002, 07:27 PM
Well right now my life is quite full, I'm not sure when I'll find time to work on expanding the schedule.

Everything will be done via window messaging.

IF you could come up with a list of things you'd need/want to be able to do. Perhaps even specifics of how you think it should be done. I know people may want total control but that's just not pratical.

logos
10-08-2002, 08:57 AM
well really, for me personally and integrating a few ideas for further scheduling requests i think it could be done pretty simply with a few basic commands.

Basics

Queue Begin, inputs: none, returns: fail/success (begins processing the current queue, like the scheduler had started it the same as it does atm)
Queue Halt, inputs: none, returns: fail/success (...)

Upstream Rate, inputs: kbytes/sec ceiling (0 being infinite), returns: fail/success (set upstream ceiling, should be able to do it no matter what state client is in)
Downstream Rate, inputs: kbytes/sec ceiling (0 being infinite), returns: fail/success (...)

Terminate, inputs: +hangup/turnoff/logoff, returns: fail/success (graceful termination of FlashFXP)

Not really required, but could be handy given some of the other requests i see in the forums atm.

Other

Queue Save, inputs: filename - forced overwrite (Y/N), returns:fail/success (overwrites file saving all state queues save atm)
Queue Load, inputs: filename, returns:fail/success (overwrites current queue and idles)

Status Command

Able to retrieve,

Status, input: none, return: Idle/Queue Complete/Queue Failed/Working
BitCount Down, input: none, return: current bit count (basically a counter on how much has been downloaded since init)
BitCount Up, input: none, return: current bit count (...)

I _think_ that would be enough to provide for quite powerful control options, although i've only given this some brief thought atm. Whaddya think?