New Issue

Import station list. #330

Open

opened by Apply2Sci · 12 comments

Apply2Sci commented (Migrated from github.com)

Is it possible to read in e.g. a .pls or .txt file, and have Transistor pull all the streams out into its own database?

I tried looking in the /Android/ folder but I don't know how to edit the collection.json file that I see using a file manager on my phone, and on PC it appears to be an empty folder named Collection.

I have nearly a hundred internet radio stations in my collection that I would like to migrate to Transistor. After manually copying a few URLs across, I see that Transistor works really well, and is exactly what I would like to use for my whole library of streams. However, manually coping in each URL and then editing the display name is just untenable, especially on a phone keyboard. Is it possible to read in e.g. a .pls or .txt file, and have Transistor pull all the streams out into its own database? I tried looking in the /Android/ folder but I don't know how to edit the collection.json file that I see using a file manager on my phone, and on PC it appears to be an empty folder named Collection.

👍 1

Apply2Sci commented (Migrated from github.com)

noticed duplicate issues, sorry

y20k commented (Migrated from github.com)

No Problem. Import/export is an important feature. In what kind of format would you have been able to export your radio stations?

Apply2Sci commented (Migrated from github.com)

I get the playlists exported from another service as .pls files, but I also have a cleaned .txt file with just the stream URLs on each line.

On the FAQ section of the project front page here, it says Transistor can read .pls files, but I haven't been able to get this to work with .pls files on local storage. "No results found" after copy/pasting full path from file explorer.

Having manually imported a handful of my most favourite stations, I have to say that the app works quite ideally in all other regards. Thanks a lot for making this in your free time. I'm not personally familiar with Java, or I'd offer to help with the import/export issue more directly.

I get the playlists exported from another service as .pls files, but I also have a cleaned .txt file with just the stream URLs on each line. On the FAQ section of the project front page here, it says Transistor can read .pls files, but I haven't been able to get this to work with .pls files on local storage. "No results found" after copy/pasting full path from file explorer. Having manually imported a handful of my most favourite stations, I have to say that the app works quite ideally in all other regards. Thanks a lot for making this in your free time. I'm not personally familiar with Java, or I'd offer to help with the import/export issue more directly.

y20k commented (Migrated from github.com)

I have considered using PLS or M3U as a format for importing/exporting, too. Problem is, that both formats only store name and stream address. Transistor stores more data (see Station.kt).
For example: Depending on the way a station was added (by search or by URL), it stores the source (remoteStationLocation / radioBrowserStationUuid). That information is necessary for the "update stations" feature.

So offering an import/export format, that is limited, could cause some frustrations.

new users: if they bring their own PLS files, they are going miss out on some features
existing users: they might think that an export from an old phone and an import to a new phone is a backup. They will find out that it is not (images missing, update not possible anymore)

An alternative could be a propitiatory format, lets say a ZIP containing JSON file plus images. That would work as a backup for existing users, but would not be a help for new users.

Another alternative could be a more complex import that tries to re-create some of the missing data, by querying the radio station search server for it.

As of now I am not totally convinced that Transistor could offer a satisfactory solution for this problem.

I have considered using PLS or M3U as a format for importing/exporting, too. Problem is, that both formats only store name and stream address. Transistor stores more data (see [Station.kt](https://github.com/y20k/transistor/blob/v4.0.10/app/src/main/java/org/y20k/transistor/core/Station.kt#L31)). For example: Depending on the way a station was added (by search or by URL), it stores the source (`remoteStationLocation` / `radioBrowserStationUuid`). That information is necessary for the "update stations" feature. So offering an import/export format, that is limited, could cause some frustrations. - new users: if they bring their own PLS files, they are going miss out on some features - existing users: they might think that an export from an old phone and an import to a new phone is a backup. They will find out that it is not (images missing, update not possible anymore) An alternative could be a propitiatory format, lets say a ZIP containing JSON file plus images. That would work as a backup for existing users, but would not be a help for new users. Another alternative could be a more complex import that tries to re-create some of the missing data, by querying the radio station search server for it. As of now I am not totally convinced that Transistor could offer a satisfactory solution for this problem.

👍 1

jamal2362 commented (Migrated from github.com)

Hi :)

I have an idea how to do it best.
In the settings an import/export button.

Import: .zip with the .json file and images.
.m3u and .pls as web address is already included and doesn't need to implement it.

Export: .zip with the .json file and images. As well as .m3u and .pls as web address.

Everything both as in each case a button so that it remains clean in the app.

Thus all should profit from it.
No matter if existing users or new ones.

Example:

Hi :) I have an idea how to do it best. In the settings an import/export button. Import: .zip with the .json file and images. .m3u and .pls as web address is already included and doesn't need to implement it. Export: .zip with the .json file and images. As well as .m3u and .pls as web address. Everything both as in each case a button so that it remains clean in the app. Thus all should profit from it. No matter if existing users or new ones. Example: ![Screenshot_20210119-204134](https://user-images.githubusercontent.com/15986930/105084546-c7495c00-5a96-11eb-90f0-b510de99dd22.jpg)

