Webcast archive service

Spinitron is developing a Webcast Archive service provisionally named Spinitron Ark. (We can simply call it Ark here.)

See it in action at https://spinitron.com/WZBC/ navigate to any past playlist and look for the player. Other stations currently testing should feel free to invite you to check out theirs.

Description of the service

The Ark system consists of these parts

  1. Recorder connects to a stream and makes audio data files
  2. Storage for two weeks worth of audio data per stream
  3. Server gives access to the audio data over the internet
  4. Player runs in the listeners browser (or phone), gets the audio data from the server and converts to audible sound

Spinitron will

  • offer the recorder, storage and server as a subscription service for a monthly fee (pricing below),
  • integrate a web player into public pages on spinitron.com for clients that subscribe to both Ark and Spinitron playlist management service,
  • provide a web player widget that any Ark subscriber can integrate in their web pages.

Listeners can start the archive player at any point in time within the last two weeks that the webmaster provides. Public pages on spinitron.com will provide a variety of starting points, see below for details.

Ark subscribers will have access to the following management tools

  • Numeric and graphic display of current and historical audience size
  • Log of each listener session including the listener connection timestamp, archive start point, listening session duration, and the listener’s IP and approx. geographic location
  • SoundExchange formatted reports of use will be available for clients subscribed to both Ark and Spinitron playlist management service

Billing and pricing

For a fixed monthly fee of your choice you receive a nominal monthly data transfer allocation. No down payment. No commitment.

We quote the data transfer allocation in terms of listener hours. When a person connects to your archive and listens for one hour, one listener hour of your allocation is consumed. This is the same kind of thing as Aggregate Tuning Hours (ATH) used in the Reports of Use and Statements of Account for your live webcast.

Listener hours for each fee tier depends on stream bit rate. Higher stream bit rate consumes the data transfer allocation faster than lower. The listener hour allocation for a number of different stream bit rates is shown in the table. Higher tiers follow its simple formula.

Monthly fee 64 kbps 96 kbps 128 kbps
$20 4,500 3,000 2,250
$40 9,000 6,000 4,500
$80 18,000 12,000 9,000
$120 27,000 18,000 13,500
$160 36,000 24,000 18,000
$200 45,000 30,000 22,500

For example, with a 128 kbps stream, for $40 you get 4,500 listener hours over a month. If 45 people each listen for 100 hours during the month, that would consume the whole allocation. So would 500 people who each listen for 9 hours.


Since you may not have a good idea of your archive’s listenership, we allow you to consume more than your monthly allocation so long as you switch up to a higher tier in subsequent months. We won’t cut off service once your month’s allocation is exhausted, instead we will notify you and ask what you want to do going forwards.

How to choose your tier

If you know anything about prior archive audience size then we can factor that in. Otherwise we’ll basically use trial and error: we’ll agree an initial estimate, choose a tier, monitor usage to see what happens and, if necessary, choose a different tier next month. Our overage policy supports this process.

Your live webcast’s monthly ATH might be useful for the initial estimate. For example, if your monthly webcast ATH is around 10,000 and you have a 128 kbps stream then the $80/mo tier allows nearly as much listening to the archive.

Project status

As of Sep 1, we are testing the service with ten Spinitron stations using provisional software.

The recorder, storage, server and player parts of the system (described above) are all working. The management features that allow you to monitor usage and see logs are not ready yet.

The storage and server parts use AWS S3 and appear to be reliable.

Each archive’s recorder uses an instance of FFmpeg on AWS EC2. We’re monitoring and logging the status of each recorder instance to get an idea of reliability. The recorder’s connection to your stream is inherently unreliable and there’s nothing we can do about that but we need the recorder to be robust no matter what your stream does. It’s worked well this week (ending Sep 4) but we need more experience and performance data to gain confidence.

The web player works but is pretty basic right now. We plan to deploy an upgraded player next week. There’s a widget version that you’ll be able to use on your web site. The new player allows set arbitrary start points for archive playback meaning you/we can put play buttons on web pages that start the player at any dates and times. We will use it to put play buttons on spinitron.com public pages as described below.

How to use the service

As of today (Sep 4) we’re not ready to take on more test users. We need a few more weeks to test the player, fine tune the recorder, develop the management tools, and gather feedback from testers.

After that, how to use it depends if you are a Spinitron client already. If so, we can take care of everything. You just choose a pricing tier (see above) and monitor usage as you please. The archive player will appear in your spinitron.com public pages.

We will support integration of archives with your web site. There will be a player widget you can use and some of the current web integrations will work. Other details TBD.

If you’re not a client of Spinitron’s playlist management service then it’s the same except you don’t get spinitron.com public pages and need to use the player widget on your web site.

Copyright, licensing and SoundExchange

