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.
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 
. 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.
Here’s where we’re going to put UI elements to start the archive player.
In the on-air block (if there is one) or just ended block (if there is one) and the list of recent playlists
In the list of past playlists
In the list of past playlists
For each calendar view (week, day, list) that we can manage to put a play UI element, e.g.
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.
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:
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!
Try one of the stations in testing, e.g. https://spinitron.com/WZBC/
We added WOWD to the test stations around 7pm on Wednesday so you can also try https://spinitron.com/WOWD/. If you try an earlier date/time, it won’t work, even though the UI allows you to choose earlier dates.
I would like to also know if there will be a counter for number of plays? It was very useful.
Joseph McGuire
KSVR-FM Mount Vernon Washington
Hi Joseph. Thanks for joining the forum.
Yes, we’re currently working on the management tools (mentioned in the OP). They will include what I think you’re asking for.
Thank you. DJ’s enjoyed seeing the number of times a show was played or at least started.
Joseph
Tom - Just wondering if you could post a status report … is Ark still in Beta mode? Do you anticipate significant changes before it fully launches?
Yes. We’ll post a status update soon.
Owing to a sysop error (i.e. it’s Tom’s fault) the stream recorder failed for several hours last night. This means there will be parts of your archives during these hours that won’t play. I don’t know the exact date-times when your recordings stop and restart.
Sorry.
Until about 2 weeks ago we thought things were looking good. The Ark Player is working, the recorder and server parts are working. There were some things to finish up that wouldn’t take long.
One of those things was playback using mobile. This turned into a big problem.
Sorry to be technical for a moment, please bear with. Until now we use a browser feature called Web Audio API to convert audio files into sound. Each file is a segment of the archive of your webcast (5 minutes each as it stands). Web Audio allows seamless playback of the segments. JavaScript runs in the background in the web browser to download, cue-up and start each subsequent segment. That just doesn’t work on mobile. If the user has switched to a different browser tab, or is using a different app, or locks the screen, or if it turns itself off then the JavaScript that plays the next archive segment won’t run. The archive just stops playing.
This is a fundamental problem.
It’s not ok to limit the archive to people actively using desktop or laptop computers. People should be able to listen with their phone in their pocket or purse, as they would to music, a podcast or audio-book, or while using a different app, or reading news in a different browser tab. They should be able to listen while out and about, or in the car, or in any room at home or work using a phone or tablet with a Bluetooth speaker, earphones or the device’s speaker. They should not need a computer to listen to the radio.
So we went back to square 1: the basic research on how to implement the service. We are currently working on how to implement it using HLS. It segments the archive into smaller audio files (e.g. 10 seconds) together with a playlist file that lists the URL and duration of each segment. We point the browser to play the playlist and it can do that without JavaScript running in the background.
It’s promising. Yesterday I played an archive of WZBC for two hours while my phone’s screen was locked.
There’s a lot still to do and I don’t know how long it will take. When you’re trying to engineer something you haven’t done before, you don’t know what needs to be done until you’ve done it so estimating how long it will take is hard. Remind me and I’ll give you another update a week from now.
