Tuesday, 6 November 2007 - 7:40 AM EST

At a connection speed of 44kbps it took 5 reloads on the AF site to DL the pic. On tripod, it DL/d without problem so there's dedfinitely a problem......but why are you using 400kb files at all if you have modem users? That jpg could easily be optimized. Adding a a little compression got the file size down to 60KB with little change in viewing quality. reducing it's physical dimensions before upload would also cut the file size considerably.

PS- you're using a bmp on your home page. That's not a web format and some visitors may not be able to view the file (like me :)

Anyway, hope that helps 

Tuesday, 6 November 2007 - 8:27 AM EST

Thanks very much for your comments.  You are exactly right about compressing the jpeg to make it smaller.  However, the jpeg image file was for test only to demonstrate that there is a problem.

 Generally we try to keep files as small as possible but we have a lot of songs and 45-minute long worship services on the Virtual Worship Page that visitors listen to.  The files are progressive download Shockwave flash files compressed for 56k users and faster.  The file plays as it is being downloaded so even though a 3K file may take 30 minutes to download at 56K, the listener will be able to start hearing the song/service almost immediately without waiting for the file to download and should be able to hear the whole thing without interruption.

 Our problem is that if  Angelfire cuts the download off at 30 seconds, the listener will not hear the remainder of the worship service which makes the posting useless to the 56k users.  Anyone else with a similar type file would experience the same problem.

Tuesday, 6 November 2007 - 8:33 AM EST

Also thanks for the bmp reminder.  Actually the file is a jpg that has been renamed with an extention bmp.  This was done and forgotten about about 8 years ago to fool the old AOL browser to not further compress the photos before displaying them which often times meant that the photo was almost unreadable through AOL.  But all browsers have been updated since then and we neglected to change our convention.  I will do that today.

Tuesday, 6 November 2007 - 8:36 AM EST

I meant to say 3 mb file not 3k

Tuesday, 6 November 2007 - 9:22 AM EST

re the swf audio/video files. Have you tried loading them from the tripod account to your AF page? Since AF/tripod are sister servers it might be possible even though your tripod account is a free one.

Also- some of your swf files are coming from comcast. They did not load for me earlier because I would not let comcast set a cookie. I mention that in case someone else has trouble loading your files.

And as an additional thought. The more servers called on to load a page the slower the download speed. You might also try to consolidate the number of servers being used for any one page to speed load time (in general) for modem users..

Tuesday, 6 November 2007 - 2:24 PM EST

I have DSL so my  test is useless as CW said the images are too large byte wise and the connection is slow, it is the connecction that doesn't stay alive long enough. if you can view the image on the server then it is not a server's problem

Tuesday, 6 November 2007 - 8:31 PM EST

Thanks CW for your comments.  I would love to have all files consolidated on Angelfire because we have a very large amount of storage there but since the Angelfire server is experiencing problems with our progressive downloads, we were forced to use all resources available just to make the site reasonably functional.  We have about 80 mb of shockwave flash files and plan to have much more in the future.  Comcast doesn't have the problem with downloads so the audio and video files on the main page are stored there temporarily.  A few of the Virtual Worship files are stored on Tripod for temporary use also.  Neither the Tripod account or Comcast account have nearly the space we have with the Angelfire account so we are patiently waiting for the Angelfire problem to be fixed. You are also right about Tripod and Angelfire being "sister" organizations and that was one of the reasons that I chose Tripod for my test: the two groups are in the Lycos family.

Tuesday, 6 November 2007 - 9:09 PM EST

Thanks anonymous for your comment.

 I will be the first to say that I am no server expert and it is true that ftp downloads (of the same file) will work from the Angelfire system but then why not through http links??  There is a problem associated with Angelfire but I don't really know what it is.  What I do know is that we did not have any problems with this type of file download until sometime this year (we have been doing the progressive download for years now).  But since the same files work just fine on Comcast and Tripod (linked from AF), the probem appears to just be on AF.  Our storage level was upgraded this year and perhaps that process had something to do with this problem.  Who knows?  

Also there are some instructions in the help section of Angelfire for streaming mov files but of course we could not get that to work for 56k modems either when the files were placed on the Angelfire server.  It took a while to finally isolate the Angelfire system as the root cause for the failure of the progressive downloads. The thing is that not only is the download connection stopped prematurely, I suspect  that  (for  whatever the reason  is) the receiving computer thinks that the file download is complete and not just interrupted.  To verify this, I put a dummy file on Angelfire with a fictitious extension so that the save screen would come up.  Less than 120 kb of the 428 kb file would download (with a 56k dial-up connection) and the save dialog would respond that the download was complete!  That file link is below:

 https://www.angelfire.com/tn/fbaptist/test_file.mmm

 Most of my problem is just convincing Techical Support that a probem exists for 56k modem users.  Once they realize that there is in fact a problem, I am hopeful that the engineers taking care of that system will be able to correct the difficulty in short order.

Saturday, 10 November 2007 - 11:32 AM EST

You are right!  The same problem exists on our site and that' all we do (stream music).  I hope they will fix the bug soon.  In the meantime, we are putting our site "under construction".  I am not a technical web person and so about the only thing I can verify is that our Angelfire site will not play the music at 56k for more than 35 sec even though most of the songs are 4 min long or longer.   Thanks for your troubleshooting.