Apply2Sci commented (Migrated from github.com)

I see, there's more to this than I thought. Perhaps the import and export
functions would look very different from each other.

First, I have to contend that the vars listed in Station.kt are all
initialized after adding a single URL anyway. That is, when manually adding
a single stream by URL, all these vars are then set by Transistor, not the
user. The "complex import" you described kind of already happens, just for
a single entry. Hence, would it not be possible to import multiple URLs
from a .txt and treat each URL the same as a manually added one,
sequentially down the file? Looking at .pls files, AFAIK the only
additional var you could potentially pull is the "name" string from "title"
in the .pls file.

Regarding exporting from Transistor, probably the simplest and most
comprehensive solution could be a proprietary zip containing all
Transistor-set vars. Obviously this might only be importable back to
another Transistor installation; a true backup. But again, perhaps a
simple, cleaned export of simply a .txt file with a URL on each line could
provide a more universal (but featureless) export of the single keys that I
would argue are the most important with regard to a list of stations. The
.pls file or other formats could fall between these two extremes.

So, regarding the vars that would be lost in a very pared-back export,
since they are all initially obtained from the stream (if adding a single
URL manually), then can the stream not be relied on to provide an
up-to-date replacement at any point in the future? How important is it to
backup e.g. the album art from the stream at a point in the past? These
arts could be the station logo (generally not changing at any lookup time)
or the currently playing album (soon obsolete info).

Now I have to admit that I have a fairly simple set of experiences and
probably have not have thought of all the possibilities, but hopefully
there are some easily implementable solutions amongst all this.

On Sun, 17 Jan 2021 at 20:59, y20k notifications@github.com wrote:

I have considered using PLS or M3U as a format for importing/exporting,
too. Problem is, that both formats only store name and stream address.
Transistor stores more data (see Station.kt
https://github.com/y20k/transistor/blob/v4.0.10/app/src/main/java/org/y20k/transistor/core/Station.kt#L31
).
For example: Depending on the way a station was added (by search or by
URL), it stores the source (remoteStationLocation /
radioBrowserStationUuid). That information is necessary for the "update
stations" feature.

So offering an import/export format, that is limited, could cause some
frustrations.

new users: if they bring their own PLS files, they are going miss
out on some features

existing users: they might think that an export from an old phone
and an import to a new phone is a backup. They will find out that it is not
(images missing, update not possible anymore)

An alternative could be a propitiatory format, lets say a ZIP containing
JSON file plus images. That would work as a backup for existing users, but
would not be a help for new users.

Another alternative could be a more complex import that tries to re-create
some of the missing data, by querying the radio station search server for
it.

As of now I am not totally convinced that Transistor could offer a
satisfactory solution for this problem.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/y20k/transistor/issues/330#issuecomment-761879085,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASMVNAZCQIRMPPSTHU4GSTLS2NFT3ANCNFSM4V2PY4KA
.

