I see Series and Episodes, so rclone could present a directory full of Series and within each of those would be Episodes.
Yes, and I have sample json returns to work with too.
I see categories in the API so we could do something with that.
Potentially, but categories are completely made up by the maintainer. It would be less important, but still a feature to be considered, nonetheless.
That would be your first job - decide how to show the existing streams within a file system structure
I had a working proof of concept to do this with a set of directories/placeholder files on my local machine, but the basic idea:
- Get VOD:
- this returns a long json of videos, sample here: getv - Pastebin.com
- A directory can be abstracted from the name, so "name": "Example Video 1" would render a directory with the same name, with the intent of loading that very same video file as a virtual file in that directory.
- Get Series
- Series are a bit harder, but the idea is the same.
- get a list of available series: gets - Pastebin.com
- a directory name is abstracted from the name. I have never seen an exact duplicate name, but if that is an issue, we can append the series_id to the series top level directory, guaranteeing it to be unique.
Now we are left with
.
├── movies
│ ├── Example Video 1
│ │ └── Example Video 1.mkv
│ ├── Example Video 2
│ │ └── Example Video 2.mkv
│ └── Example Video 3
│ └── Example Video 3.mkv
└── series
├── Example Series 1
├── Example Series 2
└── Example Series 3
As you see, the movies directory and sub dirs can be constructed with 1 api call. The series directory and 1 level below (the series names) can be constructed also with 1 api call.
Note: at this point, querying for the vod file data is irrelevant. It's metadata, like plex or emby would generate.
The file's actual location can be derived into a simple http link:
http://<server:port>/movie/<username>/<password>/<streamid>.<extension>
We now know that movies/Example Video 1/Example Video 1.mkv is found at
http://example.com:80/movie/exampleuser/examplepass/97675.mkv
For series, we need to continue down the path and make some subsequent queries for each show. If I traverse Example Series 1, an api call would be made to get the series info. The child directories and all files of Example Series 1 can be derived from this 1 api call. Here are the returned results: seriesinfo - Pastebin.com
- the naming convention used by the api is odd. episodes["1"] is actually season 1.
- episodes["1"][0] is the first episode of season 1
- episodes["2"][0] is the first episode of season 2
now with this api call, you've built out the entire directory structure of the Example Series 1:
.
├── movies
│ ├── Example Video 1
│ │ └── Example Video 1.mkv
│ ├── Example Video 2
│ │ └── Example Video 2.mkv
│ └── Example Video 3
│ └── Example Video 3.mkv
└── series
├── Example Series 1
│ ├── Season.1
│ │ └── Example Series 1 - S01E01 - First Episode Title.mkv
│ └── Season.2
│ └── Example Series 1 - S02E01 - Second Season First Episode.mkv
├── Example Series 2
└── Example Series 3
Similarly to VOD, a series file's actual location can be derived into a simple http link:
http://<server:port>/series/<username>/<password>/<streamid>.<extension>
We now know that s01e01 of Example Series 1 is found at:
http://example.com:80/series/exampleuser/examplepass/83550.mkv
These api servers have basic api rate limiting, although undocumented and varies by host. Getting the series child directories should be done only on demand and then cached for a specified time, like we all know and love rclone to do already with other remotes. A limit should certainly be placed on making these calls, since apps like plex or emby might scan the series directory and use a lot of queries very quickly.
For example, one host of mine during testing limited me after about 15 api calls in 15 seconds. I had to build in a tick-tock timer to prevent any api call from exceeding approximately 2 per 5 second interval. When i set the series api calls to about 1 every 5 seconds it ran perfectly for about 20 minutes (I was querying about 200 shows). I see rclone's tpslimit and tpslimit-burst being very useful here. The good thing here is that a long cache time is ok, since (in my experience) once the file is set in the xcodes api, it doesn't get changed often. And if it does, typically, the stream ids all the stay the same.
I'm guessing this would be read only
You are correct.
That's a dump of info, sorry for the long wall of text. Admittedly, i need to study up on the code to see how this all plays out, but I wanted to get answers over to you as quickly as possible. What do you think?