My brother has a computer running Windows XP with SP2 installed. His computer was behaving badly (very old installation of Win) and one of the problems was that he could not upload jpegs to Facebook, for example. The upload would complete, but the images are garbled.
Finally I decided it was time to format his computer and reinstall windows, which I did.
Still, images would upload garbled to Facebook. I tried using Google Chrome instead of IE, same problem. Then I discovered that this is not just a problem with image uploads, all HTTP uploads seem to fail. For example, I could not send an e-mail with an attachment on his computer using G-mail, the attachment got corrupted.
Any ideas? I don't really know where this problem originates.
Happens in different browsers
Win XP has been re-installed
Just got a new xDSL router (the wired lan section on the old one seized), but same problem
Is it possible his network is glitching? The only correctness check on a HTTP upload is the Content-Length header and even that's option (and frequently unchecked by the receiving end anyway). If his TCP connections are dropping then the receiving end could think it has a full image but really have gotten only the beginning of it.
Related
We have a site that uses ConvertAPI to create PDFs and download them. They are working in most instances but are failing with large files in certain circumstances. Here's what I could gather:
1: it only happens with a large PDF.
2: it only happens on the mac
3: it appears to have a commonality with Acrobat where Acrobat's plugin called "Web2PDF" is listed as "loaded: no" on the two machines that are not correctly allowing the ConvertAPI code to work. There's another mac where it DOES work in our office, but that mac is working fine.
Anyone seen this before? Help?
Thanks.
Paul
It is hard to say for sure what is the problem, as there is no information about which command is used. However, the similar problem occurs with large files if you are using the ConvertApi with a secure https URL instead of the http, as in this case:
Powerpoint upload stops at ~9MB with cURL -F
Please let us know if changing to the http URL helps with the problem.
When running a flash application that I run locally
ie I get to it from a browser but with a file path
file:///C:/Projects/test/bin-debug/Main.html#
Now, most of the time the shared objects are stored in
%APPDATA%\Macromedia\Flash Player#SharedObjects\XXXX#localWithNet
But occasionally, it reverts and thinks this application is running on localhost
%APPDATA%\Macromedia\Flash Player#SharedObjects\XXXX\localhost
which means all previous saved settings are gone.
I'm wondering if anyone knows how flash decides if the application is infact localhost or localWithNet (local with Network access)
Rebooting can sometimes make it revert, but I've also had it stay localhost for a few days then revert.
Normally, it has everything to do with your 'domain'. If you're running in a browser with file://pathToSwf/YourSwf.swf, that's normally localWithNet, if you're doing http://localhost/YourSwf.swf, that's localhost domain. I don't think there's any other way for this to happen unless you're doing something funky, but then I don't know that since I need more details.
I have a problem with Visual Studio 2010. When I start debugging it works slowly.
Internet Explorer opens, but the website loads extremely slowly.
My workmate and me work on the same project and he doesn't have any problem like that.
My hardware is 4G memory + Intel Core i5 CPU 3.20 GHz.
I stopped my anti-virus program but it couldn't be resolved.
I've had the same problem for over a year! And I solved it :)
I took me about 20 seconds to start debugging, and about 1 minute to stop it. It also took 2 minutes to load the solution! My colleague had NO problems with the same solution.
I found my way out of it by a coincidence.
I CHANGED the NAME of the solution, and things suddenly happened 30 times faster.
I CHANGED the solution name back and it slowed down again!
This is probably a FUBAR error made by the Microsoft development team. Don't try to figure out why it happens :)
This might be a IPV6 issue (that shows itself in windows vista/7 when using firefox or IE). I've had that at work and this is what made pages load instantly when using localhost (instead of the 20+ seconds that could happen on image-heavy websites I was developing).
IPv6 (taken from Firefox cannot load websites but other programs can )
Firefox supports IPv6 by default, which may cause connection problems on certain systems. To disable IPv6 in Firefox:
In the Location bar, type about:config and press Enter.
The about:config "This might void your warranty!" warning page may appear. Click I'll be careful, I promise!, to continue to the about:config page.
In the Filter field, type network.dns.disableIPv6.
In the list of preferences, double-click network.dns.disableIPv6 to set its value to true.
For Internet Explorer, try using http://127.0.0.1:PORT_NUMBER/ where PORT_NUMBER is the port you can see in your address bar. If the loading of the page is faster, then you might want to go check the C:\Windows\System32\drivers\etc\HOSTS file and make sure the only line mentioning localhost looks like 127.0.0.1 localhost.
Check to see if you have _NT_SYMBOL_PATH environment variable set. Getting symbols or pdb files for the assemblies used by your application from a symbol server could be the cause of the slow startup of your application when debugging. You can also look at the symbols setting in VS>Tools>Options>Debugging. Also, take a look at the output window and the status bar down at the bottom in VS when your app is loading and taking a long time to see what VS is busy doing.
Not sure if this applies to ASP.NET applications, but disabling the 'Show Parameter Values' option in the Call Stack window's context menu considerably speeds up the debugger on my machine.
Two things to check.
1. Remove all the parameters in the watch list.
2. Build >> Config Manager , Check the Configuration Mode: Debug/Release.
I have encountered the same problem. I could make it better by deleting the Folder created in the temporary aspnet folder. For that you need to close the solution that you have opened and then delete. I don't know if there is any other solution.
An application I wrote for a client almost 2 years ago using Flex 2 has stopped playing the .flv videos. It's been nearly 9 months since I've had to perform any updates to the app, so I don't have the source code on the computer I'm using at the moment. I'm not sure how often the client uses the application, so I can't say exactly when this started.
The videos just displays a black screen, does not load the first frame. I believe I used standard VideoDisplay object. The videos are contained in a folder on the same shared account as the application.
I've checked the application in latest versions of IE, Firefox and Chrome (running Flash 10) and I've also fired up a virtual machine to test it out in IE 7 with various releases of Flash 9 instead of Flash 10.
I checked, and the videos are still present, and I scattered some extra no-security cross-domain files around... but to no avail.
Does anyone have an ideas as to where I should start looking when I get back to my development computer? Could a change on the hosted server cause this?
UPDATE: I remembered another application with video that I had on the site that was made more recently using Flex 2. This application is a simple shell VideoDisplay object that serves up a .flv file in the same directory... and it works just fine.
So, the server is serving .flv files. The application I'm having problems with pulls .flv files from a different folder that is at the same level of the applications parent folder (the only difference I can see right now).
The someone cryptic error message received when using the debugging version of the Flash player was:
Error: 1000: No bitrate match
at mx.controls.videoClasses::VideoPlayer/play()
After getting back to my development machine I was able to determine that the XML file containing the URLs of the videos showed an old variant of the domain name that was in use a couple of years ago. This domain name was just allowed to expire, and so, the video player was pointing to .flv filenames no longer existed. Correcting the domain name resolved the problem.
You said the videos are still present, but are the being served?
A small hosting configuration change might cause files to no longer be served.
I would start there, you rule out that both your swf, and flv are accessible by the client browsers..
If it's on a new server, make sure it's serving the right mime type for .flv files, video/x-flv. I've had flash refuse to play videos without that set. Also, IIS now gives bogus 404 errors on requests to files of unknown mime type, so files can be on the servers, but invisible to clients. http://it.toolbox.com/blogs/rymoore/adding-flv-mime-type-in-iis-4198
When I yesterday returned to Visual Web Developer I was no longer able to run/debug my projects. Clicking the green play button launches ASP.NET Development Server (and it shows up in the systray) but the browser only shows the error message "Firefox is not able to connect to localhost:58127" (translated from Swedish). IE7 says "Cannot show web page".
I cannot figure out why this happens. It worked a couple of weeks back. Could there be a Windows setting that mess things up? (I've tried to disable the firewall without any change.)
Are you using Vista? I've had the same issues with recent Vista updates.
Firstly, make sure Visual Studio is running "As Administrator".
Secondly, when the browser launches, replace "http://localhost:" with "http://127.0.0.1:". If that works, then its because a Windows Update messed up your hosts file.
If this is the case, make sure you hosts file has this line in it, uncommented: "127.0.0.1 localhost"
my hosts file is in this directory: "C:\Windows\System32\drivers\etc"
yours will be something similar to that.
Are you perhaps using NOD32 or any other antivirus that may cause problems?
I encountered this issue today and just wanted to elaborate because my hosts file had "127.0.0.1 localhost" already defined.
I was able to see the default IIS site by referencing localhost but when I tried debugging in my IDE it would always display "cannot display webpage" in IE and "Oops! Google Chrome cannot connect to localhost" in Chrome.
I opened a command prompt and typed "netstat -a" and reviewed the results. I saw that my port used by my debugging web server was listed as "LISTENING" on the local address of [::1] only:
TCP [::1]:64212 [ComputerName]:0 LISTENING
What's unusual to me is that debugging worked for a period of time and then it seemed like all of a sudden it stopped. The first couple times it happened I re-installed Visual Web Developer Express 2010. This became rather annoying because it was a long process and the problem continued to resurface after what seemed to be an arbitrary period of time.
This latest time I changed my hosts file to include "::1 localhost" (the opposite of this solution and numerous others I found online) and that has resolved my issues with my debugging environment.
I'm grateful this resolved my issue but am still curious as to why and how my debugging environment seems to change. Additionally, I'm curious why there are multiple loopback addresses other than 127.0.0.1. Is "::1" an ip6 standard? If so, shouldn't localhost be routing to 127.0.0.1 and interpreted by the tcp/ip stack as the same as ::1?
I had this problem with Visual Studio 2013. I have set the Firewall system manually. This means that, at the time of communication by programs Firewall notify me. Incorrectly linked to "devenv.exe" was blocked by the Firewall. Correct mode of communication "devenv.exe" will solve the problem. in your case cheeck Firewall options and filtered communications.