We operate the Ark service on the assumption that it is part of your webcast service that you operate under the statutory license. You assume liability for your compliance with law, regulations and procedures with copyright performance royalty organizations.

Archive listening counts just like live webcast listening for purposes of reporting and audience size tracking. The listener hours of your archive count towards your webcast service’s Aggregate Tuning Hours (ATH).

The consequences depend on the rates and terms your webcast operates under: Public Radio (CPB/NFCB), Educational, or CRB.

  • Educational and CRB webcasters must limit their monthly ATH to 159,140 to qualify as Minimum-Fee Webcasters.

  • Educational webcasters must limit their monthly ATH to 80,000 to qualify for the reporting waiver.

  • Statements of Account (monthly for CRB, annual for Educational) include statements of your monthly ATH.

  • You must include the songs Ark users listen to in the Reports of Use you send to SoundExchange (CRB and Educational services without a reporting waiver).

  • CPB/NFCB webcasters that report to NPR must process the archive server connection logs into NPR format and merge them with the live webcast streaming logs.

Ark users can use the management tools to

  • obtain listener hours for their archive for arbitrary date ranges
  • obtain listener session logs

Clients of both Ark and Spinitron playlist management can also use Spinitron to

  • prepare SoundExchange Reports of Use
  • prepare NPR-format streaming log files

Thanks, Tom!

Here’s the $64,000 question: how soon is “soon” ? :wink:

For $64,000 I’ll give you whatever answer you like best.

This really is exciting. Please let us know if we can provide you with any information or feedback. I know that everyone would like to get their archives up and running again, if we are down for a little bit, listeners will appreciate it even more when it comes back on line! I think that since our schedules are already “built” on your platform, and many of us are already sending a stream to Radio Rethink, it’s like a Reese’s Peanut Butter Cup with Chocolate and Peanut butter combined. I know there’s a lot more to consider in terms of servers, streams, etc. We truly wish you every success on this endeavor and can’t wait to use it!

Hi Tom,

When should playback first be available to listen? Immediately or sometime after? Are you using the same stream that is being sent to the recognition service to record?

Thanks, Rene

We would be happy to be a beta!

We started recording from your stream yesterday morning. So you can try it out starting with any playlist after 9am yesterday. For example


Yes, I expect it’s the same stream that the recognition uses.

You should be able to start listening to a replay about 10 minutes after it happened. So if a playlist has a start time of 1pm them by 1:10pm the you should be able to click the play on the playlist web page it’ll work.

Actually, I take that back. It might. :P The current player is simplistic. What I just described above is the revised version I’m working on now.

Try it and see what happens!

The 10:00 AM show will not playback. I had to switch server/ encoders this morning just after 9:00 AM. The 9:00 AM show played for a few seconds, then stopped when I switched encoders. Appears it did not reconnect after that?

Right. I had failed to include Restart=always in the service unit for the ffmpeg process that connects to streams. That should help prevent this sort of thing.

But it reminds me that we should try to make the player to be robust in case of missing or incomplete archive chunks.

1 Like

Great, I’m contributing to the success of this beta already!

This is really great, Tom. I’ve been thinking about some things as it relates to KXCI. I’m just letting it all percolate for now.

I’m trying to think about how to message to the programmers about the new setup. And then how to convey to listeners how to get to shows. I suppose I could break down and make some short videos, but I tend to write up a bunch of words for users. And I like to get it distilled to about 60s words for the end users, the listeners.

I love that you could click on the schedule and then go to that playlist and listen to that episode.

I also like that you can go to any playlist from the day and scroll down to get to previously played shows for the day. But, how do you teach people to do all that scrolling?

I love that this is Spinitron based and that you already have the schedule, and that your system easily allows for occasional prorgrams.

On the top of our Programs Page, we had one link to the rfa page, and one link to the KXCI Spinitron Schedule. On our website, we used to have several locations linked to the general rfa/kxci landing page so that people could go to our rfa page and see the whole archive.

And then below that, there are tiles for each of the programs, and the tiles to a unique program page.

On nearly every music program page, we have a link to the Spinitron Playlist for that program, which in some cases could go back to 2013. And we used to have a link to every program in rfa, too. So that was about about 70 unique rfa links.

OK that’s mostly a description of how things have been working, not a lot of questions. Just trying to imagine how to make things the easiest.

Again, thank you so much!

The first show that we have archived is The Hub, which began at 6pm, Monday, August 24th. Hurray! Looks and sounds good.

I was just clicking on one program. They haven’t done a playlist since July 11. So, theoretically, I don’t the the archive will show up for them on Saturday? Or will it go to the most recent playlist that is there?

I like that we could have more leverage to get a few of our stragglers to do their playlists.

