If you're transferring a Stream to Azure Blob Storage via the official CloudBlockBlob class, how does one monitor the progress of the upload/download itself? I was expecting some events to that class since it's a network IO class but none seem to exist.
Right now our application sends the entire stream to CloudBlockBlob and it appears like it's done - but we know CloudBlockBlob is still uploading the bytes delivered to it in the stream, so it's really not done...
Am I missing something? Is an entirely different way of doing this (without reinventing the wheel!)
See the code at http://blogs.msdn.com/b/kwill/archive/2013/03/06/asynchronous-parallel-block-blob-transfers-with-progress-change-notification-2-0.aspx. It uses a ProgressStream wrapper around the file stream in order to raise events whenever data is transferred.
Related
Using Google's Nest Device Access API, I can generate an RTSP camera stream using the GenerateRtspStream command and subsequently stop the stream using the StopRtspStream command. Makes sense, however these streams are only alive for 5 minutes by default - so the API also features another command: ExtendRtspStream.
On the face of it, this sounds like it should "extend" the stream you had originally created, however these RTSP stream urls include an auth query parameter and extending a stream simply issues a new token to use for this, which means that the url for the stream changes every time it gets extended. So in reality the stream isn't getting extended at all as the url you use to access the stream still gets invalidated, and you have to restart it with a new url to continue watching the stream. So what's the point? You may as well just call the GenerateRtspStream command and switch over to that one once the first expires. Is there some way to seamlessly change the RTSP url mid-stream that I'm not aware of using FFMPEG, perhaps? Or to have a proxy server that broadcasts a static RTSP url and seamlessly switches the actual url each time it gets extended?
Rant starts here: I'm really hoping that this behaviour is actually a bug or oversight in the design of the API, and that ExtendRtspStream is supposed to keep the same url alive for as long as needed, because it's awfully pointless to have an RTSP stream that only stays alive for a max of 5 minutes. Heck, it'd be more useful to have an API that just returns the latest single-image snapshot from the camera every 10 seconds or so - but alas, there's no API for that either.
I am currently using the DataApi and Asset class to transfer a 30MB file from mobile to wear. I am using an IntentService but the file never gets to the mobile. The wear freezes and says "Application is not responding, do you want to wait?"
Should I use a SyncAdapter to send this over? I'm not sure on the best way to do this?
It is better to use ChannelApi methods; first obtain a channel and then use Channel#sendFile() to send the file across. ChannelApi is built for transferring large files and doesn't do a sync across all the devices but rather for the target that you have used to open the channel to. It also saves space on the sender side. If you don't need syncing across multiple connected devices, this is the api to use.
I am writing an end-point using Sinatra where I will be receiving raw pdfs from the client and need to process the pdf for internal use. Now the pdf processing takes a while and I do not necessarily want client to wait till the processing is finished and risking a timeout (504). Instead the would like to invoke another method that handles pdf processing while I respond back to the client with appropriate code. What is the best way to implement that using Sinatra?
So there's a few parts to this, so let me break down the various steps that are going to happen:
Client uploads a PDF file: depending on the size of the PDF and the speed of their connection, this could take a while. While you're waiting for the upload your web process is busy receiving the data and is unable to process any other requests for any other clients.
You then need to process the uploaded file, store it somewhere, possibly manipulate it somehow. If you do all that as part of the request process then there is yet more time you're tied up dealing with this one request and unable to serve other clients.
The typical way to solve the latter of those problems, manipulating or processing an uploaded asset, is to use a background job queue such as Sidekiq (http://sidekiq.org). You store the required data somewhere, keep enough information to know what to work on (e.g., the database ID of a model that has stored the relevant information, a filename, etc.), and then pass all of that required information into a background job. You then have separate worker processes that pick up that work and complete it, but they aren't part of your web process so they aren't blocking other clients from receiving information.
This still leaves us with the problem of handling large uploads, fortunately that has a solution too. Take advantage of all of the web capacity Amazon has and have the clients upload the file direct to S3, when it's complete they can post just the filename to you, and you can then queue that up into your worker from the previous step and have it all happen in the background. This blog post has a good explanation of how to wire it together using Paperclip http://blog.littleblimp.com/post/53942611764/direct-uploads-to-s3-with-rails-paperclip-and
What is the best way to send a byte stream from one Windows process to another assuming that both processes are running as a Windows service? The data consists of an image buffer. Each service is running on a separate server on the same subnet.
Should the second service that is receiving the buffer be a web service (as opposed to a Windows service), even though it will never be called on a website (just internally)?
Is RPC the best method of communicating data between two windows services? There will be a lot of data passed and performance is key.
Development language is C# 4.0
I would suggest using sockets. RPCs have slight overhead over sockets and not worth the effort unless sending structured data.
If performance is key then use a shared memory segment. Look up CreateFileMapping and MapViewOfFile on MSDN. You can start from the aptly named "Creating Named Shared Memory" available at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366551(v=vs.85).aspx
I am taking my first dives in to the WASAPI system of windows and I do not know if what I want is even possible with the windows API.
I am attempting to write program that will record the sound from various programs and break each in to a separate recorded track/audio file. From the reseacrch I have done I know the unit I need to record is the various audio sessions being rendered to a endpoint, and the normal way of recording is by taking the render endpoint and performing a loopback. However from what I have read so far in the MSDN the only interaction with sessions I can do is through IAudioSessionControl and that does not provide me with a way to get a copy of the stream for the session.
Am I missing something that would allow me to do this with the WASAPI (or some other windows API) and get the individual sessions (or individual streams) before they are mixed together to form the endpoint or is this a imposable goal?
The mixing takes place inside the API (WASAPI) and you don't have access to buffers of other audio clients, esp. that they don't exist in the context of the current process in first place. Perhaps one's best (not so good, but there are no better alternatives) way would be to hook the API calls and intercept data on its way to WASAPI, if the task in question permits dirty tricks like this.