Recent Posts

With the recent switchover to the new dedicated free feed, let us know if you're still having chop issues.  We upgraded our connection, as well.

MDg

I've had the same problem on my end.  I'm also on the east coast using the 48K AAC stream.  It's fine at the beginning (~30 mins - hour or so) and then the problem starts occurring.  My temporary "workaround" was to dramatically increase the buffer size in Winamp from the default (I think 64K?) to a couple of meg.  That keeps the dropouts from occurring, but then I would hear the "speedup".  I was speculating that perhaps some packets occasionally never make it across, and that with the small buffer it manifests itself as short dropouts in the audio stream, and then with the large buffer Winamp just plays the [ packet after the lost one ] right after the [ packet before the lost one], therefore causing the perceived speedup.  I'll try to collect some statistics over the next few days if the problem is still occurring.

We're looking into it.

MDg

Its actually been happening a lot over the past 2 weeks. It's fine right now as of this posting, but last night around 10 p.m. it was doing it again. It's definitely not something on my end.

It's happening to me right now. 11:20 a.m. Eastern. 128 kbps stream. In winamp it actually says it's buffering.

considering this thread is almost a month old, and issues reported to me for the behavior at the start of the message seem to not be happening anymore, i can only conclude that it might be another issue that may not be related to this original issue. are you sure you don't have any other traffic on your network that might cut into the streaming bandwidth? I'm listening on my mobile phone on 128K and it's fine right now.

It's happening to me right now. 11:20 a.m. Eastern. 128 kbps stream. In winamp it actually says it's buffering.

Thanks for the info.  I'm on EDT, so 3 hours ahead of PDT.  Actually last night the server played perfectly for hours, but then this evening it's acting up again.  I'll see if I can get a recording of it happening -- maybe it's some goofy network glitches between here and the JAR servers.  

It seems like it's happening for you around the same time.. not sure if that's entirely true or not.

Thanks for the info.  I'm on EDT, so 3 hours ahead of PDT.  Actually last night the server played perfectly for hours, but then this evening it's acting up again.  I'll see if I can get a recording of it happening -- maybe it's some goofy network glitches between here and the JAR servers.  

what timezone are you listing those in? all Japan-A-Radio servers and services are only tracked in the Pacific timezone. It's helpful to give times you experience that problem in our timezone correctly to help speed up the issue of finding a problem. You say the bitrate never dropped out, but also say you think it might be a server problem. I'm not sure how that would be the case, since, again, the stream never dropped out. It could be somewhere else on our network. It would probably help if you were to get a recording of it happening and sent it to us for us to hear it, because I listen all the time and don't hear it happening.

I have some more data here after doing some detailed analysis:

* Throughout all the times the music would "speed up", "slow down", or get choppy, the download byte stream stayed steady (i.e., no interruptions in data).  I could tell this by watching my system's bandwidth graph using a utility called "DU Meter".

* After streaming at 192 kbps tonight for one hour from 12:20 AM to 1:20 AM, there were 16 disruptions in the music where it sped up and/or slowed down and/or had breaks/pops.  Disruptions occurred at 12:22, 12:35, 12:43, 12:45, 12:46, 12:48, 12:54, 12:56, 12:57, 1:00, 1:01, 1:05, 1:08, 1:09, 1:10, and 1:16.  The disruption at 12:48 AM was a 5-second break in the music while the stream continued sending data as normal at 192 kbps (as verified by the DU Meter graph).

* Next, I tested the stream for 20 minutes at 160 kbps from 1:26 AM to 1:46 AM: there were six diruptions total, occuring at 1:33, 1:34, 1:36, 1:38, 1:41, and 1:43.  Six in 20 minutes equates to 18 in one hour, which is very close to the 16 disruptions in the hour I monitored the 192 kbps stream.

* As a final test, I monitored the stream for 30 minutes at 128 kbps.  This time I had seven disruptions in 30 minutes, which works out to 14 disruptions in an hour, again similar to what I saw for the 160 kbps and 192 kbps stream results.  Between 1:46 and 2:16 AM, disruptions in the 128 kbps stream occurred at 1:48, 1:52, 2:01, 2:04, 2:06, 2:08, and 2:15.  

I want to reiterate that the actual byte stream from the JAR servers remained constant and steady throughout all my tests tonight.  Also, this does not occur when I stream other Internet radio stations, YouTube, or other streaming media.  It occurs only on JAR streams, and is happening under both Winamp and Windows Media Player 12 (this is on Windows 7 64-bit).  

Anyway, I don't know what to think at this point.  It looks like a server issue of some sort.