Hi Marc, thanks for joining the forum.
It’s a known problem. And we understand how big a drawback it is.
Let me give a rundown on where we are, how we got here and what might happen next.
Radio Free America (RFA) was providing a free two week archive that lots of Spinitron stations were using. We thought it was a pretty good service for $0 and easy for stations using Spinitron to try so we often mentioned it to stations. But it is in the nature of that kind of business that if they cease operations they will do so without warning and that worried us. We would feel bad if stations we had pointed their way were left hanging overnight.
When that happened we quickly moved to fill the gap. I figured we could quickly set up a system that connects to station’s webcast streams, automatically writes the digital audio data in the streams to audio files, stores those in the cloud and to provide a web-based archive player that uses those files to play back from an arbitrary point in the last two weeks.
And I was right, we got that up and running quickly. But we soon found that on mobile the web player would continue running only if the mobile device’s screen stays on and the browser tab it’s in stays in the foreground. This is, as you pointed out, a severe limitation and we started to work on fixing it as though it were a bug. But it eventually became clear that fixing this bug would require redesigning the whole system using different web-audio technology. That was going to take considerable time, way more than we had planned and more than stations who had lost RFA should have to wait. So we decided to offer what we had commercially at a low price with a clear notice about the limitation on mobile.
We were unable to quickly fix the mobile issue is because of a malign combination of legal and technical constraints. As a service provider we have to make it unfeasible for a user to download a copy of the station’s audio without resorting to obvious hacking and violation of the terms of service. So we segmented the audio into 5 minute chunks, each stored in one file. The audio player downloads these files on the fly and plays them back to back. To download, say, an hour of programming, a user would have to hack the system to download twelve such chunks and then stitch them together to have an hour of seamless audio.
And this is where the problem on mobile arises. The archive web player uses JavaScript running in a web browser to download the chunks and start playing them at the right time. When a browser tab goes into the background, or the user switches to a different app, or the screen turns off, the browser stops running the player’s JavaScript. There’s nothing we can do to prevent that.
I can see two ways out of this. One is to use long audio files, so long, maybe an hour or more, that the user doesn’t mind reopening the browser tab to restart the archive playback when it stops. We’re not prepared to do this for legal reasons. A station could reasonably operate such a service for themselves since I believe their liability would be acceptable. But it’s different for a commercial service provider like Spinitron. Litigation for us would likely be the end for Spinitron and our livelihood.
The other is to use a streaming video protocol such as DASH or HLS. I’ve done enough experiments with HLS to be fairly confident that it can be made to work. I can specify how such a system can work but I haven’t had time to build it.