MediathekViewWeb puts the MediathekView film list in a browser tab

The web front end of a desktop project

MediathekViewWeb is a web interface for fast and easy access to the film list of the MediathekView project, and the comparison with the desktop application is made in the first paragraph.

Unlike the desktop application MediathekView, with MediathekViewWeb you neither have to install a program nor load a film list manually. The search is available in the browser immediately, and the documentation stresses that it also works on smartphones and tablets.

The architecture behind that is a client and a server with a search index of its own, and the fact that the queries are processed directly on the server is listed as a feature, blitzschnelle Suche, Suchanfragen werden direkt auf dem Server verarbeitet. That is the same catalogue the desktop client uses, reached through a different front end, and the film list is the MediathekView one rather than a separate index.

The feature list in the readme is short. No installation, fast search, a capable search syntax, a mobile-friendly responsive design, an integrated video player for many items, and RSS feeds so you can subscribe to a search and hear about new content.

The licence is GPL-3.0, the primary language is Svelte, the site is mediathekviewweb.de, and the last push to the repository was on 2026-05-17. There are no GitHub releases, so the deployment path is the container in the repository rather than a tagged artefact.

Selectors are how you search

The search syntax is the heart of the interface, and it is a small set of prefix characters.

You type a term into the search field and by default it is searched in the topic and title fields. For more precise results you use selectors, each of which is a symbol followed by your search term with no spaces.

The exclamation mark is the sender, so !ARD finds content from the broadcaster ARD. The hash sign is the topic, so #Tatort finds content with that topic. The plus sign is the title, the asterisk is the description, and the greater-than and less-than signs are duration, so >80 finds items longer than eighty minutes and <10 finds items shorter than ten. With no selector at all, a plain term searches topic and title.

Duration is the one that has no counterpart in most search interfaces, and it is the reason the syntax is worth learning. A broadcaster archive is not a catalogue of films, it is a pile of news segments, documentaries and episodes, and being able to say longer than thirty minutes or shorter than ten minutes is often the difference between a usable result and a thousand hits.

The documentation then gives four worked examples, and the first one combines everything.

!ard !wdr #tatort >80

That is every Tatort episode from ARD or WDR that runs longer than eighty minutes. The second narrows to documentaries about space on ZDFinfo.

!zdfinfo #weltall #universum >30

And the third finds short items from a specific channel.

!tagesschau24 <10

The last one shows the comma syntax, which is worth a paragraph of its own in the documentation, and it is the fourth example.

OR across selectors, AND across comma separated words

Two rules govern how the pieces combine, and they are the same two rules you would design yourself if you were writing the parser.

The first is that repeating a selector means OR. Using the same selector more than once links the values with OR, so !ARD !ZDF #Reportage finds all reportages that aired on ARD or on ZDF.

The second is that several words in one value mean AND. To search for content that must contain several words, you separate them with a comma, and this works for the sender, topic, title and description selectors.

!ard !ndr #sturm,der,liebe #rote,rosen

That example is the one to read carefully, because it exercises both rules at once. The sender is ARD or NDR, the topic must contain all three words of Sturm der Liebe, and the second topic must contain both Rote and Rosen.

Searching for content about Sturm der Liebe and Rote Rosen on ARD or NDR is a question about two shows that share a broadcaster, and the answer is a query that no plain search box would produce. That is the case this syntax exists for.

There is also a house style detail that matters in German. The search is not case sensitive, and it handles umlauts flexibly, so Ö, oe and OE return the same results, and special characters do not have to be typed exactly.

Two switches, sorting, and feeds that carry the whole query

Beyond the query language there are two toggles that change the scope of a search, and the second one is the more interesting.

The Überall switch, when enabled, makes a general term without a selector search in all fields: sender, topic, title and description. It is for a broad, unspecific search, and it is off by default because the default of topic and title is the more precise behaviour.

The Zukünftige switch changes what is in the index at all. By default only content that has already been broadcast is shown, and with the switch enabled, future broadcasts are included in the results as well. For a broadcaster archive that is a live, growing catalogue, being able to see what is scheduled is a different kind of feature from the search itself.

Results can be sorted by several criteria, including date, duration and sender, ascending or descending.

The RSS feature is the one with the most engineering in it. Every search query can be subscribed as an RSS feed, and you get the feed link by clicking the RSS symbol. The documentation is specific about what the link encodes: the complete search state, with the selectors, the sorting, the duration filter and the Überall and Zukünftige switches, so that even complex searches can be subscribed directly and you are informed automatically about new results.

