3.6 Beta - Playback fixes

[rubbersoul]

Well that's good. I'm not sure what I can do to stop that first pause, but at the very least it shouldn't be restarting from the beginning and I'm hoping that now the random stutterings people were experiencing after the file is already buffered will be gone. Anyone else able to test the newest beta who were previously having issues?

just curious, do you know what is going on here? i've experienced this short stutter after 20s or so on the first track on subsonic for as long as i can remember.

[mr_nobody]

Well that's good. I'm not sure what I can do to stop that first pause, but at the very least it shouldn't be restarting from the beginning and I'm hoping that now the random stutterings people were experiencing after the file is already buffered will be gone. Anyone else able to test the newest beta who were previously having issues?

just curious, do you know what is going on here? i've experienced this short stutter after 20s or so on the first track on subsonic for as long as i can remember.

I _believe_ the player is switching from playing the partially downloaded track to playing the full track and it jumps to the current position in the full file but I'm sure if I'm wrong, the dev will tell us!

[daneren2005]

Well that's good. I'm not sure what I can do to stop that first pause, but at the very least it shouldn't be restarting from the beginning and I'm hoping that now the random stutterings people were experiencing after the file is already buffered will be gone. Anyone else able to test the newest beta who were previously having issues?

just curious, do you know what is going on here? i've experienced this short stutter after 20s or so on the first track on subsonic for as long as i can remember.

Ok, time for some technical explanation. For the media playback I have a onComplete function that is supposed to happen when the file is done playing. If you have slow downloading then the end of the file might be reached in the middle of playing, so it pauses playback until it can continue again, and restarts from the position you were at.

There are three main problems:
1) Some players don't seem to remember where they were at when they reach this function, so it restarts from the beginning. I think I've solved this by keeping track of the position as playback is going on.
2) Before it was doing long extensive IO operations when files were done downloading, which was causing brief stuttering while they happened. I think I solved this.
3) Some players seem to call the complete function even after the entire file is done downloading, but long before that song is over. What I'm thinking is happening is the player is trying to buffer ahead of time, and reaches the end of the file while still downloading, then stops trying to buffer. Then when the player reaches that point it stopped buffering, it stops thinking it was done. From the googling I did I'm thinking this is worse because in JB google apparently increased the amount of buffer ahead by quite a bit. I'm still not exactly sure what I can do about this though. I'm hoping though that as long as it only does it for the first song, and only once, and doesn't just reset back to the beginning, it should be acceptable to most people.

[NTolerance]

Thanks for your work on this! These stuttering issues have plagued the Subsonic Android client for quite a while, so I'll do whatever I can to help test these builds out. I know that the heavy I/O issue has affected me in the past, so it's great that we've got a handle on that. I'm attaching a logcat where the first track paused briefly at about 55 seconds in. I'm not sure if this falls into category #3 from your last post or not. I'm running DSub 3.6Beta 3.

[daneren2005]

Thanks for your work on this! These stuttering issues have plagued the Subsonic Android client for quite a while, so I'll do whatever I can to help test these builds out. I know that the heavy I/O issue has affected me in the past, so it's great that we've got a handle on that. I'm attaching a logcat where the first track paused briefly at about 55 seconds in. I'm not sure if this falls into category #3 from your last post or not. I'm running DSub 3.6Beta 3.

It looks like it probably does. I'm going to post up one last beta a little later that as long as there aren't any recessive bugs will be what goes out. I'm still going to continue looking at some of the issues people are having but I need to get out some other fixes that people are having with regards to crashing and I didn't properly branch the dev code.

[NTolerance]

Thanks for your work on this! These stuttering issues have plagued the Subsonic Android client for quite a while, so I'll do whatever I can to help test these builds out. I know that the heavy I/O issue has affected me in the past, so it's great that we've got a handle on that. I'm attaching a logcat where the first track paused briefly at about 55 seconds in. I'm not sure if this falls into category #3 from your last post or not. I'm running DSub 3.6Beta 3.

It looks like it probably does. I'm going to post up one last beta a little later that as long as there aren't any recessive bugs will be what goes out. I'm still going to continue looking at some of the issues people are having but I need to get out some other fixes that people are having with regards to crashing and I didn't properly branch the dev code.

Thanks for the update. I've done more testing and it looks like the pausing occurs exclusively during the first track of a playback queue. The pausing can occur during the first track between 1-3 times. All subsequent tracks play back flawlessly.

[daneren2005]

That's odd that it happens more than once sometimes. That seems to point to a different underlining problem. And I'm able to reproduce skipping on my Nexus 7 now, so I will still be looking at these issues, but for now as long as there aren't any serious problems with this beta this will be what goes out in this next update.

[NTolerance]

That's odd that it happens more than once sometimes. That seems to point to a different underlining problem. And I'm able to reproduce skipping on my Nexus 7 now, so I will still be looking at these issues, but for now as long as there aren't any serious problems with this beta this will be what goes out in this next update.

If I'm able to reproduce multiple skips during the first track I'll let you know and post a logcat. Otherwise, the single skip happens more often. It's possible the multiple skips were just a fluke.

[mr_nobody]

Noticed a couple things vs. the previous beta:

1. The issue where the last 30 seconds of a song was playing twice with the screen off is fixed.

2. It seems to me the pause in the first track is being handled slightly less gracefully than it was before. Whereas before it really seemed like a brief pause, now it seems like it is also rewinding the track the length of the pause. So let's say the pause is one second (I'm sure it's less than that but for my example, let's say it is), it seems like after the pause you are hearing the one second of the track again that you heard right before the pause. Does that make any sense?

In any case, looks like you are headed in the right direction!

[daneren2005]

Noticed a couple things vs. the previous beta:

1. The issue where the last 30 seconds of a song was playing twice with the screen off is fixed.

2. It seems to me the pause in the first track is being handled slightly less gracefully than it was before. Whereas before it really seemed like a brief pause, now it seems like it is also rewinding the track the length of the pause. So let's say the pause is one second (I'm sure it's less than that but for my example, let's say it is), it seems like after the pause you are hearing the one second of the track again that you heard right before the pause. Does that make any sense?

In any case, looks like you are headed in the right direction!

I was just running a check every 1 second for the position, so maybe I just need to decrease that down to like 200 ms so it's less time you lose. Glad to hear there are no other regressions for you though.

[NTolerance]

We've been talking about the "first track" being part of the issue for a bit, but based on further testing the playback issue can occur when playing any track that's not fully cached. I find that I have better luck if I let the current track get cached fully before I start to play it.

[NTolerance]

I've been thinking that an option to not begin playback until the current track is fully cached would be a welcome addition if the "first track" playback issues are too tricky to solve. Thanks again for your work on DSub!

[mr_nobody]

I've been thinking that an option to not begin playback until the current track is fully cached would be a welcome addition if the "first track" playback issues are too tricky to solve. Thanks again for your work on DSub!

I would use such an option but understand if the dev doesn't want to stir that hornet's nest again right now!

[daneren2005]

Yah while I definitely would like to add an option for that, right now I'm kind of weary about adding it because of how touchy Android's media playing handling is

[NTolerance]

Yah while I definitely would like to add an option for that, right now I'm kind of weary about adding it because of how touchy Android's media playing handling is

It seems you did add the option and it works great! This is the first time I've been able to stream music without skipping for over a year. Thanks!