php-general Digest 16 Nov 2009 02:41:54 -0000 Issue 6444

Topics (messages 299841 through 299858):

Shoutbox suggestion needed
        299841 by: Cemal Eker

Re: is Aptana taking a crap on the face of PHP?
        299842 by: Andy Shellam (Mailing Lists)

Developer needed in Rome, Italy
        299843 by: intelllimike.gmail.com

fread() memory problems
        299844 by: Ashley Sheridan

mail mimedecode with multiple mails in one mbox file
        299845 by: Ashley Sheridan
        299846 by: Per Jessen
        299847 by: Ashley Sheridan
        299858 by: Manuel Lemos

this has got me baffled: imagesx() and imagesy() reporting the wrong size?
        299848 by: Ben
        299849 by: Ashley Sheridan
        299852 by: Ben
        299856 by: Ashley Sheridan
        299857 by: Ben

Lightweight web server for Windows?
        299850 by: O. Lavell

Re: File To Blob Corruption
        299851 by: Nisse Engström

Help needed with calculation
        299853 by: Chris Payne
        299854 by: Ben
        299855 by: Adam Shannon

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
Hello,

I just want to implement a shoutbox script for an e-learning application.
Searched Google for possible solutions but I just want to know what other
developers use.

AJAX and GPL is a must.

Thanks.
---
“Talk is cheap. Show me the code” - Linus Torvalds

