I've been trying to solve this issue for a few weeks now. The issue revolves around a Cordova plugin called cordova-plugin-playlist that utilizes AVQueuePlayer.
The issue is that when a large number of tracks (30+) are added, several of the tracks time out when attempting to buffer. Because of this, AVQueuePlayer is only able to play some of the tracks that I'm attempting to load (it just skips the error tracks when attempting to play them). The tracks that time out are always random. Attempting to add only the first 15 or so tracks from the same list succeeds, so it appears to be directly related to the number of tracks being added.
What I've figured out by logging the requests to my server is that AVQueuePlayer is attempting to buffer all of the tracks all at once, rather than buffering only the current and maybe the next track. When there are 20 or fewer tracks, all of the tracks load and play fine, but when there are 30 or more, the request seems to be too much to handle, and the requests begin to time out before some of the tracks are able to load.
All of the tracks are added via AVQueuePlayer's insertItem method. Is there something about this method that causes a track to immediately begin buffering as soon as it is added? Is there a way to prevent this behavior? I would like only the current and next tracks to buffer. Or am I fundamentally misunderstanding something? Thanks in advance for all your help!
I've solved the issue. In case it helps anyone, it wasn't an issue with AVQueuePlayer itself, but rather with the subclass AVBidirectionalQueuePlayer included with the cordova-plugin-playlist plugin. The issue lies within the overridden insertItem method in AVBidirectionQueuePlayer.m (line 217 in my case).
if (CMTIME_IS_NUMERIC(item.duration)) {
NSLog(#"duration: %5.2f", (double) CMTimeGetSeconds(item.duration));
if (CMTimeCompare(_estimatedDuration, kCMTimeZero) == 0)
_estimatedDuration = item.duration;
else
_estimatedDuration = CMTimeAdd(_estimatedDuration, item.duration);
}
The item.duration call triggers the track to load (and it's called each time a track is added, so it triggers ALL of the tracks to load), which is fine for a smaller number of tracks, but with 30+ tracks, some an hour or longer, my server was overloaded and the requests were timing out.
In my particular instance, it seems that item.duration is never NUMERIC here anyway, so my solution was to comment out the IF statement entirely.
Related
I've build an iOS app that uses the iOS SquarePointOfSaleSDK which returns me a transaction Id and nothing more. Since I need more information about the payment (e.g: method, how many tenders, etc.) I'm calling the RetrieveTransaction Connect API v2 service immediately when I receive the transaction id from the Square POS app and this normally works, but sometimes I get the error described below.
{"errors":[{"category":"INVALID_REQUEST_ERROR","code":"NOT_FOUND","detail":"Location `XXXXXXXX` does not have a transaction with ID `YYYYYYYYYYYYYYYYYYYY`.","field":"transaction_id"}]}
When this transaction actually exists in this location.
I'm guessing the transaction, sometimes, is not available for API actions that fast, but I couldn't find anything in the documentation about this, I'd really appreciate any help or guidance in this, thank you in advance.
Yes, there can sometimes be a small delay between Charge and the transaction actually being retrievable. Unfortunately I'm not sure on how long the delay can be but I'll make sure this gets added to our documentation.
For now, I would suggest that if the error occurs, just to have the code attempt the RetrieveTransaction call again, perhaps looping until it's available. You should probably also include a way to get out of it (after X time or something), just to prevent the rare possibility of an endless loop.
I’m developing a small game where the player owns droids used to perform some automated actions. The easiest example is giving an order to a droid to send him at a specific position. Basically, the users gives it a position and the droid goes there. I’m already using a lot Azure app function and I’d like to use them to make the droid moves.
On the top of my head, I thought about making one function that would trigger every minute, fetch all the droid that need to move then make them move.
The issue with this approach is that if the game is popular, there could be hundreds of droids and I have to ensure that the function execution time stays below the minute.
I thought about just retrieving all droids that needs to move then for each of them calling a Azure app function via its URL to make it execute for this particular droid. In my head, it would parallelize the execution a bit but I’m not sure I’m correct.
I also have to think about using sql transaction or not in order to be sure not to create deadlocks.
The final question would be « how to handle recurring treatment of potentially large amount of data and ensure that it stays below the minute ? »
Thanks for your advice
Typically, you handle such scenarios with queues. Each order becomes a queue message, and then Azure Function is triggered by it and processes the order. It can and will scale based on the amount of messages in the queue.
If your logic still requires timer-based processing, the timer should be as lean as possible, e.g. send the queue messages to a queue which would do the real work.
Im working on an AutoIt application, and today I found out Pushbullet blocked me from reading from their database because I performed too many database reads, this is the actual error message:
"You have been blocked for performing too many database reads per user with this app."
I contacted them to see if I can get my block removed, but while Im waiting for their response I would also like to know what I was doing wrong.
I want to find and display new Notifications, so I was using this code:
$oHTTP = ObjCreate("WinHTTP.WinHTTPRequest.5.1")
$access_token = $PushToken
$oHTTP.Open("Get", "https://api.pushbullet.com/v2/pushes?active=true", False)
$oHTTP.SetCredentials($access_token, "", 0)
$oHTTP.SetRequestHeader("Content-Type", "application/json")
$oHTTP.Send()
$Result = $oHTTP.ResponseText
It was set on a two minutes timer, which I guess triggered the block, but then, whats the right approach to this problem without performing too many requests to their DB (and getting blocked)?
Since this question never got a proper answer. The answer was that I banned a script that was doing a very large number of reads in an inefficient manner. We have better ratelimiting now: https://docs.pushbullet.com/#ratelimiting which should help avoid this issue.
To use Pushbullet efficiently, you should wait for a tickle message from the stream (https://docs.pushbullet.com/#stream) and then fetch the new items (https://docs.pushbullet.com/#syncing-changes). If you only care to read the most recent push, an easier way is to call https://api.pushbullet.com/v2/pushes?limit=1 .
This is not necessary for smaller apps, but when you have thousands of users and you're polling every 2 minutes, it adds up.
I've been working on an app that uses the LBAPI to gather all the leaf work items within our workspace when the app is first ran. This is expected to take some time, seeing as there are over 25,000 and I'm pulling several fields for each item. However, recently the requests seem to be timing out at around the 30 second mark. I would assume this is a setting within the SDK, however I found no way to change the timeout anywhere in the documentation. To make matters worse, rather than returning to the callback function an "unsuccessful" response, there is no response at all, which makes exception handling much more difficult on my end.
I was wondering, is there in fact a way to increase this timeout? And if not, is there are more elegant way to catch that event, rather than simply setting a timer on my end as well, and assuming once it gets to zero without a request there was an error?
Thanks!
30 second default is probably low for 20K page size. Changing pagesize to 10k with limit set to infinity may help. Also, given a Rally.data.WsapiDataStore or Rally.data.lookback.SnapshotStore try
store.getProxy().timeout = 60000;
In an iOS app, I'm writing a class that will be messaged, go do a background request (via performSelectorInBackground:withObject:), and then return the result through a delegate method (that will then be displayed on a map). Everything seems to work right when one request is happening at a time, but I'm trying to figure out how to handle multiple overlapping requests. For example, if a user enters something in a search box that starts a background thread, and then enters something else before the initial background thread completes, how should this be handled?
There are a few options (don't let the second request start while the first is in progress, stop the first as soon as the second is requested, let both run simultaneously and return independent results, etc.), but is there a common/recommended way to deal with this?
I don't think there's universal answer to this. My suggestion is to separate tasks (in form of NSOperations and/or blocks) by their function and relationships between them.
Example: you don't want add image resizing operation to the same queue with fetching some unrelated feed from web, especially if no relationship between them exists. Or maybe you do because both require great amount of memory and because of that can't run in parallel.
But you'd probably want to add web image search operations to same queue while canceling operations of the same type added to this queue before. Each of those image search operations might init image resize operation and place it into some other queue. Now you have an relationship and have to cancel resizing in addition to image search operation. What if image search operation takes longer than associated resize operation? How do you keep a reference to it or know when it's done?
Yeah, it gets complicated easily and sorry if I didn't give you any concrete answers because of uniqueness of each situation but making it run like a Swiss clock in the end is very satisfying :)