I see, there's more to this than I thought. Perhaps the import and export functions would look very different from each other. First, I have to contend that the vars listed in Station.kt are all initialized after adding a single URL anyway. That is, when manually adding a single stream by URL, all these vars are then set by Transistor, not the user. The "complex import" you described kind of already happens, just for a single entry. Hence, would it not be possible to import multiple URLs from a .txt and treat each URL the same as a manually added one, sequentially down the file? Looking at .pls files, AFAIK the only additional var you could potentially pull is the "name" string from "title" in the .pls file. Regarding exporting from Transistor, probably the simplest and most comprehensive solution could be a proprietary zip containing all Transistor-set vars. Obviously this might only be importable back to another Transistor installation; a true backup. But again, perhaps a simple, cleaned export of simply a .txt file with a URL on each line could provide a more universal (but featureless) export of the single keys that I would argue are the most important with regard to a list of stations. The .pls file or other formats could fall between these two extremes. So, regarding the vars that would be lost in a very pared-back export, since they are all initially obtained from the stream (if adding a single URL manually), then can the stream not be relied on to provide an up-to-date replacement at any point in the future? How important is it to backup e.g. the album art from the stream at a point in the past? These arts could be the station logo (generally not changing at any lookup time) or the currently playing album (soon obsolete info). Now I have to admit that I have a fairly simple set of experiences and probably have not have thought of all the possibilities, but hopefully there are some easily implementable solutions amongst all this. On Sun, 17 Jan 2021 at 20:59, y20k <notifications@github.com> wrote: > I have considered using PLS or M3U as a format for importing/exporting, > too. Problem is, that both formats only store name and stream address. > Transistor stores more data (see Station.kt > <https://github.com/y20k/transistor/blob/v4.0.10/app/src/main/java/org/y20k/transistor/core/Station.kt#L31> > ). > For example: Depending on the way a station was added (by search or by > URL), it stores the source (remoteStationLocation / > radioBrowserStationUuid). That information is necessary for the "update > stations" feature. > > So offering an import/export format, that is limited, could cause some > frustrations. > > - new users: if they bring their own PLS files, they are going miss > out on some features > - existing users: they might think that an export from an old phone > and an import to a new phone is a backup. They will find out that it is not > (images missing, update not possible anymore) > > An alternative could be a propitiatory format, lets say a ZIP containing > JSON file plus images. That would work as a backup for existing users, but > would not be a help for new users. > > Another alternative could be a more complex import that tries to re-create > some of the missing data, by querying the radio station search server for > it. > > As of now I am not totally convinced that Transistor could offer a > satisfactory solution for this problem. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <https://github.com/y20k/transistor/issues/330#issuecomment-761879085>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ASMVNAZCQIRMPPSTHU4GSTLS2NFT3ANCNFSM4V2PY4KA> > . >

y20k commented (Migrated from github.com)

Hi there,

typically there are two ways to add stations to Transistor:

via an URL pointing to a M3U or PLS file
via the inn app search

Transistor stores in case 1. the original source URL (remoteStationLocation) and in case 2. an ID it got from the search provider (radioBrowserStationUuid).

If we use M3U or PLS as an import format, we can store names and stream addresses for each station.

But what we would need to be able to restore a previous state of Transistor would be remoteStationLocation and radioBrowserStationUuid.

Just importing names and stream addresses would result in an incomplete restore state. We cannot derive any additional information from those two values.

Hi there, typically there are two ways to add stations to Transistor: 1. via an URL pointing to a M3U or PLS file 2. via the inn app search Transistor stores in case 1. the original source URL (`remoteStationLocation`) and in case 2. an ID it got from the search provider (`radioBrowserStationUuid`). If we use M3U or PLS as an import format, we can store **names** and **stream addresses** for each station. But what we would need to be able to restore a previous state of Transistor would be `remoteStationLocation` and `radioBrowserStationUuid`. Just importing names and stream addresses would result in an incomplete restore state. We cannot derive any additional information from those two values.

👍 1

y20k commented (Migrated from github.com)