--- End Message ---
--- Begin Message ---
> 
> * It is FREE (unlike Zend's retarded $500 price tag).

I bought Zend Studio back in the 5.5 days - a couple of months after that they 
announced they were dropping support for the standalone IDE and made Studio an 
Eclipse plugin.  It was then they added about $200 to the price.

I moved to NuSphere PhpEd and was happy with that for a couple of years, now 
I'm on a Mac and haven't been able to find a decent IDE for either PHP or C++.

Apple's Xcode seems to do the job for C++ (although better code completion 
wouldn't go a miss) but it fails miserably with PHP.  Komodo was great for PHP 
but quite often it kept failing to load my class definitions for the code 
completion (and kept my processor sat at 25% use the whole time it was running.)

I thought NetBeans was Java-only (and proprietary) but evidently it's come a 
long way since I last looked at it - I'm just downloading it now to see if it 
will handle both PHP and C++.


--- End Message ---
--- Begin Message ---
Hi All,

I'm looking for a PHP MySQL JavaScript CSS HTML developer,
full time, in Rome, Italy.
Laurentina area.

Qualification is not compulsory (degree ... certification ...)
and can be first experience.

Ability to read English is a requirement
(so that the candidate can benefit studying real world documentation).

Example of previous jobs are welcome
even if they are amateur.

References are a plus.

Please contact me off-list.


Regards and have a nice evening,
Mike

--- End Message ---
--- Begin Message ---
I was just wondering why fread() seems to use so much memory when
reading in a file. My php.ini has a script memory limit of 32MB, yet PHP
hits its memory limit on a 19MB mbox file that I'm reading in. How is it
possible that this function can use 150% of a files' size in memory?!


Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
Hi all,

I'm having a bit of difficulty seeing my way through this. I think I'm
on the right path with mimeDecode, but I can't get it to read all of the
emails in an mbox file which contains 100 emails; it only reads the
first.

I've looked over the docs on pear.php.net, but can't seem to find any
way to get the other 99 emails out!

Does anyone know of any way to do this, or have you done something
similar another way? Just to clarify, I won't be connecting to an
external mailbox for this, so it has to be something I can use on a
local mbox file.

Ps, sorry to anyone who thinks bad of me for opening two threads at
once, but they are quite separate, and valid, and contrary to popular
belief, us men *can* actually multitask!


Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:

> Hi all,
> 
> I'm having a bit of difficulty seeing my way through this. I think I'm
> on the right path with mimeDecode, but I can't get it to read all of
> the emails in an mbox file which contains 100 emails; it only reads
> the first.
> 
> I've looked over the docs on pear.php.net, but can't seem to find any
> way to get the other 99 emails out!
> 
> Does anyone know of any way to do this, 

Look up "formail -s"


/Per

-- 
Per Jessen, Zürich (9.0°C)


--- End Message ---
--- Begin Message ---
On Sun, 2009-11-15 at 20:54 +0100, Per Jessen wrote:

> Ashley Sheridan wrote:
> 
> > Hi all,
> > 
> > I'm having a bit of difficulty seeing my way through this. I think I'm
> > on the right path with mimeDecode, but I can't get it to read all of
> > the emails in an mbox file which contains 100 emails; it only reads
> > the first.
> > 
> > I've looked over the docs on pear.php.net, but can't seem to find any
> > way to get the other 99 emails out!
> > 
> > Does anyone know of any way to do this, 
> 
> Look up "formail -s"
> 
> 
> /Per
> 
> -- 
> Per Jessen, Zürich (9.0°C)
> 
> 


Thanks, that's got me going in the right direction! There just seems to
be no end to what you can do on a Linux console does there?!

Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
Hello,

on 11/15/2009 05:22 PM Ashley Sheridan said the following:
> Hi all,
> 
> I'm having a bit of difficulty seeing my way through this. I think I'm
> on the right path with mimeDecode, but I can't get it to read all of the
> emails in an mbox file which contains 100 emails; it only reads the
> first.
> 
> I've looked over the docs on pear.php.net, but can't seem to find any
> way to get the other 99 emails out!
> 
> Does anyone know of any way to do this, or have you done something
> similar another way? Just to clarify, I won't be connecting to an
> external mailbox for this, so it has to be something I can use on a
> local mbox file.

The mbox format is not exactly compatible with the regular MIME message
format.

Anyway, you may use the MIME parser class which supports parsing single
MIME messages as well multi-message messages in the mbox format. Just
set the mbox class variable to 1.

http://www.phpclasses.org/mimeparser


-- 

Regards,
Manuel Lemos

Find and post PHP jobs
http://www.phpclasses.org/jobs/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

--- End Message ---
--- Begin Message --- On my site I have a web form for users to upload graphics, however there are constraints on the size allowed. Recently, a user has been having problems, because the code is reporting the wrong size - a size too small to be allowed! They sent me a copy of the image so I could confirm the error, and I have: even though the image is a 32x32 image (2-frame animated GIF, if it matters), imagesx() and imagesy() report that the image is 30x24! I have never had this problem before (or, at least, no one has reported it to me) so I'm tempted to think that it's a bug in PHP, or (more likely) I am missing something crucial...

The relevant code:

if($itype == 'image/gif')
  $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else if($itype == 'image/png' || $itype == 'image/x-png')
  $img = imagecreatefrompng($_FILES['file']['tmp_name']);

// note: we do not get here if($itype != 'image/gif' && $itype !=
// 'image/png' && $itype != 'image/x-png'), so the problem should not
// lie with an image type we were not expecting

$w = imagesx($img);
$h = imagesy($img);

if(!(($w == 48 && $h == 48) || ($w >= 4 && $w <= 48 && $h == 32)))
{
  $error = 'The graphic\'s dimensions are not correct (' .
           $w . 'x' . $h . ').';
}
else
{
  ...
}

yes, the logic wants either a 48x48 graphic, or a 4x32 to 48x32 graphic.

I'd be happy to link the animated GIF in question... just in case there was a problem with the GIF itself, I tried opening it up in an (old) version of Fireworks, and re-exporting it, but the problem remains.

besides the possibility of a bug in PHP, I'm wondering if I need to handle animated GIFs differently, or something like that? but again, this code has been running for... 3ish years without a problem like this ever being reported... quite confusing.
--- End Message ---
--- Begin Message ---
On Sun, 2009-11-15 at 15:07 -0500, Ben wrote:
> On my site I have a web form for users to upload graphics, however there 
> are constraints on the size allowed.  Recently, a user has been having 
> problems, because the code is reporting the wrong size - a size too 
> small to be allowed!  They sent me a copy of the image so I could 
> confirm the error, and I have: even though the image is a 32x32 image 
> (2-frame animated GIF, if it matters), imagesx() and imagesy() report 
> that the image is 30x24!  I have never had this problem before (or, at 
> least, no one has reported it to me) so I'm tempted to think that it's a 
> bug in PHP, or (more likely) I am missing something crucial...
> 
> The relevant code:
> 
> if($itype == 'image/gif')
>    $img = imagecreatefromgif($_FILES['file']['tmp_name']);
> else if($itype == 'image/png' || $itype == 'image/x-png')
>    $img = imagecreatefrompng($_FILES['file']['tmp_name']);
> 
> // note: we do not get here if($itype != 'image/gif' && $itype !=
> // 'image/png' && $itype != 'image/x-png'), so the problem should not
> // lie with an image type we were not expecting
> 
> $w = imagesx($img);
> $h = imagesy($img);
> 
> if(!(($w == 48 && $h == 48) || ($w >= 4 && $w <= 48 && $h == 32)))
> {
>    $error = 'The graphic\'s dimensions are not correct (' .
>             $w . 'x' . $h . ').';
> }
> else
> {
>    ...
> }
> 
> yes, the logic wants either a 48x48 graphic, or a 4x32 to 48x32 graphic.
> 
> I'd be happy to link the animated GIF in question... just in case there 
> was a problem with the GIF itself, I tried opening it up in an (old) 
> version of Fireworks, and re-exporting it, but the problem remains.
> 
> besides the possibility of a bug in PHP, I'm wondering if I need to 
> handle animated GIFs differently, or something like that?  but again, 
> this code has been running for... 3ish years without a problem like this 
> ever being reported... quite confusing.
> 

If you could link the gif I think that would help.

Also, just to point out, the comment in the script is wrong, if the
image is neither png or gif, the rest of the script will still be
parsed. The if logic is like this:

if($itype == 'image/gif')
    $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);



