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
Original
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.
UPDATE
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.
Thanks for joining the forum @cpuyear . Could you specify the station and show name (and time-slot)? Thanks!
The station is KOPN The show is Blues On Broadway, 8-11pm Saturdays
Itâs not just my show, I just monitor my shows. I see the same thing on the last Sunday Morning Coffee House I did on 1/30/22 (8-12am) Sundays.
I donât know why this is happening but I know itâs frustrating listeners (and me) and costing us both listeners and as I said before I know the log times are short but not sure why. I recognize some of the locations as regular listeners to our live stream so I know when I see them try a couple times and go away that they are not doing a drive by and just seeing whatâs on, they want to listen but canât.
Here are the last 2 BOB (I can only do 2 attachments). I noticed a difference on 1-22 & 1-29, fewer listeners but most hooked up for a decent amount of time without showing several short tries ?
I donât see much suggestion in those logs that listeners were unable to listen for technical reasons. Short listening sessions are normal and typically this reflects nothing more than listener behavior. (We define a listening session as a consecutive sequence of HLS segment requests from a given client.) An exception in these logs is this one
The fact that these two sessions are the same start time and duration is surprising and would be explained by an interruption in the archive recordings. But those recordings are deleted already so we canât check up on that.
We can see from the recording availability stats that KOPNâs stream exhibited instability on the 17th and 18th and there were glitches on three of the next four days.
If listeners are unable to listen to a specific date/time and we can reproduce the problem and the problem is not due to unavailability of the recordings (e.g. interruption is in a block of solid, full one-hour alternating light/dark green bars), then we have something to investigate.
We continue to monitor recorder performance and make improvements to the recorder logic to make them more robust to network and service instability and bugs. If thereâs something in the recording availability that you think I need to investigate, feel free to report it, though not on this thread, which is about our web player. But remember that recording outage is often not something we can fix beyond reporting the problem upstream.
I wonder if there is a way for the playlist to to update/refresh while the playlist is live? More people are interacting with the chat function which does refresh but the playlist stays static from when the page was opened. So if you are on the page and contributing to chat, the playlist doesnât update. If one refreshes the page to see the updated playlist, it then logs one out of chat. These are great features but they are working against each other a bit. Sorry if this is already covered. Thanks Duncan KXCI
1 Like
Hi Duncan, thanks for joining the forum.
Yes, weâre aware of the need for a kind of independence of the audio player, chat and other page content, so that you can keep the player going while doing other things in the page, and maybe the page doing things to itself, like updating its own content. For this we will have to develop an SPA.
As far as chat is concerned, it is by design that we require users to login to each playlistâs chat room. Itâs easy (not requiring entering passwords each time) but we require a deliberate action from each user to enter each playlistâs chat room after the DJ (i.e. playlist chat-room moderator) opens that playlistâs chat. It comes from our goal of minimizing anti-social behavior.
1 Like
Thank you Tom. Glad to have this forum to share info on Spinitron. I appreciate your time and these important tools you have made available for stations like KXCI. I didnât address the archive audio player in my post but yes an independent player that keeps going and out of the way of other web use is probably highest on the wish list.
In that post I kept to how a user interacts with the page while it is live and the chat is open. Like how the chat updates but the playlist doesnât, then if you refresh to update the playlist, you have to log back in to the chat again (ad infinitum if you want to see the playlist updates and contribute to chat). I do appreciate that the chat is set up so that the DJ has control and logins minimize antisocial behavior. Best, Duncan
1 Like
Is there a way to replace the audio the ARK player draws from in the event of an ARK recording error? Weâve had several instances lately of the recorder missing occasional chunks of time or adding the wrong timeframe (for example, offering only 3 hours of a 4 hr show or offering 6pm-9pm when it should be offering 4pm-6pm.)
Weâre still archiving on-site, so I do have full mp3s of these shows on our server, but donât see a way to swap out that audio.
1 Like
Hi Mason. Good question but no, sorry, the Ark service offers no such feature.
The system we built to run Ark is technically as simple and automatic as I could manage (necessary for our low, low prices). Hypothetically speaking, it is not impossible that you could manually produce sets of audio files, to our precise specs, that I could manually copy to the server to replace the ones already made by the recorder that listens to your live webcast. But it is not simple. (Consider for example the continuity of timestamps in MPEG streams segmented into files.) It is exacting technical work that I cannot do alone and am unprepared to offer in general as a consulting service.
If there is an emergency then I will always attempt to help. For example I can delete archive segments fairly easily (maybe someone did something bad on the radio #itsathing). But replacement is much harder.
I hope this answer leaves you better prepared to decide if you want to try to persuade me 
cannot move through streamed programme. I am listening on KRVS. Their previous app allowed to move through the programme. this was particularly useful if you had to close and reopen a window prior to finsihing listening to a programme. Please, can you put this functionality in or tell me how to do it if it is already there? thanks,
Hi Charney, thanks for joining the forum.
The archive player on spinitron.com does not have a seek slider or buttons to skip backwards and forwards. You may however pause the player and choose a new archive start time in increments of 15 minutes.
We understand that this is not as convenient/interactive as some other kinds of audio player and Iâm sorry that it is disappointing relative to what you used in the past. We have attempted to explain the reasons for the design here Webcast archive, not podcast
A couple of days ago I used Ark for the first time . I listened to Firehouse Theater, WFHB 91.3FM, Bloomington Community Radio. At the time I listened about a half-hour using Firefox 100.0.2 (64 bit) on Linux (Fedora v34). I also listened for a short time using Chrome 99.0.4844.84 (Official Build) (64-bit) on Fedora.
I experienced no trouble with either.
My comment was going to be "why no way to rewind or move ahead in the recordingâ, but I read some of the forum posts. I understand there are limitations based on licensing.
Thank you for a useful tool.
1 Like
Thanks for taking the trouble to join the form and write that @jsware.
This is by far the most read and replied-to topic on the forum and I think this may be the first entirely positive feedback weâve gotten. So thatâs nice. I feel like saying you cracked the code and won a prize but people would think Iâm handing out rewards in return for complements, and theyâd be right!
We have another forum topic called Webcast archive, not podcast which contains some details about the licensing issues. It was written mainly for station staff but it contains the crux of the interactivity limitations too.