Open n-ce opened 5 months ago
Thanks for the suggestion! To confirm:
discover
, history
and favorites
discover
corresponds to the "home feed" (or recommended videos)history
is historyfavorites
is liked videos (specifically https://www.youtube.com/playlist?list=LL)playlist1
, playlist2
) - are these the display names, or their playlistId?
- And the other playlists (
playlist1
,playlist2
) - are these the display names, or their playlistId?
Those are display names. Currently youtube created playlists (non-editable) are converted into ytify playlists (editable) so playlist id is not relevant here.
In the future though, I am interested in introuducing channels & ytplaylist (non-editable) support for which the id will be fruitful. I think those changes can be incorporated later on, what do you think?
Also
discover
should not be added to the export.listenLater
but i'm not sure if that should also be imported from Watch Later
.I think you should introduce versioning into your schema so your software can parse it correctly. Also consider using a arrays for the videos so you can preserve the order.
I don't use YouTube music much, so I don't know what people store in it and what they usually want to export, but I realize there are subtle differences to be considered.
For example, there'a predefined playlist LM
which is Liked Music
and can be accessed from https://www.youtube.com/playlist?list=LM. I think this one maps to favorites
more accurately.
There's also Episodes for Later
which has an id SE
- https://music.youtube.com/playlist?list=SE, but is not viewable from https://www.youtube.com/playlist?list=SE
I think you should introduce versioning into your schema so your software can parse it correctly. Also consider using a arrays for the videos so you can preserve the order.
A versioning system might increase complexity and extra code would be needed to handle it and i'm not ready for that yet. In any case there wont be a problem for now since unknown collections just get converted into playlists.
I don't use YouTube music much, so I don't know what people store in it and what they usually want to export, but I realize there are subtle differences to be considered. For example, there'a predefined playlist
LM
which isLiked Music
and can be accessed from https://www.youtube.com/playlist?list=LM. I think this one maps tofavorites
more accurately. There's alsoEpisodes for Later
which has an idSE
- https://music.youtube.com/playlist?list=SE, but is not viewable from https://www.youtube.com/playlist?list=SE
After pondering on this for a while, I think it would be right to let users decide which collections they want to import. If they want to import watch later it would be imported as ytify playlist Watch Later
same with favorites
. It all depends on the prompts we ask the user of what they want to do with their data like
Import history
[x] YouTube Music
[ ] YouTube
Import favorites
[x] YouTube Music
[ ] YouTube
Import other playlists
[x] myPlaylist1 from YouTube
[ ] myPlaylist1 from YouTube Music
[ ] watchLater from YouTube
[ ] ....
^ I'm still trying to think about the best way to approach this - should we select the source first (e.g. YouTube vs YouTube Music) and then go from there (since it will narrow down the choices later)
I still don't have a final opinion on it. And also needs to be intuitive from both interactive and non-interactive modes #1
Hi, I am the developer of ytify, a similar platform like the others supported by yt2alt. I would request the possibility of exporting to the ytify data format. It's a rather simple data format and should be relatively easier to implement.
Here's the full example export : [ytify_library.json] (https://github.com/iBicha/yt2alt/files/14969525/ytify_library.3.json)
apart from history, favorites(liked videos), playlists can also be added
Thanks for maintaining a project like this.