everything after that is executed

perhaps you wanted something like this:

if($itype == 'image' || $itype == 'image/png' || $itype ==
'image/x-png')
{
    if($itype == 'image/gif')
        $img = imagecreatefromgif($_FILES['file']['tmp_name']);
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);

    // execute the rest of the image checking script
}


Thanks,
Ash
http://www.ashleysheridan.co.uk




--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Sun, 2009-11-15 at 15:07 -0500, Ben wrote:
On my site I have a web form for users to upload graphics, however there are constraints on the size allowed. Recently, a user has been having problems, because the code is reporting the wrong size - a size too small to be allowed! They sent me a copy of the image so I could confirm the error, and I have: even though the image is a 32x32 image (2-frame animated GIF, if it matters), imagesx() and imagesy() report that the image is 30x24! I have never had this problem before (or, at least, no one has reported it to me) so I'm tempted to think that it's a bug in PHP, or (more likely) I am missing something crucial...

The relevant code:

if($itype == 'image/gif')
   $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else if($itype == 'image/png' || $itype == 'image/x-png')
   $img = imagecreatefrompng($_FILES['file']['tmp_name']);

// note: we do not get here if($itype != 'image/gif' && $itype !=
// 'image/png' && $itype != 'image/x-png'), so the problem should not
// lie with an image type we were not expecting

$w = imagesx($img);
$h = imagesy($img);

if(!(($w == 48 && $h == 48) || ($w >= 4 && $w <= 48 && $h == 32)))
{
   $error = 'The graphic\'s dimensions are not correct (' .
            $w . 'x' . $h . ').';
}
else
{
   ...
}

yes, the logic wants either a 48x48 graphic, or a 4x32 to 48x32 graphic.

I'd be happy to link the animated GIF in question... just in case there was a problem with the GIF itself, I tried opening it up in an (old) version of Fireworks, and re-exporting it, but the problem remains.

besides the possibility of a bug in PHP, I'm wondering if I need to handle animated GIFs differently, or something like that? but again, this code has been running for... 3ish years without a problem like this ever being reported... quite confusing.


If you could link the gif I think that would help.

Also, just to point out, the comment in the script is wrong, if the
image is neither png or gif, the rest of the script will still be
parsed. The if logic is like this:

if($itype == 'image/gif')
    $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);



everything after that is executed

perhaps you wanted something like this:

if($itype == 'image' || $itype == 'image/png' || $itype ==
'image/x-png')
{
    if($itype == 'image/gif')
        $img = imagecreatefromgif($_FILES['file']['tmp_name']);
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);

    // execute the rest of the image checking script
}


Thanks,
Ash
http://www.ashleysheridan.co.uk




what I meant by the comment, is that that previous code DOES exist... to assure you that the problem isn't in having $img unset, or something along those lines. (I added in the comment after the fact.)

I have uploaded the image causing the problem here: www.telkoth.net/temp/radioactive-bread-eek.gif

