Bug here!

[Vienta]

Hi.Thx for this awesome engine.It helps me much! But there this a bug here,when in bad network, example,prebuffer on 30%, I drag the slider to 70% for a moment,then I again drag the slider to 20%(below 30%),and it can not play until it prebuffer to 70%. I think 30% below was prebuffed,I hope it can play at once. This maybe a bug,right?

[ap4y]

I see, this is not really a bug, rather limitation of the implementation/design of the HTTP source. Basically, when you slide to the area outside of the downloaded data, http source will lock current thread and continue downloading asynchronously. Once data will be downloaded, lock will be release. Without locking decoding thread, playback will stop since there will be no data for decoder.

Possible improvements will be:

• Support of the Range http header, if http server supports it;
• Don't allow to search outside of the buffered area in UI.

I will leave this issue open, as there is not much library can do about it. I tried to implement straightforward and simple streaming, but streaming problem is quite complex and may require changes according to your expectations.

I'm still open for suggestions. Let me know, if you see possible improvements of the library that will help you.

[Vienta]

Thx for your reply! Streaming problem is quite complex.https://itunes.apple.com/cn/app/wang-yi-yun-yin-le/id590338362?mt=8. This application solved this problem.And I also think this application is perfect.

I'll continue follow you and this great engine. Hope this engine can be more powerful! Thx!

[Vienta]

Hi! Another bug here.When playing in Wifi,I switch the network to 3G,the HttpSource receive failure, then it can not play out of the prebuffer.

I wonder if you will continue to write this engine?

[ap4y]

This is sounds like a file got corrupted somehow. Current caching system is based on a simplistic implementation of the http downloads, so there is a chance of file corruption during transfer. You can upload corrupted file from the device and check what is wrong with file, or you can mail it to me.

Regarding question about writing the engine. I try to investigate and fix all issues with current code, I also consider implementing user requested features if I find it appropriate. This library emerged from my personal project and I still use it myself on a daily basis. As you may notice it has quite a diverse set of features, so it's hard to use all features at the same time. I personally more interested in hi-res(192/24) audio and I mostly use local files on device. I don't listen lower quality audio files and don't use http streaming as much. So it will obviously result in less polished implementation, but it doesn't mean that this part is not maintained. I had number of bug reports over the past year and I fixed most of them, as always contributions are welcome.

I also want to clarify my position regarding streaming. As I previously said http streaming and caching are quite a complex problems and I believe implementation should be tailored to your server side implementation. You may find numerous approaches to this problem and most of them will be valid for the specific situation. Current implementation again was useful for my use case: UPNP support in local network, where I could expect stable network environment. So you may need to provide some improvements to the current code or implement you own sources.

[Vienta]

Thx!

I've solved the httpSource receive failure bug, add a reconnect method can solve this.But now I find a more bigger bug——in iOS8, the engine only can play until current playing track all cached. It's quite terrible!

[ap4y]

I will check streaming with iOS 8 over the next couple days and will let know how it goes. Thanks for the report.

[Vienta]

Thx!

I'm trying to solve this in iOS8 ,too. Hope can solve it as soon as possible. Best wishes!

[Vienta]

Hi!

I tried and found this callback function--audioFile_ReadProc in CoreAudioDecoder.m file.I find in iOS7 , the inPosition can stable increase,but in iOS8,it rapid increase to a large number which I guess is the audio total length.I think this maybe the iOS8's bug! What do you think? Do you have any idea?

Thx!

[Vienta]

Hi! I have sent you a email. Hope you can reply. Thx!

[ap4y]

Yeah, sure.

[ap4y]

Ok, I was able to figure out what is going on. I tried to play couple mp3 files over the http source and every time ExtFile API tried to read id3v1 tag, which is always last 128 bytes in file. It is happening even when there is an id3v2 tag at the beginning of the file. As far as I remember, in previous version of iOS it didn't happen.

From mp3 decoder perspective it's a valid logic, there is no way to figure out which tag format file is using. But I'm not sure how decoder resolves between 2 different tags once it read it.

What can I do, is to return empty data when decoder trying to play last 128 bytes over http source. So basically drop support of the idv1 tags for http source.

[Vienta]

Thanks for this detail reply. So, can solve it?

[ap4y]

Hey @Vienta I just pushed the fix, let me know if it works for you.

[Vienta]

Hi @ap4y Thx! I'll try it.

[Vienta]

Hey @ap4y I've tried and now can play well in iOS8.Thank you very much! But I still have a question that why seek to a new time it can not play at that time immediately but play some packet before?

Again,thanks for your help! Best wishes!

[ap4y]

I'm not sure If I understood your question correctly, but I will try to answer anyway :) When you seek to the area that was not yet downloaded engine obviously can't do much, if source will return empty/incorrect data for the decoder, decoder will not be able to decode and playback will stop. So obvious solution is just to lock whole processing thread and wait till data arrive. That is what happens internally. Hope this makes sense.

[Vienta]

Sorry for my expression . I understand what you say.I know seek to the area that was not yet downloaded the engine can't do much.In fact,it's really hard to express clear. When I play a local file which total time is 160s, example,now it is playing in 30s, I drag the slider to 50s,the engine may play like this: 31s、32s、33s,then 50s、51s、52s...,I want it can play immediately like this:50s、51s、52s、53s、54s... Hope you can understand:)

[ap4y]

Ok now I think I understand. Short answer is seek doesn't flush already buffered data, this is kind of related to #25. It was designed like that, if this data will get flushed, pause due to seek may be noticeable (new data have to be pre-buffered). With current implementation this pause is quite small but seek is less responsive. It's quite unconventional and it annoys me a bit lately too, so I may make flush optional, so it can be configured.

[Vienta]

Yes, it is. Thank you for wasting time to help me and my company!

[rperney]

Hi all, I do have the same problem and I am very looking forward the new flushing option :) In my case, the bug is also present when I press my "next" button, even if I ask DataFlush:YES

Regards

[ap4y]

Sorry, for the delay. Was a bit busy, still have this on my TODO list for the weekend. Will let you know once it finished.

[ap4y]

Seek with flush added in 5f6a673

[Vienta]

Great! Thx!

[rperney]

Thanks ! I added the input flush in the

• (void)setNextUrl:(NSURL *)url withDataFlush:(BOOL)flush method as well, because I add the same bug when I wanted to play next or previous track in my player.

Regards

[ap4y]

I guess that's reasonable thing to do, I will add it to the master too.