Ark player feedback

I listen to WERU program playbacks which use the Ark player, and find it to be generally terrible. The programs play discontinuously. They will play for a time (15-45 minutes, then stop and the player ‘locks up’ and the time counter for the program freezes. If I advance the playback clock (such as from 8:50 to 9:00) and restart playback, the program will play again, but will invariably lock up again and require advancing and restarting.

The result is that it’s impossible to listen to an entire program, or generally more than 30-45 minutes of one at a time. More frustrating is the loss of portions of the program, since the playback advances in 15 minute increments and any program during that time is lost.

Overall, I’m finding the reliability and performance frustrating and unreliable.

I fixed a bug in our server software that probably has been causing trouble on both servers. It certainly has been why the new server stops was stopping at the top of the hour if it was started not at the top of the hour. So for example, if you started a player at 2:45 pm then it would stop at 3:00 pm. But if you started at 2:00 pm then you had a chance of it playing through.

I corrected the bug on both servers and it seems to make a big difference.

If you’re interested, we’re using kaltura/nginx-vod-module in mapped mode.

For example, if the request is

then the mapper response is

  "discontinuity": false,
  "referenceClipIndex": 1,
  "clipFrom": 3000000,
  "durations": [
  "sequences": [
      "clips": [
          "type": "source",
          "path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T080000Z.mp4"
          "type": "source",
          "path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T090000Z.mp4"
          "type": "source",
          "path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T100000Z.mp4"
          "type": "source",
          "path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T110000Z.mp4"
          "type": "source",
          "path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T120000Z.mp4"

Prior to the most recent fix "clipFrom": 3000000 was inside the first of the objects in the clips array.

I think this also explains why the old server works ok for some streams and not for others. Some streams including KCSM had very irregular clip duration (idk why) but this would cause more HLS streams to include a clipFrom field in the wrong place. Streams that produced nicely regular 5-minute clips were less likely to need the field.

And when the firt clip had a clipFrom field then the HLS server would return a series of empty .ts segments to make up the missing duration. Some players can tolerate empty segments while others cannot.

1 Like

Testers might like to try a different player than ours, which doesn’t provide much control.

For example, VLC or this one With other players you can skip and seek which allows more rapid tests. With I like to open the browser developer tools and monitor network. For example

Use a URL like this

Set the station ID. You can use any timestamp since Jan 13, e.g. 20220115T023344Z is valid. Note: use UTC.

There are some discontinuities in the recorded clips owing to snafus while I was working on the server. I don’t yet have a way to display them so you can work around them.

Totally dysfunctional. For example put in a date and time and and and NOTHING CHANGES

Listening to KBCS on Firefox/Edge, the player does not seem to allow any way to scroll ahead (or back) to a specific (arbitrary) time in the player, which is very frustrating if you want to jump or repeat a bit. Is that something that will be addressed in future if not now? Thanks!

1 Like

Reporting good news this morning Tom. Tried three hours from yesterday evening and one hour from this morning. I started all hours at **:45 and all clips played through the top of the hour! Chrome Browser Windows 10.


Hi @KCSMtech , glat to hear. Was that using the widget demo page?

If so, try the active public Spinitron page, which is still using the old server.

1 Like

Hi @Thomas_Paquette, thanks for joining the forum.

The streams are required by US law to be non-interactive(*).

The Spinitron archive player allows you to start a stream in 15 minute increments, to stop and to pause/resume.

The archive server doesn’t have this restriction so if a station wants to implement a player that permits skip and seek, they are free to do so. In due course our player will allow this too but only to stations that indemnify Spinitron w.r.t. that interactivity.

(*) The statutory license permits a service that provides an experience broadly like listening to broadcast radio. Interactively choosing which song to play, or to skip past things you don’t want to hear, is not like radio and offering a service that does would require a direct license. For that kind of thing there’s Spotify and the rest.

1 Like

Yes widget demo was good.

I think I heard the Firefox “chirp” when I tested the old server this morning, I’ll check again and report back.

Played through using on old server 6:45:00 PM past 7:00:00 PM. Firefox and Chrome Windows 10. I could hear the file stitching “chirp” at 7:00:00.

I look forward to that station indemnifying Spinitron in that case, and more flexible listening. Thank you for the reply and your player, Tom.

Audio availability display

Each archive station has a page like this one for KCSM

that displays the audio for that stream available on the new HLS server.

When you hover over a green block using a desktop browser (i.e. not on mobile since touch interfaces don’t have cursor hovering) it display’s the file’s start time and duration.


In this example we see on Friday there’s a gap in KSYM’s archive from about 4:08:20 am until 4:15:03. That was probably due to some disruption upstream from Spinitron’s archive recorder.

If your archive playback stops mysteriously then you can check with this display for the stream in question.

[This makes me think that perhaps we should substitute gaps with some elevator music and a synthesized announcement.]

1 Like

on the Ark players for several programs on WRFI, we have noticed the stream cutting out after the first five minutes or so. Some have attributed this to their phone screens falling asleep, but I’ve had it happen on a laptop, and others have reported the same. Any info on why this might be happening? (I use a Chrome browser (version 97.0) … until something better comes along) on Mac OS Mojave 10.14.6 (and Safari on the iPhone) thanks, Dan Aloi WRFI Community Radio volunteer / on-air host

1 Like

Hi Dan, thanks for joining the forum.

If you give one or more examples of failure that I can reproduce then I’ll investigate to find the cause. Use this WRFI ark player test page (because we’re shutting down the current archive server in a few days and this test page uses the server that will replace it). I just need the date and time to dial in to the player and, if the bug occurs only on certain devices or browsers, then please report that too.

EDIT: This seems to be a problem WRFI had, as the audio kicks back in around 1:27


I’m having a problem with WRFI on Firefox on Windows 10 too (although I’ve tried in Chrome too) The Slow Drift Wed Jan 26 with Andrew Hoffmann on WRFI 88.1FM The stream seems to go quiet after 1hour and 5(ish) minutes I’ve tried grabbing the playlist and using VLC to listen to it, and it does the same thing.

Hi @david, thanks fir joining the forum.

Yes, I agree. If I turn it up I can hear typical noise. And before the music starts back up it sounds like the DJ’s mic is open. Something known in the business as dead air. Things like this could happen if, for example, the DJ were to lose consciousness for a while.

1 Like

Hello Tom, have you fully migrated to the new server yet?

Also (asking for a listener), how long does it take for a listener to gain incremental access to the archive? Here’s a scenario: It’s 10:15 AM and I’m listening to a show from 8:00 AM from that same morning. I can select to play from 8:00, 8:15, 8:30 and 8:45. I can also start the 9:00 AM hour but I can’t access 9:15, 9:30 or 9:45 directly. How much time must elapse before I can access those 1/4 hours?

Thanks, RR

Yes, we decommissioned the the old HLS infra last week.

As far as the archive stream server goes, at about 10 minutes past each hour, the whole of the previous hour will be available. (When the hour turns green here, you can listen to it.)

Our player may restrict things a bit more than that. I’d have to carefully read the code to know for sure. But if you use a different player then this won’t matter.

More detail than you asked for

There is, however, a limit in this feature at present. We are using VOD (video on demand) HLS playlists, which have an explicit end…

VOD playlists aren’t supposed to change over time, i.e. no adding segments to the stream as new program material becomes available, and players fetch the playlist only once. So if at 9:15 AM you request the 8:00 AM playlist, we create a one-hour long stream that will end at 9:00 AM. You have to start the player again.

I experimented with #EXT-X-PLAYLIST-TYPE:EVENT but ran into the problem that players generally start playing the stream at the end of the playlist instead of the beginning. The server cannot control that and we will need to fix it in the players. I haven’t gotten around to it. For now this isn’t top priority although I very much want to do it.

If anyone wants to use EVENT playlists in their player, I can provide them.


Event playlists are now available.

1 Like

Hello Tom,

Just FYI… I had two complaints this week re: ARK player stopping at the top of the hour. #1 Windows 10 Firefox KCSM Jazz Oasis Feb 12, 2022 6:00 PM – 9:00 PM #2 Google Chrome KCSM, Latin Jazz show, 2/13/22, 2pm-6pm

All for now.

My first post, I had emailed about this awhile back but no response.

It seems all the problems here started when you changed from the old listener log to the new one. I have many listeners who try and try but can’t get on as the player stops after a few minutes or seconds. I recognize some on the log as regular listeners who used to listen for hours. The sad part is they usually give up and don’t try again for a week or so. Sorry but I don’t have any browser info for those.

The other problem I see is I have listeners who I know listen for 3 hrs to the entire show but on the log they all show up around 1hr 20 min or so ? The previous 5min increment log showed them listening for 3hrs. A week ago I sat and talked with someone and listened to my own show with them for the whole 3hrs and sure enough it showed up on the log as an 1hr 20min or so.

All I know is things worked better/more consistently before.