Re: AVAssetReaderTrackOutput fails with error code -11800
Re: AVAssetReaderTrackOutput fails with error code -11800
- Subject: Re: AVAssetReaderTrackOutput fails with error code -11800
- From: Heinrich Fink <email@hidden>
- Date: Sun, 19 Jun 2011 12:27:55 +0200
Hi,
thanks for sharing your findings! I have modified my example code to use usleep for 1 second every 300 opened songs. This seems to work very well. With this modification I was able to successfully open and close 10 000 songs on the lower priority queue (which would not have been possible without inserting usleep).
best regards,
Heinrich
On Jun 18, 2011, at 21:30 , Zachary Kulis wrote:
> I have some additional information regarding the -11800 error. Heinrich,
> the interesting thing about your script is that you use the global
> dispatch queue. In my test code, I was using an NSOperation and an
> NSOperationQueue to perform each export. However, according to Apple
> docs, NSOperation does not make use of Grand Central Dispatch under iOS.
> Using NSOperation, each operation is spawned as an NSThread; I could not
> complete more than 370 exports without getting the -11800 error. I even
> tried setting the NSThread's priorty to something low (.1), which had no
> effect.
>
> I then tried using the low priority global dispatch queue (like you do).
> As you observed, the application was able to initialize more
> AVAssetReader objects successfully, but I still received the -11800
> error after around 700 initializations. I then added a usleep(250000)
> before starting each export. This slight pause is the secret to getting
> AVAssetReader to init without errors. I think your assessment is
> completely correct regarding assetd exhausting its resources. If you add
> just a slight pause (and use the low priority queue), you should be able
> to export all of your MP3 successfully.
>
> I will file a bug report and reference your ID.
>
> Thanks again,
> Zach
>> Heinrich,
>>
>> Thank you very much for the useful information. I actually succeeded in
>> exporting all 1500 MP3s last night by shutting down all of the
>> extraneous audio resources (I am using a Remote IO to play the exported
>> file) and performing the exports in the main thread. So, there does seem
>> to be an issue when exporting and trying to stream the exported audio
>> file on-the-fly. I am still trying to isolate my exact bug, but it seems
>> like we might be observing the same root issue with assetd and
>> mediaserverd. Perhaps the pausing will work -- my test app is a stress
>> test, so there is absolutely no pausing between successive exports.
>>
>> Thanks again. I will follow up with my own bug report shortly (and
>> reference yours). If I find a workaround, I'll let you know.
>>
>> Regards,
>> Zach
>>
>>> Hi Zach,
>>>
>>> I have recently experienced the exact same odd behavior (iOS 4.3.3). I have already filed a bug with ID 9557175. If you have filed one, too, I suggest you add a comment that identifies your report as a duplicate/related one to mine. I was able to present this issue to the AVAssetReader engineers last week at WWDC. I know that WWDC is confidential but I think it is safe to say that they have looked into it and that they are now aware of the problem (it is a bug). They will follow up on my bug report as soon as they can.
>>>
>>> From my own experience I could tell that the problem arises when the mediaserver-daemon and asset-daemon are exhausted. But there is really no way of predicting the moment of failure (when AVAssetReader fails to be initialized).
>>>
>>> However, I assume that you are performing your export operation as a background task and I have experienced that it is much less likely to run into the bug when you are using a low-priority queue instead of a default or high priority queue. In my case I was handing off the processing task as a block to dispatch_get_global_queue with DISPATCH_QUEUE_PRIORITY_LOW). The issue then still exists, but it might take much longer to encounter the error. You can find this implementation in this test app that isolates the bug:
>>>
>>> http://files.hfink.eu/AVAssetReaderBug.tar.gz
>>>
>>> I have attached this project this also with my bug report.
>>>
>>> Another way to work around the problem could be to pause the export operation for some time after let's say after 200 MP3s for 2 seconds. Maybe this gives the media-server a chance to clean up resources which prevents the error. I haven't tried that yet, though.
>>>
>>> This is my story with this issue so far.
>>>
>>> best regards,
>>>
>>> Heinrich
>>>
>>> On Jun 16, 2011, at 17:37 , Zachary Kulis wrote:
>>>
>>>> Hi all,
>>>>
>>>> I am currently plagued with a most perplexing issue. I am trying to
>>>> export the raw data packets from MP3s that are stored in my device's
>>>> iTunes library. I have about roughly 1500 MP3s stored on my iPhone 4. I
>>>> am using an AVAssetReader and an AVAssetReaderTrackOutput to write the
>>>> raw audio samples. Unfortunately, after about 370 successful exports,
>>>> the call to create/init the AVAssetReader fails with the following
>>>> error: "The operation couldn't be completed. (AVFoundationErrorDomain error
>>>> -11800.)
>>>>
>>>> The problem is, the AVFoundation framework seems unable to recover when
>>>> this error occurs. This means that all future attempts to export an MP3
>>>> (or an M4A file using an AVAssetExportSession) fail immediately with
>>>> error -11800.
>>>>
>>>> Has anyone observed this behavior? I've tried many different
>>>> permutations of allocating/releasing the AVAssetReader. Instruments does
>>>> not report any memory leaks. Does anyone know of a way to "reset" the
>>>> AVFoundation framework once this error occurs?
>>>>
>>>> Thanks very much,
>>>> Zach
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Coreaudio-api mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden