I have a piece of my site being built for me that works like this... when you click a song, the song loads in the player and plays it.
I'm being told by the guy who's developing it for me that Asp.Net does not support 320kbps files, so that's why the player isn't working. This seemed a little ridiculous so I did some research on it and couldn't find anything that says so:
http://msdn.microsoft.com/en-us/library/cc189080%28VS.95%29.aspx
He found this on that page:
24 bit audio will return silence.
But that's under the WMA section, not the MP3 section, I can't even tell if they're 24 bit or not anyways... The only info I have is that the songs are 320kbps and they're all .mp3 files. I can provide more info if you tell me where to look. Please let me know why he would be saying that these files can't be streamed... he says he's tried 128kbps and it worked, but that these are incompatible.
Thanks,
Matt
I'm being told by the guy who's
developing it for me that Asp.Net does
not support 320kbps files, so that's
why the player isn't working.
You're right, he's wrong. That page is irrelevant.
Asp.net doesn't care -- doesn't know! -- what's inside the file. If the connection doesn't overtax the available bandwidth, you're fine.
Assuming you're using a static file and not a dynamic one, ASP.NET will never even see it. All references to static files are handled by IIS, without involving the ASP.NET runtime.
However, by default static files aren't streamed. Instead, they are sent at the maximum speed that the connection will support. If you want true streaming, you will need to add an appropriate plug-in to IIS, or use something like Windows Media Server.
Related
Whenever you reference something in your public or assets directory via link/script tags, are you only downloading what you reference?
For example, say I have an enormous amount of images in my public directory. Only images that are referenced on that particular page are downloaded, right?
Taking this further, say your stylesheet references a lot of images, and it serves every single page on the your website. So are all of those images downloaded?
You see, I'm probably lacking some fundamental background on this as I'm pretty new to web dev, and I don't have much experience with nginx/apache or the like. Please explain!
Yes, the browser has no idea, what files are located on the server. It only knows those paths that are referenced in HTML (via <link/>, <script/>, <img/>, <a/>, etc.).
You can also have a look at the so called access log of your web server or (better) your browser's developer tools (Firebug, Chrome DevTools) to investigate what happens under the hood.
My web application allows authorised users to upload videos using the ASP.NET WebForms FileUpload web control, which in the past have been around 100-200MB. I had to obviously make some changes to the web.config so that files of this size could be uploaded.
However, the authorised users now want to upload video files which are 500MB+
The maxAllowedContentLength has now been set to 629145600 (600MB).
However, when uploading the videos, after a while the page responds with:
Page not found
This only happens with large videos, so I know this issue has something to do with the file size.
Why is this happening? And also, should I really be increasing the limit to 500MB+? Is there a better way of getting such large files onto the web server?
Check out this blog post by Jon Galloway, its a bit old but still relevant:
Large file uploads in ASP.NET
Its got answers to your questions about:
page not found
setting the correct maxAllowedContentLength
There's recommendations for various controls you can use, both free and commercial.
I've used the flash control and it worked great.
Alternative Solution
Provide an FTP area for each user to upload too.
It allows users:
easily batch upload many files (harder in the browser)
takes advantage of resume on disconnect
Then you provide a GUI for the user, to consume the files.
Have you considered using jQuery File Upload https://github.com/blueimp/jQuery-File-Upload/ there are versions available for .net and mvc (see the git hub wiki). It takes all the heart ache out of implementing large file uploads in .net and provides a lovely interface too. Since discovering this a while ago I never use anything else! I've successfully implmented a few times now and seen uploads ~2GB working successfully.
I need to do this:
1) enter a certain website using my clients usernames and pass- they are aware of that offcourse :)
2) navigate inside, a matter of 6 steps
3) download a .csv file from the site
It's a water meter reading site, and I want to update my DB automaticly every hour.
Using WebBrowser in c#, it works great. But, I need it to be on a server and run it all the time for the info to be up to date.
Webservices aren't valid because the reading site has nothing to do with me (3rd side company etc.).
So basically, what I need is to mimic the webbrowser control. what I found unthe codeproject didn't helped me.
I'm checking if CGI can do the trick, but perhaps I'm offtrack here.
thanks for your help!
You can use the HttpRequest/Response objects in the System.Net namespace. They don't mimic the web control but they do allow you to make the requests you want.
I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?
I've recently started embedding JavaScript and CSS files into our common library DLLs to make deployment and versioning a lot simpler. I was just wondering if there is any reason one might want to do the same thing with a web application, or if it's always best to just leave them as regular files in the web application, and only use embedded resources for shared components?
Would there be any advantage to embedding them?
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
I doubting and questioning the validity of Easement's comment about how browsers download JavaScript files. I'm pretty sure that the embedded JavaScript/CSS files are recreated temporarily by ASP.NET before the page is sent to the browser in order for the browser to be able to download and use them. I'm curious about this and I'm going to run my own tests. I'll let you know how it goes....
-Frinny
Of course if anyone who knew what they were doing could use the assembly Reflector and extract the JS or CSS. But that would be a heck of a lot more work than just using something like FireBug to get at this information. A regular end user is unlikely to have the desire to go to all of this trouble just to mess with the resources. Anyone who's interested in this type of thing is likely to be a malicious user, not the end user. You have probably got a lot of other problems with regards to security if a user is able to use a tool like the assembly reflector on your DLL because by that point your server's already been compromised. Security was not the factor in my decision for embedding the resources.
The point was to keep users from doing something silly with these resources, like delete them thinking they aren't needed or otherwise tamper with them.
It's also a lot easier to package the application for deployment purposes because there are less files involved.
It's true that the DLL (class library) used by the pages is bigger, but this does not make the pages any bigger. ASP.NET generates the content that needs to be sent down to the client (the browser). There is no more content being sent to the client than what is needed for the page to work. I do not see how the class library helping to serve these pages will have any effect on the size of data being sent between the client and server.
However, Rjlopes has a point, it might be true that the browser is not able to cache embedded JavaScript/CSS resources. I'll have to check it out but I suspect that Rjlopes is correct: the JavaScript/CSS files will have to be downloaded each time a full-page postback is made to the server. If this proves to be true, this performance hit should be a factor in your decision.
I still haven't been able to test the performance differences between using embedded resources, resex, and single files because I've been busy with my on endeavors. Hopefully I'll get to it later today because I am very curious about this and the browser caching point Rjlopes has raised.
Reason for embedding: Browsers don't download JavaScript files in parallel. You have a locking condition until the file is downloaded.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
Regarding the browser cache, as far as I've noticed, response on WebRecource.axd says "304 not modified". So, I guess, they've been taken from cache.
I had to make this same decision once. The reason I chose to embed my JavaScript/CSS resources into my DLL was to prevent tampering of these files (by curious end users who've purchased my web application) once the application's deployed.
Reason against embedding: You may not need all of the JavaScript code. So you could be increasing the bandwidth/processing unnecessarily.
You know that if somebody wants to tamper your JS or CSS they just have to open the assembly with Reflector, go to the Resources and edit what they want (probably takes a lot more work if the assemblies are signed).
If you embed the js and css on the page you make the page bigger (more KB to download on each request) and the browser can't cache the JS and CSS for next requests. The good news is that you have fewer requests (at least 2 if you are like me and combine multiple js and css and one), plus javascripts have the problem of beeing downloaded serially.