MP3 playback: CRASH (w/o exception) when player is closed during prefetch

[cryptoalex]

Same issue happens not regularly on Nokia N95, Nokia E51, Nokia E71.. Seems to be critical issue: midlet just crashes without errors or exceptions (I am sure on this since all of the places are covered with catching Throwable exceptions and logging).

MMAPI.Player is created using HTTP URL pointing to remote MP3 file.
The user wants suddenly to stop the prefetching process (started with player.prefetch()) - for example to change the song or do something else - calling player.close() from some thread may lead to application CRASH!

Already tried to stop the player first and later player.close() - same issue is reproducible..

Is there any reliable and SAFE way to close MMAPI.Player when the latter is being prefetched???

[grahamhughes]

I'm not surprised this is a problem. The way to do it is: wait until it's prefetched before trying to change its state again. Use a PlayerListener to do this.

If you're fetching a large amount of data from a remote source, I suggest you realize() the player before prefetching it. Use a PlayerListener to detect the end of the realize process, then prefetch() or close() it, depending on situation. You may be able to realize() more Players than you can prefetch().

Graham.

[cryptoalex]

Hi, Graham.
Thanks for the answer.

I'm not surprised this is a problem. The way to do it is: wait until it's prefetched before trying to change its state again.

Yeah, to bypass the situation this is the only possible solution, but the requirement is to do fast-switching between the songs upon user's request. By the way in case if I leave the prefetch thread working and try to prefetch another song in the same time - MediaException ("prefetch error -4" - which means No Memory) occurs pretty often. So it'd be better somehow to stop/cancel prefetch process not to occupy the heap and not to wait for prefetch to finish (it could be minutes depending on the network connection!). Unfortunately I do not see the workaround on this situation so far...

If you're fetching a large amount of data from a remote source, I suggest you realize() the player before prefetching it. Use a PlayerListener to detect the end of the realize process, then prefetch() or close() it, depending on situation. You may be able to realize() more Players than you can prefetch().

Yes, but it takes longer for device to prefetch the song than to realize the player, so it usually happens that I rather need to cancel prefetching than detect this situation before prefetching is started.

[grahamhughes]

Yes, but it takes longer for device to prefetch the song than to realize the player, so it usually happens that I rather need to cancel prefetching than detect this situation before prefetching is started.

Really? I would have expected realize() to take longer (as this involved fetching the data). Remember that a prefetch() on an un-realize()d Player performs an automatic realize(). But, I've been surprised before, so if you've tried both, I'll take your word for it.

