Webcast archive service

Spinitron offers a Webcast Archive service named Spinitron Ark.

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 a listeners web browser, fetches and plays the audio from the server

We offer the recorder, storage and server as a subscription service for a monthly fee (pricing below). We integrate a web player into Spinitron public pages on spinitron.com for clients that subscribe to both Ark and Spinitron playlist management service. We also 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 start buttons, see below for details.

Ark subscribers have access certain management tools including

  • Display of recent and historical audience size
  • Log of each listener’s use to the service including the listener connection timestamp, archive start point, and approx. geographic location.
  • SoundExchange formatted reports of use will be available for clients subscribed to both Ark and Spinitron playlist management service (not implemented yet)

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 listener 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.

Overage

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 step 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 Mid November we are able to offer the service commercially.

Limited function on mobile. On a mobile device the archive playback will stop a short time up to 5 minutes after the device’s screen turns off or the web browser tab with the player is backgrounded. This can be acceptable in some use cases, e.g. I have a cheap tablet at home for this kind of use. But it it means you can’t continuously listen to the archive while doing something else with a phone or if its screen is off/locked (e.g. when it’s in a pocket or bag).

There’s a widget web player that you can use on your web site. Indeed anyone can use it on their web site. It’s the same as what we use on spinitron.com. It allows the web master to set arbitrary start points for archive playback so you can put play buttons on web pages that start the player at any dates and times. We will use it on spinitron.com to put play buttons on public pages as described below.

For now we are accepting only existing Spinitron clients as Ark customers in order to limit how quickly we need to scale up the system.

Copyright, licensing and SoundExchange

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

Listeners’ use of the archive counts towards your webcast’s audience just like the live webcast. Thus the Aggregate Tuning Hours (ATH) of your webcast service for any given period is the sum of the ATH of live listening and that of archive playback.

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 and listener logs. Clients of both Ark and Spinitron playlist management can also use Spinitron to prepare SoundExchange Reports of Use and NPR-format streaming log files of archive use.

Legal

See the Ark Terms of Service.

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

https://spinitron.com/KCSM/pl/11476162/Mid-Day-Jazz

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!