I should also add: I have ended up working around the problem by using getimagesize() instead; that function is reporting the correct width and height. this furthers my belief that there's a bug somewhere with imagesx(), imagesy() or imagecreatefromgif()...
--- End Message ---
--- Begin Message ---
On Sun, 2009-11-15 at 16:25 -0500, Ben wrote:

> Ashley Sheridan wrote:
> > On Sun, 2009-11-15 at 15:07 -0500, Ben wrote:
> >> On my site I have a web form for users to upload graphics, however there 
> >> are constraints on the size allowed.  Recently, a user has been having 
> >> problems, because the code is reporting the wrong size - a size too 
> >> small to be allowed!  They sent me a copy of the image so I could 
> >> confirm the error, and I have: even though the image is a 32x32 image 
> >> (2-frame animated GIF, if it matters), imagesx() and imagesy() report 
> >> that the image is 30x24!  I have never had this problem before (or, at 
> >> least, no one has reported it to me) so I'm tempted to think that it's a 
> >> bug in PHP, or (more likely) I am missing something crucial...
> >>
> >> The relevant code:
> >>
> >> if($itype == 'image/gif')
> >>    $img = imagecreatefromgif($_FILES['file']['tmp_name']);
> >> else if($itype == 'image/png' || $itype == 'image/x-png')
> >>    $img = imagecreatefrompng($_FILES['file']['tmp_name']);
> >>
> >> // note: we do not get here if($itype != 'image/gif' && $itype !=
> >> // 'image/png' && $itype != 'image/x-png'), so the problem should not
> >> // lie with an image type we were not expecting
> >>
> >> $w = imagesx($img);
> >> $h = imagesy($img);
> >>
> >> if(!(($w == 48 && $h == 48) || ($w >= 4 && $w <= 48 && $h == 32)))
> >> {
> >>    $error = 'The graphic\'s dimensions are not correct (' .
> >>             $w . 'x' . $h . ').';
> >> }
> >> else
> >> {
> >>    ...
> >> }
> >>
> >> yes, the logic wants either a 48x48 graphic, or a 4x32 to 48x32 graphic.
> >>
> >> I'd be happy to link the animated GIF in question... just in case there 
> >> was a problem with the GIF itself, I tried opening it up in an (old) 
> >> version of Fireworks, and re-exporting it, but the problem remains.
> >>
> >> besides the possibility of a bug in PHP, I'm wondering if I need to 
> >> handle animated GIFs differently, or something like that?  but again, 
> >> this code has been running for... 3ish years without a problem like this 
> >> ever being reported... quite confusing.
> >>
> > 
> > If you could link the gif I think that would help.
> > 
> > Also, just to point out, the comment in the script is wrong, if the
> > image is neither png or gif, the rest of the script will still be
> > parsed. The if logic is like this:
> > 
> > if($itype == 'image/gif')
> >     $img = imagecreatefromgif($_FILES['file']['tmp_name']);
> > else
> >     if($itype == 'image/png' || $itype == 'image/x-png')
> >         $img = imagecreatefrompng($_FILES['file']['tmp_name']);
> > 
> > 
> > 
> > everything after that is executed
> > 
> > perhaps you wanted something like this:
> > 
> > if($itype == 'image' || $itype == 'image/png' || $itype ==
> > 'image/x-png')
> > {
> >     if($itype == 'image/gif')
> >         $img = imagecreatefromgif($_FILES['file']['tmp_name']);
> >     if($itype == 'image/png' || $itype == 'image/x-png')
> >         $img = imagecreatefrompng($_FILES['file']['tmp_name']);
> > 
> >     // execute the rest of the image checking script
> > }
> > 
> > 
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> > 
> > 
> > 
> 
> what I meant by the comment, is that that previous code DOES exist... to 
> assure you that the problem isn't in having $img unset, or something 
> along those lines.  (I added in the comment after the fact.)
> 
> I have uploaded the image causing the problem here: 
> www.telkoth.net/temp/radioactive-bread-eek.gif
> 
> I should also add: I have ended up working around the problem by using 
> getimagesize() instead; that function is reporting the correct width and 
> height.  this furthers my belief that there's a bug somewhere with 
> imagesx(), imagesy() or imagecreatefromgif()...
> 


It does indeed seem to be some sort of bug. I've just tested it with
your image on my machine here and for imagesx() and imagesy() it gives
30 and 24 respectively. getimagesize() does return the correct
dimensions though.