Since most Series 60s can cope with more than one simultaneously prefetched Player (this certainly applies to MIDI players, not sure if it also applies to MP3 players), you might get away with allowing the currently-prefetching player to continue in one thread (and close it when it's finished), while prefetching (or at least, realizing) a second player on another thread. You'll need to cope with a rapid sequence of sound shifts causing an exception (when you can't prefetch any more players).

Hmmm... did you say it was an HTTP URL? Unless you've managed to achieve some kind of streaming, then the phone will be downloading the entire file before playing starts, so you might be better to download the file into a byte[], and then play that (or not). Beware that, on some phones, you will hit a limit to the number of simultaneously active HttpConnections. Well, probably all phones - the limit will be at least 64 on Series 60s, but could be as low as eight on Series 40.

Graham.

[cryptoalex]

Really? I would have expected realize() to take longer (as this involved fetching the data). Remember that a prefetch() on an un-realize()d Player performs an automatic realize(). But, I've been surprised before, so if you've tried both, I'll take your word for it.

Well, the problem is with a long-running call. Not a big issue of the nature of this call: realize or prefetch, but the issue is in inability of application developer to cancel the call asynchronously. I think of this problem as of an important issue which is somehow still present in the latest firmwares and KVMs.

Since most Series 60s can cope with more than one simultaneously prefetched Player (this certainly applies to MIDI players, not sure if it also applies to MP3 players), you might get away with allowing the currently-prefetching player to continue in one thread (and close it when it's finished), while prefetching (or at least, realizing) a second player on another thread. You'll need to cope with a rapid sequence of sound shifts causing an exception (when you can't prefetch any more players).

This is what I already did, but as I mentioned in the previous post this may lead to NoMemory exception thrown by MMAPI as MediaException with "-4" code (why not to throw OutOfMemory here by the way, Nokia?) because we'll have two simultaneous prefetching threads (and I have already reproduced this exception pretty easily).

Hmmm... did you say it was an HTTP URL? Unless you've managed to achieve some kind of streaming, then the phone will be downloading the entire file before playing starts, so you might be better to download the file into a byte[], and then play that (or not). Beware that, on some phones, you will hit a limit to the number of simultaneously active HttpConnections. Well, probably all phones - the limit will be at least 64 on Series 60s, but could be as low as eight on Series 40.
Graham.

You are right on the fact that Nokia device will download the entire file when prefetch is called. By the way (sorry Nokia) SE device (SE K850, if to talk about the model I saw this behavior) uses buffering approach to play HTTP media instead of buffering 100% of the file like on Nokia device.
I think it is an idea to make a different approach for Nokia device (SE behaves better with the current approach) and to make manual prefetching to external file and to cancel the download if requested by user. However, if the thread will reach the prefetch call on the local file created up to the time of user's request, we'll still have the same issue.

Thanks for the answers, Graham.

[grahamhughes]

Ultimately, your problem is that there is no way to terminate a blocking operation. This will be true also of reading from an HttpConnection (where, again, the entire response will be downloaded before you have a chance to handle it).

If the server is under your control, you could build some mechanism for splitting the file into a series of chunks, and download them separately. (You might even be able to specify "Range: bytes=start-end" in the header, most HTTP servers will support this, but it might not get through a proxy.) Then you can at least abort the process sooner. If you organize it correctly, you should be able to discard all the data that's been downloaded so far (minus the currently-downloading chunk) immediately, and avoid OutOfMemory problems.

Sorry, I can't give you a definitive fix, but I hope this helps a little.

Graham.

[cryptoalex]

Ultimately, your problem is that there is no way to terminate a blocking operation. This will be true also of reading from an HttpConnection (where, again, the entire response will be downloaded before you have a chance to handle it).

Are you sure? What makes you think so about HttpConnection? I wrote a small test where a connection was created to read a big MP3 file (about 8 MBs): InputStream was opened pretty fast (sure that it didn't read all 8 MBs in one shot), after that I started to read from the stream and could cancel the reading asynchronously without a problem by closing the InputStream. No crash, seems to work smoothly.

Sorry, I can't give you a definitive fix, but I hope this helps a little.

Thanks anyway, I will head the way with manual prefetching instead of MMAPI's remote prefetching.

But, still, if Nokia has seen this topic, please do something with asynchronous closing of Player, this is really necessary. Let it work like with InputStream closing. Let the prefetch() throw MediaException if player was closed asynchronously. But do not force the developers to wait for prefetch to finish.

[Tiger79]

after that I started to read from the stream and could cancel the reading asynchronously without a problem by closing the InputStream. No crash, seems to work smoothly.

That's why Graham was talking about the HttpConnection not the InputStream... those two aren't the same, you can create a httpConnection object and attach an InputStream to it... Still if you close the InputStream that doesn't mean you are closing the HtppConnection...

[cryptoalex]

That's why Graham was talking about the HttpConnection not the InputStream... those two aren't the same, you can create a httpConnection object and attach an InputStream to it...

But the issue is to stop/cancel/break the long running procedure (like realize/prefetch in MMAPI). If we talk about manual data prefetching with HttpConnection: What is the longer operation: opening HttpConnection or downloading MP3 files with InputStream opened by HttpConnection?

Still if you close the InputStream that doesn't mean you are closing the HtppConnection...

I break the reading(realizing/prefetching) without application crash - this is the result I can't achieve with MMAPI! And after closing InputStream I can close HttpConnection of course.