[Bug] /api/v1/auth/playlists returns no videos for saved playlists

[iBicha]

Describe the bug
/api/v1/auth/playlists returns both created and saved playlists. But it returns invalid info for the saved playlists.
The interesting fields to look at:

• author (wrong author technically?)
• authorUrl
• authorThumbnails
• description
• descriptionHtml
• viewCount
• isListed (this should be true, since it was brought from a public channel)
• videos (missing)

This is retuned for the saved playlist

	{
		"type": "invidiousPlaylist",
		"title": "100 Seconds of Code",
		"playlistId": "PL0vfts4VzfNiI1BsIK5u7LpPaIDKMJIDN",
		"author": "ibicha",
		"authorId": null,
		"authorUrl": null,
		"authorThumbnails": [],
		"description": "",
		"descriptionHtml": "",
		"videoCount": 144,
		"viewCount": 0,
		"updated": 1688688000,
		"isListed": false,
		"videos": []
	},

but if we call /api/v1/playlists/PL0vfts4VzfNiI1BsIK5u7LpPaIDKMJIDN for the saved playlist, we get

{
	"type": "playlist",
	"title": "100 Seconds of Code",
	"playlistId": "PL0vfts4VzfNiI1BsIK5u7LpPaIDKMJIDN",
	"playlistThumbnail": "https://i.ytimg.com/vi/DC471a9qrU4/hqdefault.jpg?sqp=-oaymwEWCKgBEF5IWvKriqkDCQgBFQAAiEIYAQ==&rs=AOn4CLCNWUPFX0NRF27C3tP_BjyOeqPXew",
	"author": "Fireship",
	"authorId": "UCsBjURrPoezykLs9EqgamOA",
	"authorUrl": "/channel/UCsBjURrPoezykLs9EqgamOA",
	"authorThumbnails": [ THUMBNAILS_AVAILABLE_HERE],
	"description": "The fastest code tutorials in the west",
	"descriptionHtml": "<p></p>",
	"videoCount": 144,
	"viewCount": 1191310,
	"updated": 1688688000,
	"isListed": true,
	"videos": [ VIDEOS_AVAILABLE_HERE ]
}

Steps to Reproduce

1. Add a playlist from a channel to your profile (saved playlist)
2. Observe response on /api/v1/auth/playlists
3. Observe response on /api/v1/playlists/PLAYLIST_ID where PLAYLIST_ID is of a saved playlist

[absidue]

I think you should change this issue to a feature request, as it currently just returns the information it has in the database, this will require it to duplicate the behaviour of the /api/v1/playlists/ endpoint.

Personally I'm against having multiple API endpoints for the same thing, especially when it's not hard to figure out which playlists are Invidious ones and which ones are saved YouTube ones (the IDs for the invidious ones always start with IV). It's literally less work for you to add an extra if to your code, than for this feature request to be implemented in Invidious.

invidious/src/invidious/playlists.cr

Lines 315 to 325 in 69e2eac

	def get_playlist(plid : String)
	if plid.starts_with? "IV"
	if playlist = Invidious::Database::Playlists.select(id: plid)
	return playlist
	else
	raise NotFoundException.new("Playlist does not exist.")
	end
	else
	return fetch_playlist(plid)
	end
	end

[iBicha]

I think you should change this issue to a feature request, as it currently just returns the information it has in the database, this will require it to duplicate the behaviour of the /api/v1/playlists/ endpoint.

I have to disagree, this qualifies as a bug. API callers have no notion of created and saved playlists (at least not in this call) and it can only see that some of them do not have videos.
What's in the database, or the fact invidious created playlists start with "IV" are implementation details that should not leak outside of Invidious, otherwise they become part of the API, and really hard to get rid of later.

I see in this comment that we want to split the two kinds of behaviours, which is fair, since one require a database read, and the other require fetching from youtube. But this expectation has not been set in the API.

• The api could for example return only the created playlists,
• or it could contain both, with a documented way of distinguishing between the two
  • (for example, the absence of the videos field, or be more specific on the type, since they are both invidiousPlaylist for now)
• or it could contain both types fully populated

I know I can patch things up in my code, but a proper fix does not belong there, and it can break once someone decides to fix things in the API

[SamantazFox]

I'm in favor of splitting the two endpoints.

An easy way to fix that is to keep /api/v1/auth/playlists as it is, for backward compatibility, and then to create /api/v1/auth/playlists/saved and /api/v1/auth/playlists/created to list, well save/created playlists.

[iBicha]

I have changed my approach a bit so that I don't have to distinguish between saved and created playlists.

First, some info is almost always available: title, author, videoCount. That's enough to display in a "list of playlists view"
In a playlist videos view, I would use the videos field and compare it with the videoCount

• saved playlists have no videos
• created playlists have a 100
• playlists in search results has two

And I treat it as "it doesn't matter - if you're missing videos for display, grab more"

So it's not really a blocker for me as API consumer, but feel free to keep the issue open for tracking the api improvements.

Thank you both for your input!