The same image saved as a flat single layer gif from the Gimp behaves
exactly the same way.

This might not be a proper bug as such, as the image itself might be
32x32, but the first layer (the first frame in the animated version) is
30x24 when you remove the dead, unused, transparent background. Perhaps
GD is meant to report on the *actual* size of the image, rather than the
dimensions of the frame?

Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Sun, 2009-11-15 at 16:25 -0500, Ben wrote:

Ashley Sheridan wrote:
On Sun, 2009-11-15 at 15:07 -0500, Ben wrote:
On my site I have a web form for users to upload graphics, however there are constraints on the size allowed. Recently, a user has been having problems, because the code is reporting the wrong size - a size too small to be allowed! They sent me a copy of the image so I could confirm the error, and I have: even though the image is a 32x32 image (2-frame animated GIF, if it matters), imagesx() and imagesy() report that the image is 30x24! I have never had this problem before (or, at least, no one has reported it to me) so I'm tempted to think that it's a bug in PHP, or (more likely) I am missing something crucial...

The relevant code:

if($itype == 'image/gif')
   $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else if($itype == 'image/png' || $itype == 'image/x-png')
   $img = imagecreatefrompng($_FILES['file']['tmp_name']);

// note: we do not get here if($itype != 'image/gif' && $itype !=
// 'image/png' && $itype != 'image/x-png'), so the problem should not
// lie with an image type we were not expecting

$w = imagesx($img);
$h = imagesy($img);

if(!(($w == 48 && $h == 48) || ($w >= 4 && $w <= 48 && $h == 32)))
{
   $error = 'The graphic\'s dimensions are not correct (' .
            $w . 'x' . $h . ').';
}
else
{
   ...
}

yes, the logic wants either a 48x48 graphic, or a 4x32 to 48x32 graphic.

I'd be happy to link the animated GIF in question... just in case there was a problem with the GIF itself, I tried opening it up in an (old) version of Fireworks, and re-exporting it, but the problem remains.

besides the possibility of a bug in PHP, I'm wondering if I need to handle animated GIFs differently, or something like that? but again, this code has been running for... 3ish years without a problem like this ever being reported... quite confusing.

If you could link the gif I think that would help.

Also, just to point out, the comment in the script is wrong, if the
image is neither png or gif, the rest of the script will still be
parsed. The if logic is like this:

if($itype == 'image/gif')
    $img = imagecreatefromgif($_FILES['file']['tmp_name']);
else
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);



everything after that is executed

perhaps you wanted something like this:

if($itype == 'image' || $itype == 'image/png' || $itype ==
'image/x-png')
{
    if($itype == 'image/gif')
        $img = imagecreatefromgif($_FILES['file']['tmp_name']);
    if($itype == 'image/png' || $itype == 'image/x-png')
        $img = imagecreatefrompng($_FILES['file']['tmp_name']);

    // execute the rest of the image checking script
}


Thanks,
Ash
http://www.ashleysheridan.co.uk



what I meant by the comment, is that that previous code DOES exist... to assure you that the problem isn't in having $img unset, or something along those lines. (I added in the comment after the fact.)

I have uploaded the image causing the problem here: www.telkoth.net/temp/radioactive-bread-eek.gif

I should also add: I have ended up working around the problem by using getimagesize() instead; that function is reporting the correct width and height. this furthers my belief that there's a bug somewhere with imagesx(), imagesy() or imagecreatefromgif()...



It does indeed seem to be some sort of bug. I've just tested it with
your image on my machine here and for imagesx() and imagesy() it gives
30 and 24 respectively. getimagesize() does return the correct
dimensions though.

The same image saved as a flat single layer gif from the Gimp behaves
exactly the same way.

This might not be a proper bug as such, as the image itself might be
32x32, but the first layer (the first frame in the animated version) is
30x24 when you remove the dead, unused, transparent background. Perhaps
GD is meant to report on the *actual* size of the image, rather than the
dimensions of the frame?

Thanks,
Ash
http://www.ashleysheridan.co.uk




