ybrid / player-interaction Goto Github PK

At the moment pressing pause shifts the stream in time by increasing the buffer and playing it back later. This leads into synchronication issues during skipping (the time delta between button pressed and the actual skip increases).

In context of real time scenarios like news (has to happen every full hour etc.) this shift is also problematic.

I'd suggest not to pause the stream, but to set the volume to 0.

Otherwise, the stream has to be stopped really and a new session has to be created. See also #9.

It seems that since yesterday the stream does not contain any metadata any more.

In case a station offers multiple swappable channels, it would be a nice addition to share the sessionID for all streams.

Currently a new sessionID has to be requested each time the channel is switched.

I open this issue, because I encountered this situation:
Sometimes the playout system provides two alternative items instead of three. The number depends on the background algorithms and the contents available.

We have to take this into account for the UX.

Still, I also think more than three could be technically possible, but the playout system should limit it for the current case.

As our CMS currently only stores an entire URL , I'd prefer to have the PATH_TO_SERVICE in the createSession() response along with the HOSTNAME.
This way we can avoid the need for the radio station editors to split the URL manually when entering new channels to the CMS (which is a common source for errors ;) )

While the metadata which is embedded into the audio stream is very accurate in terms of timing - it is not updated when the skip function is used.

The metadata song information should be in sync with skipped tracks.

During Advertisements the title will be set to ADVERT. Since ADVERT seems to be a track from blur, their album's thumbnail image is loaded.

I'm going to change the title to something biunique @@Advert@@. This tag can be used to display whatever want.

Im currently experiencing the following issue:

When I listen to the Simulcast of the default station in the test App (Title A) and I execute a swap the stream fades to the first alternative (Title B). If I continue to swap after listening to the last alternative (Title D), the stream is not fading to the Simulcast (Title A) but to the first alternative (Title B).

Swap Loop current State: Simulcast -> Alternative A -> Alternative B -> Alternative C -> Alternative A
Swap Loop expected State: Simulcast -> Alternative A -> Alternative B -> Alternative C -> Simulcast

As a user I'd expect to return to the Simulcast instead of the first alternative.

For the implementation of client side DRM features (skip preservation when "killing" the app), it would be nice to be able if a news track "interval" has started. Maybe we could us a simple date stamp or integer that will be embedded into the track. The value would change everytime a new interval is launched.

When the app is restarted it would compare whether a new interval has launched or the last interval is still active (in that case skipping would be disabled until the interval has finished).

Simple browser players do not understand meta data injected in icecast streams. Therfore, meta data should not be injected in that case.

The response returned by the "skip" request currently only contains
{\"status\":0}
According to the documentation it should contain the number of remaining skips.

As mentioned earlier it would be nice to check the validity of a sessionID in case the client needs to be restarted.

There seem to be some issues with the skipCount feedback.
In theory it should be possible to skip 4 times per interval.
(Simulcast->Alternative1->Alternative2->Alternative3->Simulcast).
However when launching a stream we received "skipsLeft:3".
After skipping to Alternative1 this is reduced to "skipsLeft:2" .
But when skipping from Alternative1 to Alternative2 the counter remains at "skipsLeft:2".
Only when we skipping from from Alternative 2 to Alternative3 the counter is reduced to "skipsLeft:1".

Also there seems to be a discrepancy between the results returned by the skip? and skip-info? call.
When reading the results from skip? sometimes the currentSkip is not deducting the stream count. So when he have 3 skips left and call the skip functions it returns "skipsLeft3", but then a call to "skip-info" returns "skipsLeft2".

It would be important to have an reliable skipCount to allow the appropriate display of UI Elements.

As a side note:
I currently have a setup that works like this:
When the answer to a "skip?" call is received I update my UI to reflect the skip count.
However skips have to be reset at the end of a song, which is why relying only on this method is not enough. Therefor everytime the song title transmitted by metadata is received, I call "skip-info?". However here we have the problem, that currently song-metadata in the Alternative streams is always . Maybe it would be possible to transmit the skipCount as part of the embedded metadata.

Currently it is possible for a user to skip the pre roll advertising clips.
In a production environment this would not be desired.

Our current metadata system also incorporates album cover art which it retrieves from google, amazon and iTunes search APIs. While these can also be called by the client, a server side implementation might be more efficient since the content APIs only need to be called once per track and results could even be cached.

Attached find an example for reference:

For contexts where the stream is paused (e.g. in case of an incoming call), the stream should resume afterwards. Currently relaunching the stream causes it to resume in the simulcast.
It would be better if in this case the stream would continue with the selected alternative option.

Also it appears that after a longer break a sessionID will expire. In this case API calls will fail. It would be good to have the possibility to check whether or not a sessionID is still valid.

Some radio stations have more than one channel. At the moment, each time a user switches between channels, a new sessionID is assigned to him/her. When switching back to the station they previously listened to, they will also receive a new sessionID as they are currently not stored.

I'm wondering what would be the best way to improve this situation. We could:

• Store the last sessionId for each channel on the client
• Reuse the same sessionId for multiple channels (server side management)
• keep everything as it is.

After obtaining a sessionID, I'm attempting to set the bitrate of the stream by calling:

https://SERVER/STREAM/ctrl/set-max-bit-rate?value=64000

While the call succeeds I only receive a code 400 message in return.
I'm wondering if the call is actually lacking a sessionID to set the bitrate capping to a specific session.

Throughout the last 2 days I often face problems when trying to connect to the server.
Either the server could not be reached at all or sometimes the audio would drop while playing the preroll advertising clip.
As these events occur randomly after short periods of time, I doubt it has to do with server availability in general.

For creating a connection I used two independent WI-FI Networks as well as an LTE Network.