support for collections #28
Loading…
Reference in New Issue
No description provided.
Delete Branch "collections"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Set up the work to address #7. The goal is to be able to download a collection of related videos the way they are grouped on ArteTV website. Best example of that are series. Few remarks first:
A collection URL is undistinguishable from program URL. Yes it looks like collections IDs and program IDs have different pattern (
RC-023013
vs105612-000-A
) but we already rely on the URL shape to start with, relying then on the ID shape... feels like too many assumptions. These assumptions are just more opportunities/places in our code that may break the day ArteTV changes a bit their inner mechanisms. Who's to say that there are no other pattern for IDs already that we just never came across so far ?collection IDs do return valid
ConfigPlayer
API object, but it is the one of the first program in the collection. This is an indicator that we may deal with a collection URL. So again, another dependency on ArteTV inner mechanisms.For every
ConfigPlayer
object, an associatedPlaylist
object can be fetched from the API. However, despite what we might think, that object only references the previous, current and next program for that particular program. Using that strategy leads us to make two API calls for each program in a collection.If we fetch a
Playlist
API object with a collection ID, Bingo ! We get the entire list of the programs within that collection... HOWEVER if our collection is actually a collection of collections then: nothing useful is returned. Collections of collections are rather common: all fictional series I found are collections containing one collection per season.I feel like we are in a "if you gotta do something wrong, do it right" situation.
The approach I would like to go for is to actually download and inspect the HTML code for the given URL. So no URL parsing, no collection ID or program ID guessing. No "let's assume this is a program ID and see if it fails" strategy etc... As of today, the HTML code of the pages do contain a massive chunk of JSON data. I imagine this is the data the page is actually build/hydrated from. It does contain all the info we need. If they ever change some implementation, there will be where we need to maintain. Feels like a single point of assumption/failure.
Another remark: going forward with this makes me reconsider
db0a954497
's last point.In the case of a 20 episodes series, offering 7 renditions (audio/subtitles configurations) this implementation would lead to
20 + 7*20 = 160
API calls before we even start. This is not reasonable and balances the benefit of knowing the actual original language (when not German no French).Don't take me wrong, it is very anoying for ArteTV not to provide that information: even as a web user...
However, if we use the rendition information from the
PlayerConfig
API object, then we do not need to come up with rendition codes and labels ourselves like we do now and is probably a nest of bugs to come.Also, with that approach, we will be able to fail more comprehensively for the user:
WIP: support for collectionsto support for collections