View previous topic :: View next topic |
Author |
Message |
Nonapeptide
Joined: 08 Sep 2012 Posts: 40 Location: Scottsdale, Arizona
|
Posted: Fri Oct 25, 2013 5:09 pm Post subject: Thoughts on listeners suddenly jumping forward in time? |
|
|
No DeLoreans involved!
I'm streaming MP3 encoded audio to Icecast 2.3.3-kh8 on Windows Server 2008 R2. A very small population of listeners (Probably one out of a thousand) can hear the audio just fine, but they said they've experienced a strange issue where they suddenly skip forward several minutes. My assumption is that those specific clients are lagging behind because of latency, but they're not outside of the queue-size limits on IceCast. They're not dumped from the stream, but instead there is some kind of local cache or buffer that hits a limit and then seeks fresh data from the stream.
I know this isn't a IceCast problem per se, but was hoping that other IceCast admins had seen similar listener behavior and what they did for it (if anything). I'm assuming that it's 100% on the client's side, but I've been wrong at least a few times before. |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Oct 26, 2013 1:33 pm Post subject: |
|
|
The only time listeners are placed further up the queue as such is if they reconnect (can be quick but should show in the logs) or something like a move or fallback/override occurs. I suppose it is possible that a player can detect a case where there has been plenty of data coming arrived and has decided to halt playback from where it is and resume after skipping over a certain amount. The latter case would be player specific but it's not unheard of for players to adjust playback by certain amounts to keep things in sync, mainly due to clock timing differences.
Icecast itself does not move listeners along the queue unless data has been sent and that is only by the next block.
karl. |
|
Back to top |
|
|
Nonapeptide
Joined: 08 Sep 2012 Posts: 40 Location: Scottsdale, Arizona
|
Posted: Wed Oct 30, 2013 7:43 pm Post subject: |
|
|
karlH wrote: |
The only time listeners are placed further up the queue as such is if they reconnect (can be quick but should show in the logs) or something like a move or fallback/override occurs. |
That's pretty much what I thought and have seen in logs.
karlH wrote: |
I suppose it is possible that a player can detect a case where there has been plenty of data coming arrived and has decided to halt playback from where it is and resume after skipping over a certain amount. The latter case would be player specific but it's not unheard of for players to adjust playback by certain amounts to keep things in sync, mainly due to clock timing differences.
Icecast itself does not move listeners along the queue unless data has been sent and that is only by the next block. |
In my case it appears that the only two listeners that have squawked about this issue are iPhone users listening to an MP3 stream on the IceCast server. I can't yet get more information about version of iOS and whatnot because it's a bit of a game of telephone (no pun intended), because I'm a consultant for a business that provides streaming services, my client's clients are content creaters, and my client's, client's, clients are the listeners, so getting a consistent report on any trouble is a bit of a fox and hound scenario. Or maybe it's more like a fox and hound and horse and rider issue.
If I learn more, I'll post it here, but I'm pretty unconcerned with it all so far. The mount points are using dump files to save broadcasts to files on the IceCast servers, and the archived audio files have no skips in them at all. It appears to be a transient, inconsistent client issue. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2002 phpBB Group subRebel style by ktauber
|