FYI: Regressions, post-API-change versions incorrectly read the old db

[Jollailija]

From OpenRepos:

After installing I could see my list of stations but could not use them. Deleting and adding them again helped. The readded ones appear with ".0" in the bitrate, e.g. 64.0 instead of 64.

I had problems with some stations. E.g. the database has two entries for the same station and "Radio Svoboda Rus" worked, "Радио Свобода (Radio Svoboda, RFE/RL Russian, ch. 4)" did not. Now both work. But neither is assigned to any country while actually in the database they are in Czechia.

Some countries are missing in the countries list, e.g. Rwanda and also Czechia but there is Czechrepublic there, only it does not load any stations even though some are assigned to "Czech Republic" in the database. Some other countries do not load any entried either, e.g. "United Arab Emirates", "United Kingdom", "United states".

I do not remember if I could listen to sound of TV stations before. Now they just hand the program (example: "Current Time" TV).

[Jollailija]

I also received word via email that the old favourites are listed, but can not be played. Here's a database dump for testing:

sqlite> .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE channels(id INTEGER, lastchangetime STRING, source TEXT UNIQUE, title TEXT, site TEXT, tags TEXT, icon TEXT, codec TEXT, bitrate TEXT); INSERT INTO channels VALUES(113745,'2018-09-10 22:28:42','http://us4.internet-radio.com:8193/;stream.nsv','Radio Estilo Leblon','http://www.radioestiloleblon.com','Ambient, Lounge, Bossa Nova, Jazz, Chillout, Brazilian Music','brazil','MP3','128'); INSERT INTO channels VALUES(122118,'2019-04-14 06:22:32','http://strm112.1.fm/bossanova_mobile_mp3','1.FM - Bossa Nova Hits','http://www.1.fm/station/bossanova','latin','switzerland','MP3','192'); INSERT INTO channels VALUES(132633,'2020-02-29 05:03:37','http://astreaming.europafm.ro:8000/europafm_aacp48k','Europa FM','http://www.europafm.ro','talkshow,news,music','romania','AAC','64'); INSERT INTO channels VALUES(125400,'2019-07-10 14:45:58','http://asculta.rfi.ro:9128/live.aac','RFI Romania','https://www.rfi.ro/','news,rock,pop,oldies','romania','AAC','64'); INSERT INTO channels VALUES(88769,'2017-01-09 00:59:09','http://stream2.srr.ro:8022/','Radio România Muzical','http://www.romania-muzical.ro/','classical','romania','MP3','256'); INSERT INTO channels VALUES(88770,'2016-09-21 19:04:39','http://stream2.srr.ro:8012','Radio România Cultural','http://www.radioromaniacultural.ro','cultural programming','romania','MP3','256'); COMMIT;

[nesnomis]

Yes, the new API kind of messed it up for AllRadio! Last summer i started on the conversion and realized that there were to many changes in the new API, even though the changes improved the API a lot (so it is a good thing).

Then, i started on a fresh with a version 2 (totally rebuilt with a lot of new features) just to find that i had to many things in real life to take care of, and no time for programming up until now.

When i noticed new contributions (language files, new api conversion) i tried to give the old app a go, but i don't think it is good enough to try to keep it alive?! And the only way is a new AllRadio v. 2.0.

I am really thankful for the contributions and i kind of feel guilty, thinking about rewriting the hole thing!

[Jollailija]

I guess we aren't so different after all- I also got caught up in life and never got Nettiradio up to 2.0 (which was supposed to be for international listeners, but then AllRadio came along so I no longer felt the need to implement that set of features, and with life stuff getting in the way I kinda just dropped it altogether). This Christmas I tried to refactor Nettiradio to allow for better maintainability and implemented rudimentary import + export features only to come to the same conclusion as you- a version 2.0 needs to be built from scratch. There's just way too much undocumented trial-and-error spaghetti and zero room for for plugging in new features.

I no longer live up to my name- nowadays I'm a LineageOS user -so building an all-new SailfishOS app from scratch is a bit too much for my limited free time. But you? Go for it! Don't feel bad about breaking a few eggs to make an omelet. You're doing this stuff for the community gratis after all, I doubt they'd lynch you for publishing more useful, free code that people can more easily contribute to and build on. (Also I bet most of the translations could be moved over with some regex & a switch to qsTrIds)

There's an empty space left behind by AllRadio 1.0, and no one has stepped up to fill it. I recently took a look at the "alternatives" and most radio apps are either dead, limited to a set of stations or lacking an easy way to add stations so I'd gather you'd be able to build the #1 SailfishOS radio app quite easily with the new APIs and all the knowledge you've gathered by building AllRadio 1.0 and can gather from eg. SailWave (psst, check out a fork with import/export, GPLv3). We open source devs truly stand on the shoulders of giants (of various sizes) and should use that power to it's furthest extents for the good of the community.

Speaking of community, I suggest you start with interacting with it more! Get some other devs involved, plan out the new app together (what features should be supported & how should components interact with each other), document the features and the progress so others can more easily jump in etc. I'd be happy to help you build the next best Sailfish net radio app!

[Jollailija]

A few observations I've made about (building) radio apps:

Modularization is really important for future proofing. Breaking functionality into small bits with sane functions & attributes instead of giant monolithic files & global variables makes refactoring and adding features way easier.

Implementing logic for stuff like "next channel" in the audio player and/or station list manager components instead of eg. at the cover page makes it way easier to switch how you handle switching stations in general.

Speaking of handling channels, allowing multiple user-defined sources (like CRB & importing playlist files from other apps like VLC and Radiotray, possibly hosted on the internet or synced on the local filesystem) seems like a killer feature. Can "adapter plugins" be downloaded from the internet on harbour apps? Different XML query strings seem like stuff that could be delivered to the app OTA style without requiring an update.

I think handling duplicates should be done at the database level by making stream urls unique and adding stations in any way (automated or by hand) should be generalized to go through the same "pipeline", allowing such functionality as SailWave-style stream validation to be added later.

Validating streams is hard; all stations don't air 24/7 and same error can be triggered by both bad connectivity and bad urls. Thus "the buttons going wild" should be a valid, user-configurable state for the people who have bad connectivity and can't restart playback manually (like while driving).

Configurability is king. Nemo.Configuration can be used instead of hardcoded values in a lot of places to save state- this allows stuff like resuming playback automatically after closing app (if the user doesn't stop the stream before closing) without having to implement any settings UI or startup value retrieving code for it. Double win!

Power users should be able to overwrite the app state with command line flags for stuff like import/export or sleep timer automation and alarm clock functionality. See TinyEdit for an example of parsing arguments, though I think that stuff shouldn't be implemented in the UI/qml code as is the case with reading and writing files.

Frontend/backend separation is needed for better performance. A 100+ long list starts to get slow. Dynamic loading or being able to hide certain sections are a few ideas for solving these that should be kept in mind while designing the database. Modifying buffer size and adding media format support should also be possible, at least in OpenRepos builds.