Two new similar issues came up (#336 & #337) in the last couple of days:
A lot of radio stations put multiple versions of their streams in a single playlist. The old Transistor (v3) handled that with dialog and a selection drop down menu (#175). That feature somehow got lost during the rewrite of the app (#251).

If this problem (multiple versions) is going to be addressed, we basically have the Import feature discussed earlier. I still think that my doubts are valid. But now we have a second reason for that the solution would be an Import playlist dialog.

Okay. How would such a feature look? I would prefer to have it in settings next to the Export feature. When tapped a file picker should let the user pick a playlist file. Then a dialog should let the user choose wether to import all streams within a playlist of just a selection. I think Parent and child checkboxes would be the correct UI for that.

Two new similar issues came up (#336 & #337) in the last couple of days: A lot of radio stations put _multiple versions_ of their streams in a single playlist. The old Transistor (v3) handled that with dialog and a selection drop down menu (#175). That feature somehow got lost during the rewrite of the app (#251). If this problem (_multiple versions_) is going to be addressed, we basically have the Import feature discussed earlier. I still think that my doubts are valid. But now we have a second reason for that the solution would be an Import playlist dialog. Okay. How would such a feature look? I would prefer to have it in settings next to the Export feature. When tapped a file picker should let the user pick a playlist file. Then a dialog should let the user choose wether to import all streams within a playlist of just a selection. I think [Parent and child checkboxes](https://material.io/components/selection-controls#checkboxes) would be the correct UI for that.

🎉 1

jamal2362 commented (Migrated from github.com)

Hello,

That is exactly what I think is right. The import function should be in the settings above the export function. Exactly as you described it, I suggested it and think your idea is best.

Greetings
Jamal

Hello, That is exactly what I think is right. The import function should be in the settings above the export function. Exactly as you described it, I suggested it and think your idea is best. Greetings Jamal

y20k commented (Migrated from github.com)

The old Transistor used a Spinner within a Dialog for this purpose (see DialogAddChooseStream.java).

In its standard implementation a user can only pick one item from within the Spinner. So that is not what we want here. Maybe I should adapt an existing Multi-select Spinner solution [1] [2].

🤔 A bit more work, but probably better would be: Not use a Dialog - but create a dedicated Import Fragment with a RecyclerView instead.

In any case: Just some expectation management. I am super busy at work and at home at the moment. I first need to find some time to spare, before I can implement this.

The old Transistor used a [Spinner](https://developer.android.com/guide/topics/ui/controls/spinner) within a Dialog for this purpose (see [DialogAddChooseStream.java](https://github.com/y20k/transistor/blob/bdfc73644b25714aeec97d18571555dfa5994b42/app/src/main/java/org/y20k/transistor/helpers/DialogAddChooseStream.java)). <a href="https://user-images.githubusercontent.com/9103935/105641575-fdb31c80-5e84-11eb-9b2c-4c27b5134921.png"><img src="https://user-images.githubusercontent.com/9103935/105641575-fdb31c80-5e84-11eb-9b2c-4c27b5134921.png" width="240" /></a> In its standard implementation a user can only pick one item from within the Spinner. So that is not what we want here. Maybe I should adapt an existing Multi-select Spinner solution [[1]](https://www.woolha.com/tutorials/android-multi-select-spinner-example) [[2]](http://thecodecoaster.com/2019/10/multiselect-spinner-item-using.html). :thinking: A bit more work, but probably better would be: Not use a Dialog - but create a dedicated Import Fragment with a RecyclerView instead. In any case: Just some expectation management. I am super busy at work and at home at the moment. I first need to find some time to spare, before I can implement this.

❤️ 2

Bonanzahans commented (Migrated from github.com)

Hi,
thanks a lot for this thread (and the whole app!). I wanted to ask, whether it is still being pursued, as I´m also strongly interested in importing my iTunes playlist.
Greetz

Hi, thanks a lot for this thread (and the whole app!). I wanted to ask, whether it is still being pursued, as I´m also strongly interested in importing my iTunes playlist. Greetz

y20k commented (Migrated from github.com)

@Bonanzahans

I wanted to ask, whether it is still being pursued,

Sorry, but I have not been working on this.

PS. If in the meantime anyone is interested in creating a solution for this, please contact me first.

@Bonanzahans > I wanted to ask, whether it is still being pursued, Sorry, but I have not been working on this. PS. If in the meantime anyone is interested in creating a solution for this, please contact me first.