[FEAT] Subscribe to curated station lists #267
Comments
|
We can rename it, no problem. S-N-G said to name it lossless.csv. I was considering abandoning it, because I doubt anyone, but myself, uses that list. I started working on an update yesterday (12/29/24), but the list is longer now and takes more time, so I will be done either today or tomorrow. |
|
Hey @Scary-Guy and @amski1 I've been thinking about how to manage pyradio remote (online) playlists. Instead of adding them directly to the main pyradio repo, I think it would make more sense to create a new GitHub repository solely for playlists. Here’s why: With a separate repo, pyradio itself could simply watch for commit changes and update the local copies of the playlists without touching the main program code. It keeps things modular and avoids unnecessary distro updates while giving us more flexibility to manage playlists. What do you think? |
|
I mean that was sort of what I was getting at too, in that anyone could set up a repo that people could subscribe to. Then just have it fetch updates for those curated playlists. I suppose now that I think about it that this could be achieved with a cronjob and wget/curl too. However, having it exist in app would just be much more convenient and not everyone knows how to use or has cron on their system (I don't think Windows has a cron, but maybe it exists in WSL2? Is that still a thing?) |
|
There are a lot of things to consider though. Having a centralized repo for remote playlists poses its own challenges. Each user would have to connect to github, read playlist names, check commit tokens download the playlists (if updated). Using unauthenticated requests to github api is not without its problems though; there is a limit of 60 requests per hour per IP. This means that direct updates are out of the question, they could lead to severe punishment for the repo / project, etc. So, maybe following a 10 day update period seems the safest way. Given that the playlists will probably not be updated regularly, I think this will suffice. The alternative would be to use authenticated requests, but that would require the user to have a github account, and create a PAT (Personal Authentication Token, or something) and insert it to pyradio... Too technical, I do not think anyone would actually do that... Thoughts? |
|
I'm not thinking of limiting it to just Github though. Even a pastebin or something should be workable. Or even if someone wants to host it on their own website (for example somafm.com has a lot of stations and they could host a .csv of that if they wanted, not that I'd expect it to change much.) Also if the request came specifically from the user (via cron/wget) then it would be on them. Also updated could be set to manual instead of scheduled too. So say for example I wanted to update the master list that the program uses (and it didn't have that option internally.) Then that repo file would have an entry of: Though I don't know if not using the API would be against the Github TOS then. However as I said there's Pastebin, Gitlab, etc... and then it wouldn't lock users into just repos hosted here anyway. I think it's the most elegant solution. |
|
What if you stick it on the main list, only put a dividing line with a title like so: ---------------------------- MP3 -------------------------- |
Because of the way .csv files work I'm not sure that's possible, unless there was a special argument for that where you would have something like: But that's also more of a labeling issue more than a repo issue, but I like the idea! It would be neat to group stations by URL too for example (like laut.fm or somafm.com which have A LOT of stations.) |
|
I'm not sure I follow. Currently each line consists of STATION_NAME,link All you need is a comment line, even if you navigate onto it and hit enter, nothing should happen, a comment can't play, no? |
If it's treated like a standard .csv (comma separated values) file then no, but it would mess up every entry after that comment too because the order would be off. However if you did |
|
Can you guys try? I can email the list "monthly" to any of you and you can just append it. That is if s-n-g wants to go with such a plan. |
You're already on Github, which means you can make your own repos. I mean if the maintainer wants to do it that's up to them, but I know they already told you that you should just go make your own. It's very easy and although I don't have any on here but I do on Gitlab because I prefer that. |
The thing you are talking about is grouping, pyradio already supports groups, just add a station and use "-" as URL |
|
OK, please let me know if you want the new list when it's ready. I apologize, but I won't maintain a repo. |
Sure, just update it as you normally do
Would it be a problem for you if I create a repo, make you a contributor so you can commit the changes directly to it? |
|
If you're willing to maintain it, I don't care where I post. PS. I cleaned up the other bug from all those lists, if you want - close it. |
Sorry, what are you referring to? |
|
Don't worry about it, I will when we are good and ready :) |
My idea is that curated *.csv files could exist online aside from the master one that the program uses and updates. Users could use a file called repo.csv or something. Then the program could update all the .csv files from that list.
For example, the user in issue 195 could update their list which exists on Github. Then just point to that in the .csv with something like:
HQ Lossless Stations,https://example.com/githubuser/repo/lossless-grouped.csvAlso if someone uses the stations.csv as the name there would obviously be a conflict. There could be an option to save files into subdirectories with names corresponding to the exact domain they're pulled from (so github.ext/user/stations.csv would just turn into ~/.config/pyradio/github.ext-user
Or maybe just ~/.config/pyradio/repos/*.csv and then leave the master in the root of /pyradio which seems simpler to me now that I think about it, but would still conflict with other stations.csv files.
Thoughts?
The text was updated successfully, but these errors were encountered: