Version 3 discussions

[pducharme]

Hi, I followed the installation for OS X : sudo pip3 install pytoutv. Everything is good.

Just want to know how to get access to EXTRA files (or at least 720p). I don't plan on testing, just want to get the version with 720p downloading!

[eepp]

This feature is not implemented in pytoutv currently, sorry.

[pducharme]

Ok, but what about the Extra branch? and the toutv-extra project that has it too?

Le 21 janv. 2016 à 03:22, Philippe Proulx notifications@github.com a écrit :

This feature is not implemented in pytoutv currently, sorry.

— Reply to this email directly or view it on GitHub https://github.com/bvanheu/pytoutv/issues/67#issuecomment-173493622.

[eepp]

I don't know the state of those branches.

@bvanheu, @simark: what's up with this?

[simark]

@bvanheu started work on the extra branch.

According to the pull request (#61), it's possible to login, list content and fetch 720p episodes of regular content. It's not possible to fetch extra content though. I'd like to work on this, but I am a bit stuck. I don't have access to an iPhone (or maybe a recent Android?) to analyze how the apps access extra content.

[simark]

If toutv-extra [1] works though, it should be possible to learn from that.

[1] https://github.com/scarpentier/toutv-extra

[bvanheu]

sorry for the lack of presence on this thread :3

simark is right, you can log in & fetch 720p content. The thing is, I couldn't find any API to fetch the actual list of shows available in the extra section. the scarpentier/toutv-extra works because you first get the show / episode # from the website, then give that to the script.

[simark]

@eepp and I spent some time investigating the iPhone application using mitmproxy. We got a minimal working example of login, and were able to fetch some data about the shows. It seems like the new API is very much centered on what they want the applications to look like, rather than formatting the data in a logical way... but at least the data is there.

You can try it if you want: https://gist.github.com/simark/ca21d9e3bfec69cfb18c

The usage is

$ python3 toutv-v2.py your@email.com yourpassword

It will log in and then display some user info and some info about a show.

I now realize that we did pretty much what @bvanheu did for authentication in the extra branch (although not exactly the same way). But at least we got familiar with how things work, so it should help in the future.

[eepp]

I guess this isn't the most appropriate place to discuss this, but @simark and I were considering a little refactoring of pytoutv accompanied by a major bump.

Here's what I suggest. WDYT?

Project structure

• Create a branch from actual master branch for pytoutv 2, which becomes the legacy version. It can still be maintained on its own if time allows.
• Move library from toutvcore package to toutv3 package. This name makes more sense to me for the library than with the weird core suffix.
• Move CLI client from toutvcli to toutvcli3 package. The actual CLI entry point would still be named toutv.
• Create a pytoutv3 "metaproject" depending on toutvcli. This is the official PyPI project we refer to in the docs. Eventually we can introduce a new interface (new PyPI project), make pytoutv3 depend on it, and bump its minor.
• Update README.md accordingly. Move examples elsewhere, perhaps on the project's wiki, to keep the README.md file as brief as possible: what's pytoutv, how to install, pointers to other documents.

All those 3s are there to keep the actual packages as they are without creating conflicts on a given system. Since we're not working on this project full-time, I wouldn't even support the v1 API in pytoutv 3. The v2 API seems to be a superset of v1, containing even more metadata, and of course more video bitrates. Including the major version as part of a package name is not uncommon in the Python realm.

toutv3

• Use v2 API exclusively.
• Refactor so-called business objects so that we only keep what we currently need as actual object properties. We could save the full decoded JSON dict as some raw_properties property or alike. This should feel more pythonic than mapping the API attributes as is to our library objects: API names can change in the future, ours should not, and ours should be stylized like Python names.
• Allow to save and restore a client's access tokens and HTTP cookies (more on this later).
• Add optional credentials parameters to the client's constructor to support EXTRA features.
• Emission -> show.
• Maybe use a more object-oriented approach here? Like instead of calling client.get_emissions() and then passing one of those objects to client.get_episode_by_name() to get an episode object, why not something like client.get_shows(), and then with such a show object, show.get_episode(...), and then episode.get_videos() (should find a better name for this one), and then video.download(...).

toutvcli3

• Save the session's state between invocations of the command to make it more browser-like. There is no need to connect with credentials each time. All of this should be part of the (already-existing) cache I guess, and it is debatable whether this cache is created/updated by the CLI or by the library itself.
• Add optional dependency to colorama or termcolor and output colored text if it's available at runtime. This feature is already available for the progress bar.
• I would not add a login action. I would simply read a ~/.toutvrc file containing the credentials to use, which could be overridden by arguments to the toutv command itself, or by environment variables. I guess the cache would need to take the username into account; it doesn't make sense to try a saved session token for user A when trying to make API calls as user B; we need to reconnect, or use user B's cache (we could keep per-user caches). I wouldn't be against a config action however, à la Git, actually editing the ~/.toutvrc file.

qtoutv

Considering we're not working full-time on pytoutv, do we even continue to maintain qtoutv, or do we focus future UI efforts on a curses-based interface instead, which we already started in the nctoutv branch? I'm thinking the typical pytoutv user would be more interested in a curses UI.

Other ideas

I can't help but think that a very user-friendly interface would be to augment the TOU.TV website itself with download buttons everywhere an episode box/page exists using a browser extension.

[bvanheu]

my 2cents:

Totally agree where you're leading this project!

One thing though, instead of working on a GUI, we would rather maintain a Kodi plugin (and I'm willing to do so).

I'm running Kodi on Raspberry Pi and have performance issues running toutv-cli because of THE json -> business objects operation. I definitely think we can trash this.

[simark]

One thing though, instead of working on a GUI, we would rather maintain a Kodi plugin (and I'm willing to do so).

I'm running Kodi on Raspberry Pi and have performance issues running toutv-cli because of THE json -> business objects operation. I definitely think we can trash this.

As a RPi-based Kodi media center owner, I concur :)

[eepp]

Hello people,

How about the following commands for the upcoming toutv3 CLI?

toutv3 [GENERAL OPTIONS] COMMAND [COMMAND OPTIONS]

Command	Description
list-shows	List show summaries (title, URL, key, etc.). Mark the ones that are premium only when the user is not premium. Mark the ones that are bookmarked by the user.
list-sections	List the top-level sections (À la une, Rattrapage télé, etc.); short names and titles.
view-profile	View the user's profile.
view-section	View a specific section using its short name. This shows the subsections, and for each subsection, a show summary.
view-show	View a specific show, with more or less details depending on the options. A show object has all its season lineups, and each season lineup contains the episodes and their details, but we still don't have the available bitrates at that point. Maybe warn if this show is premium and the user is not.
view-episode	View a specific episode, perhaps using the URL or some other unique key, and fetch the available bitrates at this point. Fetching the bitrates implies 4-5 HTTP requests, which is why I woud not list all of them in view-show.
fetch-show	Fetch all the episodes of a given show.
fetch-season	Fetch all the episodes of a given show's season.
fetch-episode	Fetch a specific episode, perhaps using the URL or some other unique key.

I would also add the toutv commands, and implement them as aliases of the ones above, as much as I can (things are not the same with the v2 API).

WDYT?

[gboudreau]

The EXTRA features are now integrated in master, but there is a lot more discussions about v3 in here that we probably don't want to throw away, so I'll just change the issue subject instead of closing it.

[pducharme]

@gboudreau How to use it? i did install on my OS X using this command

sudo pip3 install pytoutv

But when I try to run a toutv login (with my username), I got the error that login is not a recognize command...

[gboudreau]

Not sure where pip takes its source from. Maybe we need to tag the master branch to create a new pip release..? @simark ? @bvanheu ?

[gboudreau]

@pducharme Until pip is fixed, you can download this repository, then run

sudo pip3 install .

from within the repository folder.

[simark]

@pducharme Until pip is fixed, you can download this repository, then run

sudo pip3 install .

from within the repository folder.

Note that you can do directly:

$ sudo pip3 install https://github.com/bvanheu/pytoutv.git

[simark]

Not sure where pip takes its source from. Maybe we need to tag the master branch to create a new pip release..? @simark ? @bvanheu ?

We have to manually do a release and upload it to pip. I can take care of that in the next few days, since it has become a bit more quiet in the last few weeks. I don't know if we should call it v3 or not though.

[simark]

I have just done a 3.0.0 release. I decided to go with version 3, since the login & Extra fetching feature is rather important.