! interesting (that it's doing some kind of trimming). it hadn't occurred to me that it might be doing that. if that's the case, and intended behavior of these functions, I feel like it should definitely be mentioned somewhere on php.net
--- End Message ---
--- Begin Message ---
What do people on this list use as an ultra-lightweight web server (with 
PHP capability of course) on Windows? I have an old but still well 
functioning laptop that I have just given a second life by installing 
Windows Fundamentals (a stripped down version of XP). This works 
surprisingly well. So now I am looking for the necessary software, so I 
can do some local programming.

Some requirements I can think of:

- Extremely small memory footprint and fast efficient code. This laptop
  still works well but it can certainly use some help!
- Both free as in beer and free as in speech would be my preference.
- Be able to run as a "service" in XP.
- Be able to run PHP (obviously) and perhaps a few other nice server
  features, like SSI and name based virtual hosts.

Any suggestions? I have not seriously used Windows for years now, so my 
knowledge of that platform is not exactly up to date anymore. I am used 
to dealing with Debian/Ubuntu Linux and Apache but not much else, 
frankly. Apache does seem to heavy for this. My initial thought was to 
install Lighttpd under Cygwin, but perhaps I would be missing out on some 
great little server program that I have not yet heard about.

--- End Message ---
--- Begin Message ---
On Sat, 14 Nov 2009 17:39:20 -0800, Don Wieland wrote:

> Hello,
> 
> I am trying to create an UPLOAD page to Update a Images and PDFs into  
> a BLOB field in mySQL. The image keeps getting corrupted (it draws a  
> portion of the image and the rest is GRAY) We tried it with Safari and  
> Firefox with bad results.
> 
> Here is the QUERY to upload the image (saveDialog.php):
> 
> if($_POST['obj'] == "uploadImage") {
> $file = $db->real_escape_string(file_get_contents($_FILES['img'] 
> ['tmp_name']));
> $db->query("UPDATE Areas SET Image = '$file'") or die("1".$db->error);

Random ideas:

* Select the image from the database and compare it to $file.
  Are they identical?
* Run a hex dump on the images before and after upload.
  What is the difference?


/Nisse

--- End Message ---
--- Begin Message ---
Hi everyone,

I'm not sure of the correct formula for this, if I have a file - just
for example, that is 10245458756 bytes long and the download speed is
60KB a second, what formula would I use to calculate how many
seconds/minutes/hours it would take to download the file?

Maths really isn't my strong point and formulas go over my head
otherwise I wouldn't ask :-(

Thanks everyone

Chris

--- End Message ---
--- Begin Message ---
Chris Payne wrote:
Hi everyone,

I'm not sure of the correct formula for this, if I have a file - just
for example, that is 10245458756 bytes long and the download speed is
60KB a second, what formula would I use to calculate how many
seconds/minutes/hours it would take to download the file?

Maths really isn't my strong point and formulas go over my head
otherwise I wouldn't ask :-(

Thanks everyone

Chris

$size = 1024548756; // in bytes
$kb_per_sec = 60;   // I assume you'll fill these in from elsewhere?

$b_per_sec = $kb_per_sec * 1024;

$seconds = $size / $b_per_sec;
$minutes = 0;
$hours = 0;

if($seconds > 60)
{
  // 60 seconds to a minute
  $minutes = (int)($seconds / 60);
  $seconds -= $minutes * 60;

  if($minutes > 60)
  {
    // 60 minutes to an hour
    $hours = (int)($minutes / 60);
    $minutes -= $hours * 60;

    // if you want to go further and calculate days, have at :)
  }
}

You could also approach this using modulus, but if you're not confident with math, this might be a more intuitive approach.
--- End Message ---
--- Begin Message ---
If the download speed is constant (linear) then you can just use.

(10245458756 / 60000t)/1000 = kb/second
or
(10245458756 / 60000t)/60000 = kb/minute

The general form would be.
(size_of_file / download_speed * time) / convert_to_units

Where t (or time) is the amount of seconds that the download has been active.


On Sun, Nov 15, 2009 at 15:39, Chris Payne <chris_pa...@danmangames.com> wrote:
> Hi everyone,
>
> I'm not sure of the correct formula for this, if I have a file - just
> for example, that is 10245458756 bytes long and the download speed is
> 60KB a second, what formula would I use to calculate how many
> seconds/minutes/hours it would take to download the file?
>
> Maths really isn't my strong point and formulas go over my head
> otherwise I wouldn't ask :-(
>
> Thanks everyone
>
> Chris
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
- Adam Shannon ( http://ashannon.us )

--- End Message ---

Reply via email to