RFA used to have a counter that told us how many times each archive was played. That was kind of a nice feature to get a feel for how popular a rebroadcast was.

We are working a player widget that we can use on spinitron.com pages and that you can integrate in yours. It works together with user interface elements on the page that start playback of the archive. Each UI element has a date and time coded into its HTML that controls where in the archive the player starts playback.

For example, the element might be a play button triangle :arrow_forward:. Its position on the web page tells the user what to expect. If it is at the top of a playlist, as it is now, the playlist date/time indicates the historical moment where playback begins. Or it could be on each line in a list of past playlists. Or in several places in a calendar view, allowing playback according to time-slot. Or even beside each song in a playlist, although this might be legally dubious.

We are working on this right now.

Your thoughts on instructions for listeners to navigate to the archive don’t take into account what we’re going to add on your public spinitron.com pages or changes you might make to your web pages to make archive listening easier.

I set out below our plans for the spinitron.com public pages. We can perhaps discuss what you might do with your web site in another forum thread, or in email or on a call. Btw, ohmradio963.org demonstrates how to integrate all spinitron.com public pages in one easy step: navigate to Programming: Schedule, then click around in the page content and then back to OHM’s pages via the topnav.

Our plans for public pages

Here’s where we’re going to put UI elements to start the archive player.

Station landing page

In the on-air block (if there is one) or just ended block (if there is one) and the list of recent playlists

Show page

In the list of past playlists

DJ page

In the list of past playlists

Calendar blocks between N minutes and 14 days old

For each calendar view (week, day, list) that we can manage to put a play UI element, e.g.

1 Like

I enabled the seamless feature in the web player shortly before 8 am today eastern time.

Some of you have noticed a short gap every 5 minutes during playback. The seamless feature should get rid of that.

If you notice any problems with playback that started after 8am today, please let us know.

1 Like

I used Ark for the first time today, in an attempt to kill two birds with one stone. First, as a fourth source of audio to help diagnose a problem that occurred last night. And second to gain some familiarity with Ark itself.

I had no difficulty finding and playing the audio, and its quality was what I had expected. But there were many skips, half a dozen or so in about an hour. These were skips of substantial size (i.e., several minutes).

The URL was https://spinitron.com/KCSM/pl/11573744/The-Jazz-Oasis. The period referred to was in the range +00:30:00 and +02:00:00 (please excuse lack of precision).

I know that these things happen, and when a stream is genuinely interrupted, I’d much rather have it resume automatically later, as here, than have the recording terminate. However, none of the other three sources, two recorded from the station webstream (the other was of FM off-air) showed anything unusual, but rather simply continuous, uninterrupted audio. I’d have expected the presence or absence of skips or drop-outs to be common to all webstream recordings. Is that expectation wrong?

Thanks for the feedback @KCSMbebopper and for joining the forum.

I think what you experienced is failure of the feature that I enabled on Friday morning.

The player has two modes of operation. One uses advanced browser features to play the archive segments perfectly seamlessly. The other uses more basic browser features that are well supported but that can’t achieve completely seamless playback.

I turned on the advanced, supposedly seamless mode on Friday morning and off again yesterday afternoon. In my listening in Firefox the playback was unacceptable and consistent with what you describe. Playback in the basic mode is acceptable (imo) and seems pretty robust but I still want to minimize or eliminate the seams every five minutes.

Please give your show another listen now and let us know what you experience.

The problem no longer occurs, thank you.

I’ve listened for some 100 minutes. There have been no skips whatever.

The audio quality is excellent. I have, however, noticed over a dozen momentary drop-outs, the longest being much shorter than one second. None of these is on either of the two webstream recordings I have (one 64kbps aac, the other 128kbps mp3).

I’m pleased to report that something with the player itself which I didn’t mention yesterday (because it seemed independent and was of secondary significance) no longer happens today. Yesterday, when the player had been paused, it restarted itself after some minutes; most of the time when this happened the play/pause button was showing “pause”, as expected, and clicking it cause the audio to stop again. But sometimes the button was showing “play”, and it took a minimum of two clicks to get the audio to stop. Today, all is as expected: paused audio remains paused until restarted. (And, yes, I’m using Firefox. 80.0.1, 64-bit.)

Yes, we also noticed that in “advanced mode” the player could restart itself after pause. Certainly a bug.

Those momentary pauses are the “seams” I mentioned before. They are a feature of the more basic mode of operation.

Have y’all tried the new player yet?

Still to do with the player:

  • volume control
  • navigate to playlist when you choose a date/time with a different playlist from the one displayed
  • package it as a widget you can put on your web site

We here at WOWD/Takoma Radio were awaiting your announcement as to actual launch, since we were not one of the Beta-testing stations. Would should we or could we be doing to try it out? Please advise!