"Desktop Computer" vs Mobile Listening

[onsceno]

I've been battling this for quite some time and unfortunately, it's been impacting an incredibly reliable feed.

Long story short, I've done as much troubleshooting with the feed provider for Delaware County 911 - Sheriff, Fire and EMS (Delaware County 911 - Sheriff, Fire and EMS Live Audio Feed) and all software/hardware on my end as possible but am coming up short. It is important to note that Kevin has been INCREDIBLE in listening to the issues at hand and nothing short of a gentleman in attempting to dissect this, as well. But between the two of us, we're at a technical dead end.

When listening to this feed using a Dell laptop at home, Mac desktop at work or otherwise - all with difference ISPs - I get about 8 minutes or so in before the feed stops, does not restart and just times out. On the other hand, when listening via a cell phone or iPad connected to the same WiFi, there are no issues when connected to these ISPs. The problem seems to be isolated to an actual computer, though no rhyme or reason as to provider or location. (Insert head scratch here). Of my "usual suspect feeds" I listen to, unfortunately, it is the only one I can get to replicate the issue.

Is there anything else I should be looking at? Any help is greatly appreciated!!

 

[Deziel0495]

When listening via computer, are you using a browser or a media app and if so what one?

I'm assuming you've checked over the sleep/power settings of your desktop? In some cases, especially with laptops if the device/screen goes to sleep it may stop playing.

 

[onsceno]

Good afternoon, sir! I'm using a browser (Google Chrome) when using a computer. That part never changes, so hoping that may help on your end.

As for sleep/power settings, that's correct - everything is "wide open" and is not set to time out/reduce power, etc.

I should also note, I typically run the Greene County AND Schoharie County feeds at the same time with no interruptions on either of those.

 

[saioke]

I was going to say that it's possible your ISP is detecting and mislabeling the traffic and throttling your connection, but you say you've used different ISPs and the same thing happens so that can't be the case. Perhaps you could try a different browser and see if it changes. Firefox is always my go-to.

Do you run an external firewall or firewall software besides the default that Windows uses?

 

[onsceno]

Saioke, I can certainly try FireFox over the weekend to see if that helps. As I type, the ONLY other variable I can think of at this point is perhaps this feed legitimately uses both RIGHT and LEFT speakers and certain audio is driven to one or the other.

In terms of firewall, only the default on these babies.

 

[Bote]

Chrome can put tabs to sleep if it thinks you're not using them frequently or recently. Perhaps that can be disabled? IDK as I use Firefox as my daily driver.

I've noticed that sometimes certain Bcastify feeds playing on the HTML5 web player will just stop at random times. I've never investigated this as it's always a feed I only listen to for a particular incident so there's no history with me. WinAmp and VLC play them without interruption.

It's possible that the buffer allocated by web player is too small to ride out short hiccups in the data stream. I run my own Icecast server for my feeds and when I set the buffer in WinAmp to, say 0.5 seconds, it chops up the introductory announcement; when I lengthen the buffer to like 2 seconds the introductions play smoothly. Maybe the HTML5 player buffer is too small and once it gets starved of data it just stops playing with no retries.

It's not throttling by the ISP. They're concerned with users gobbling up huge chunks of data with video streaming. Video streams consume 10 to 50 times more bandwidth than these audio streams. 16 or 32 kbits/second is barely noticeable to them compared to a video stream that gobbles up 1000-2000 kbits/second. That tiny bandwidth can squeeze right through throttling in my experience.