external channels.json

[bagbag]

To avoid the need for new releases when a URL changes or a new one is added (channels.json history) and the delay at F-Droid, I suggest to download the channels.json from the web and cache it as a fallback.

I offer you to use the same infrastructure I use for MVW and the "Filmliste Verteiler" for MV. That would be a S3 Storage paired with a self-hosted CDN over multiple servers.

[cemrich]

@bagbag Thank you very much for your generous offer! I thought about that but love the simplicity of a bundled channel list.

I think I'll continue bundling the channel list but write a small api endpoint over at https://github.com/cemrich/zapp-backend to fetch url updates. New or removed channels are an almost non existing issue for zapp.

[bagbag]

Oh, I remember from a mail, that you have your own backend at Heroku. So Nevermind, thats obviously located better in your backend than at some kind of 3rd party service.

Something off topic

As I once told you in a mail, I would still like to see your neat app as an official MediathekView Client for Android, with its own sub-forum at [https://forum.mediathekview.de/](https://forum.mediathekview.de/) like MVW and the Kodi addon. As it basically uses the Filmlists from MV indirectly via the MVW API, I think that'd be a perfect fit. Sometime in the distant future with MVW 2.0, I'd also like to include live streams, which means we could merge our backends instead of having two - another benefit.

[cemrich]

@bagbag I was not aware you are planning on continuing development for MVW 2.0.
I think joining MediathekView would be a great benefit for Zapp. However, it comes at a cost: Zapps main feature for its users would be the Mediathek function. This requires the MediathekViewWeb backend to be actively maintained for the foreseeable future, because I do not have the resources to so and there is no alternative out there right now.

[bagbag]

I was not aware you are planning on continuing development for MVW 2.0.

I absolute am doing that, I just don't take the direct way, but the way where I have the most fun, learn the most and of course do the most over-engineering 😅 (v2 branch, outsourced library).

I think joining MediathekView would be a great benefit for Zapp.

Great! So whenever you give me a "yes", I'd talk to the other members about my (and your) wish and punch it through :)

However, it comes at a cost: Zapps main feature for its users would be the Mediathek function.

That's a much used feature right now too, isn't it? The MVW api gets a lot of hits from external applications. I don't know how much comes from which, but afaik Zapp is the largest external consumer of my API.

This requires the MediathekViewWeb backend to be actively maintained for the foreseeable future, because I do not have the resources to so and there is no alternative out there right now.

Do you mean the backend in your app or the MVW api itself?
Latter case: don't worry, the amount of users of MVW are reason enough to at least keep it running.
First case: That applies right now too, I guess. But if Zapp is a official app of MV, that's an additional reason to maintain translation layers at my api (which I think I would do anyway, because of Zapp) - at least for some time until Zapp is updated and most users use that version. And I can also imagine of creating pull-requests to Zapp for MVW related changes.

[cemrich]

@bagbag All right then! I have a few days off at the beginning of Juli where I can work a few extra hours on Zapp. So the timing is good.

Should I send an additional query parameter to the MediathekViewWeb endpoint to distinguish Zapp users?

[bagbag]

I don't think you have to do anything, except saying hi. I'll send you a mail as soon as I've sorted this out in the team.

I don't really have analytics for api usages at the moment, but if you would add a User-Agent (I think thats better suited than a query parameter) like Zapp/2.2.2 (Linux; Android 9.0) (syntax reference at MDN), I could use that in the future and provide useful information for us, so that you know what android you should keep supporting and for me to know which api version is used and needs translation layers.

[cemrich]

Nice! I opened #159 for the user agent issue.

[bagbag]

Just in case you don't check it regularly: I've sent you a mail.

[cemrich]

This feature will be released in 3.2.0