net page to upload a large file and a generic handler to play these large wmv video files of size which can be upto 150 MB's. I have the file content stored in varbinary type in SQL Server 2005.
I have set following settings in httpRuntime in web.config
<httpRuntime executionTimeout="110"
maxRequestLength="2097151"
requestLengthDiskThreshold="2097150"
shutdownTimeout="600"
delayNotificationTimeout="400"/>
The problem is that sometimes my files doesnt play. It get uploaded properly but when playing the request seems to get timeout. I was able to play files upto 100 MB's. It works 9 out of 10 times on local and production but why does it fails sometimes. The same file get played in one instance but on other instance it doesnt. Can anybody suggest where the problem may be. I think there must be some combination of httpRuntime attributes which i am missing. Please suggest. Its a production issue which keeps popping up.
why don't you use IHttpHandler? try this Uploading FIle Using IHttpHandler Might be there will be better solutions to use IHttpHandler if you will search for it.
Related
Greetings & Salutations one and all
I'm new to mixxx been using it for about 4hrs and its a brilliant piece of software so thanks once again for this amazing program. The issues i'm having is that it creates and double m3u.m3u. extension when I'm live broadcasting. I had issues with getting this to work but figured it out with lame.dll which I didn't have to rename as this solution is for version 1 and below.
It works now after putting the lame encoder.dll file into the mixxx folder, which I think might be the issue i'm not sure. the live broadcasting connects successfully and it connects to my icecast server without issue, however when I click on m3u on icecast admin page or connect directly to it the web e.g. http://externalIP:8000/stream it show me the m3u.m3u error, which is causing the streaming error as its creating a double m3u file and as we know only .m3u works not m3u.m3u. so I think its the encoding creating this double extension but I'm not sure hence the post. any ideas??
mixxx m3u.m3u error
Make sure you configure a mount point in Mixxx.
Like /stream.ogg or /radio.opus, depending on the format/codec.
Also make sure that it does NOT end in m3u! The mountpoint is a virtual media file, not a playlist. The server will automatically generate another virtual file, a m3u playlist for it.
I want to know if there is a 'right' way to make file uploads through custom tools.
I've seen the https://confluence.sakaiproject.org/display/BOOT/File+Uploads+with+RSF guide and it seens ok, but It stops with the file in memory with no further info. I can built a random file upload code but I want to make it Sakai-friendly (Using ContentHosting and Resources service?)
Any hints?
Thanks
The link you provided for the first part is a good example of how to get the upload initially processed. Going through RequestFilter will get your files validated, but you can use whatever method you want to upload it.
For the second part, I'd look at the ContentHosting webservice (createContentItem) for an example of how to add a file from a byte[] in memory after you've uploaded it.
These methods in ContentHostingService also accept InputStream as a parameter as of 2.7 (KNL-325), so you don't have to store the entire file in memory and can stream it as you're uploading, which you should do if the files are of any reasonable size.
We're currently working with Filepicker.io to allow users the ability to upload both images and videos. It appears that if we specify image conversions in the Javascript API options, video uploads don't process and instead get stuck at 99.30%. If I remove the 'conversions' option, video uploads process without issue. Is it not possible to specify image conversion options and accept both type of uploads? If so, this should really be specified in the docs.
I attached a JSFiddle with the code in question. http://jsfiddle.net/BYkD4/
It might be an issue on our end, taking a look now. For large files (+1Mb) we split the file into chunks, upload them in parallel, and then reassemble them on the server side. We use browser progress up to the 90% mark, after which we have to "best guess" what the server-side progress looks like, for now at least. That's the reason why it's hanging at 99.30% - it may actually be able to complete if you give it enough time.
In any case, looking into it
Edit: looks like this was an issue on our end. Fix deployed, everything should be working fine. Sorry about the issue
I have recently started working with a fresh install of FMS 4.5.0 and am having some issues getting my media to load with the VOD application.
After uploading some of my own FLV/F4V content to "/webroot/vod/", I am currently only able to load the samples from the installation.
Is there some sort of configuration that needs to be made to access my media?
Do I need to create a manifest for each video?
I have been running tests through:
http://www.osmf.org/configurator/fmp/
And have had luck accessing the videos that came with the install by using the following:
Video Source (URL): http://[my host]/vod/sample1_1000kbps.f4v
But when I change this to point to one of my recently uploaded videos it fails everytime.
Another strange note, I was able to play one of the samples but then I changed its name and it was still able to load that one specific video using the same filename when the file's name had changed. This leads me to believe that it isn't really loading the right files or perhaps I am uploading to the wrong directory. But I can't find any other directories that have video in them.
Please let me know if there is any more info you need to help me. I'm fairly new to this and am not sure what to include.
Thanks in advance for any help!
EDIT: This was a pathing issue.
This has been resolved.
Apparently my webroot directory for the server was not set up correctly and after it was pointing to the right directory it was fixed.
I used the sample code from http://cocoawithlove.com/2008/09/streaming-and-playing-live-mp3-stream.html. it runs OK with default URL. But when I replace with my URL "http://dl.mp3.kapsule.info/fsfsdfdsfdserwrwq3/fc90613208cc3f16ae6d6ba05d21880c/4b5244f0/b/7e/b7e80afa18d06fdd3dd9f9fa44b51fc0.mp3?filename=Every-Day-I-Love-You.mp3", this app shows an message as "Audio not Found". But when I put my URL on Address Bar of Web Browser, I can download this .mp3 file.
really, I can't understand why it is?
pleased tell me!
Thank you very much
My guess would be that the app is designed to play a MP3 encoded audio stream with no limit in length (which is different from your ordinary music file). To set this up, you need a streaming server on the client side.
I think you can find out for sure by trying with a different radio station that transmits in MP3. If that works, it's most likely that your app doesn't like your file.
You should, as Vivek recommends, also try using a simpler download URL for your file, in case the App gets confused by the URL's length and/or structure.
As mentioned, this is due to the URL of the file. The AudioStreamer code specifically checks for the extension of the file and tries to figure out the audio type based on that. If you change that logic to handle your custom URLs, it will start working
So to point you in the right direction: open AudioStreamer.m and look for the references of
hintForFileExtension:
This function returns the type of file based on the extension. If you know the file type won't change (always mp3), the quick and dirty solution is to always assign mp3 type without any logic... like this:
err = AudioFileStreamOpen(self, MyPropertyListenerProc, MyPacketsProc, kAudioFileMP3Type, &audioFileStream);
Note: I've put kAudioFileMP3Type constant instead of calculated value
PS yes, it does work with static mp3 files, even though it's designed for streams and hence misses some of the functionality one would expect from a player that plays a static file on the server (caching, prefetching, proper seeking)
Thats because the default url directly points to a file in the webserver, whereas the the url you've mentioned is a HTTP (POST/GET) operation, which the application may not be designed to handle.
I suspect that your URL is one-time-use. When I try to visit it, I see 408 - Request Timeout.
Many links on mass file sharing websites are like this. If you could download the file directly, you wouldn't sit through a page of ads and premium account offers.
Try again with a file on a normal website, like this one.