Skip and replay should be implemented

[seeReadCode]

This will likely require server inputs as I don’t know if those API calls are working currently.

[seeReadCode]

API calls exist for both in the framework. To confirm whether they are implemented in the API.

Here are the URL funcs for reference: https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Pod/Classes/RWFrameworkURLFactory.swift#L50-L56

[seeReadCode]

Needs interrupt to really do anything significant.

[seeReadCode]

Waiting on functionality from @IllyaMoskvin

[seeReadCode]

Working on it presently, should have a PR submitted by Monday.

[seeReadCode]

I believe POST /api/2/streams/:id/next/ is already implemented as of the current develop. It seems to be working well, client-side buffering issues aside. Let me know if it gives you trouble. Alternatively, you can try this APIv1 call:

/api/1/?operation=skip_ahead&session_id={{session_id}}

Replay still needs to be implemented. Please note that GET /api/2/streams/:id/current/ is not meant for replaying the current asset. It returns info akin to the following:

{
  "asset_id": 1,
  "start_time": "2016-08-16T03:09:58.196374",
  "duration_in_stream": 20955,
  "current_server_time": "2016-08-16T14:22:40.652719"
}

Please use POST /api/2/streams/:id/replay/ instead.

Edit: Pasted the wrong APIv1 call. Fixed.

[seeReadCode]

Illya, are you saying, that both of the following are true?

1. That the noted APIv2 POST request will interrupt the currently playing asset and move to the next one.
2. That the feature is deployed to devapi.digita11y.org.

A quick test shows that the currently playing asset plays thru it's end and doesn't get interrupted/faded out. I doubt there's a bug in iOS code for the next function but it's possible.

[seeReadCode]

Yes on both counts. The buffering is playing haywire with it. As far as I can tell, the server pauses the stream immediately, but because of buffering, you won't hear a change for at least 10 seconds. For instance, here are the effects of me playing the same asset several times and sending the next call as soon as I heard a track start:

[16/Aug/2016 15:18:54] INFO <roundwared.stream.start:63> Session 412 - Starting stream
[16/Aug/2016 15:18:57] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 20.46 secs
[16/Aug/2016 15:19:52] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 24.76 secs
[16/Aug/2016 15:20:26] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 17.55 secs
[16/Aug/2016 15:21:00] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 14.53 secs
[16/Aug/2016 15:21:32] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 28.47 secs
[16/Aug/2016 15:22:06] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 29.53 secs
[16/Aug/2016 15:22:39] INFO <roundwared.audiotrack.add_file:154> Session 412 - Playing asset 1 filename: rw_test_audio1.wav, duration: 17.03 secs

In my opinion, the ideal solution would be to forgo serverside streaming in favor of serving files and having the client handle audio mixing and manipulation. But I don't think this is a reasonable course of action at this juncture.

[seeReadCode]

@hburgund: Can we change the pause functionality into "Stop" and "Resume"? Essentially killing the stream and restarting it might be easier than pausing. There's too many buffering issues at play to ever make it seem like a smooth process to the listener.

[seeReadCode]

@seeReadCode: Is there any way to manually dump an audio buffer on iOS? Sorry, I'm not too familiar with Swift. I figure we might be able to manually dump the buffer when resuming from a pause, or perhaps even when skipping to the next file. It won't be smooth, but it seems like a possible compromise.

Something that I've noticed on Chrome, is that if I have a tab open with the stream, and I use the /next function, there is a good 10-15 seconds before it's reflected in the stream. But if I have that tab open, and I use /next, and then open up a second tab with the same stream, that second stream will be on the correct track. Eventually, the first tab will catch up and "skip" to the correct part of the track, once it runs out of buffer.

Still troubleshooting the problem on the server-side. Hoping we can mitigate this without too many changes. A 5-second delay for skipping / pausing seems like an acceptable compromise point, just so long as the tracks don't skip around...

[seeReadCode]

dupe of framework level issue see https://github.com/seeRead/roundware-ios-framework-v2/issues/4

[sinabahram]

Tagging @hburgund as well on this.

[seeReadCode]

@sinabahram i'm copying over issues, this is a closed issue