That is a nicer design than encoding the query in a path or a fragment, because the feed is then a stable, shareable address that the server can act on. It is also the reason the query language has to be complete: every switch has to survive the round trip through a URL.

Where it stops: HLS streams you cannot download

The FAQ answers the question that decides whether the web interface is enough for you, and it is worth reading the answer carefully.

ORF and SRF often offer their content only as HLS streams rather than as a single video file. Those streams can be played directly on the website, but the download only produces an .m3u8 playlist file that contains no video data.

That is a limitation of the format rather than of the implementation. HLS is a manifest of segments, so a link to a manifest is not a video, and the project does not pretend otherwise.

The recommended way around it is to use the desktop client MediathekView, or specialised command line tools such as yt-dlp, and the documentation says that alternatively it also works with the VLC Media Player. It then gives a step by step for VLC, which is unusually thorough: copy the .m3u8 link from MediathekViewWeb to the clipboard, open the network stream dialog with Ctrl+N, paste the link, use the arrow next to Play to choose Convert, pick a profile such as Video - H.264 + MP3 (MP4), and in the wrench settings enable the option to keep the original video track and the original audio track so the original quality is preserved and time is saved. Then choose a target file and press Start.

So the honest summary of the product is that it is excellent for finding and watching, and the download path has a hole for two broadcasters that the documentation is upfront about.

OpenSearch and Valkey in a compose file

The repository is a client and a server with a search index, and the compose file shows the whole stack.

services:
  opensearch:
    image: opensearchproject/opensearch:3
  valkey:
    image: valkey/valkey:9-alpine

OpenSearch is the index, configured as a single node with the memory lock enabled and a fixed heap of 512 megabytes, and the security plugin is disabled and the demo configuration is skipped. An admin password is still set in the environment, and the data directory is a named volume so the index survives a container replacement. The service is published on port 9200.

Valkey is the cache, at version 9 on Alpine, with a persistence command of save 60 1, which writes the data set to disk once a minute if a single key has changed. Its data is a named volume as well, and it is published on port 6379.

Two things about that configuration deserve a second look before you run it anywhere but a laptop. The security plugin is disabled, so the search index on port 9200 has no authentication, and the compose file publishes that port to the host. On a machine with a routable address, that is an open search index. The stack is also published without a reverse proxy in front of it in this file, so the intended deployment probably adds one.

The rest of the repository is the application itself. There is a client/ directory, a server/ directory, a data/ directory, images/ for the screenshots, a Containerfile, a docker-compose.yaml, a.containerignore, a.gitlab-ci.yml for the build, a.prettierrc, a.editorconfig, a CONTRIBUTE.md and a VS Code workspace file. The use of GitLab CI rather than GitHub Actions is visible in the repository root.

Maintenance, hosting and the shape of the project

The repository is not archived, and the last push was on 2026-05-17, so the code is being worked on. There are no GitHub releases, which fits a project that is deployed from a container rather than consumed as a package.

The language split in the tree is worth noting, because it explains the choice of stack. The client is Svelte, and the description of the project as a web interface is literal. The server sits between it and the index, and the search queries are processed on the server, which is what makes the selector syntax possible: a browser sending structured queries to something that understands them, rather than the browser filtering a list it was handed.

The document model also explains the mobile support. The responsive design works on desktops, tablets and smartphones, and the search is available immediately in the browser with no installation, so a phone browser is a first class way to use it rather than an afterthought.

The project is German throughout, the topics list the German broadcasters and the language tag is German, and the whole thing is aimed at the MediathekView catalogue.

For an evaluation, the question is whether you want the web interface or the desktop client. The two overlap heavily for search and playback, and the web one wins on convenience, while the desktop one keeps the download capability for the HLS-only broadcasters.

Editorial conclusion

Adopt MediathekViewWeb when you want to search and watch German public broadcaster content from a browser or a phone without installing the desktop client, and you are happy to run the search backend yourself. Do not adopt it as a replacement for MediathekView, because the project says so itself: HLS-only content from ORF and SRF cannot be downloaded through the web interface, and the documentation points at the desktop client, at yt-dlp, or at VLC for those cases. Verify first which search index your deployment points at, that your OpenSearch and Valkey volumes are persisted, and that the security settings in the compose file are appropriate for a host that is reachable from outside your network.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mediathekview/mediathekviewweb on GitHub
4. Project website
5. README