Bibel TV

The brief

Relaunch Bibel TV's television offering completely: a Mediathek their audience can search, an EPG, four livestreams, and advertising that pays for it — on every set their audience already owns.

The constraint

Four runtimes, one editorial team, one budget, one release schedule.

The alternative quote they would otherwise have received was four separate builds, four submission processes, and an editorial team learning four back ends. For a broadcaster of this size that is not merely expensive; it is the reason multi-platform projects stall after the second platform.

Search that actually searches

Most television catalogues do not search; they filter. A database LIKE finds the programme whose title you typed correctly and nothing else — which on a remote control, where every character costs four key presses, is close to useless.

This one runs on Elasticsearch, so a viewer who gets halfway through a word, misspells a name or remembers a subtitle rather than a title still lands on the right programme. On a device where typing is expensive, tolerance for imprecise input is not a refinement — it is the difference between a search box people use and one they abandon.

The rest of the catalogue is the standard television problem: everything reachable with five keys, tiles loaded as they approach the screen and released as they leave it, and a playback position that survives the app being killed by a channel change.

Four livestreams, and a channel change that feels like one

Running four simultaneous streams is not the hard part. The hard part is what happens between them.

A web player reloads: spinner, black, picture. A television does not, and viewers notice the difference immediately even if they could not name it. Getting a stream handover to feel like a channel change means preparing the next stream before the current one is released, inside a memory budget that does not comfortably hold two, and accepting different answers on each runtime — video/broadcast and the A/V control object behave nothing like AVPlay, which behaves nothing like webOS media.

This is one of the five seams where the shared codebase deliberately stops and a platform adapter takes over. Why those seams exist →

Programme data, now and next

The schedule is fed from the broadcaster's own systems rather than maintained a second time by hand — which is the only arrangement that stays correct, because a schedule that is entered twice is a schedule that disagrees with itself by the second week.

On the client the grid is windowed: a slice of time around where the viewer is looking, prefetched in the direction they are moving, discarded behind them. Now-and-next is derived from the clock rather than polled, so the app stays accurate without talking to the backend every few seconds.

VAST, inside the television player

VAST is an ad-serving standard written for web video players, and an HbbTV player is not one. The ad has to be requested, resolved and played by the same media pipeline that is showing the programme, on a device where switching sources is expensive and where a failed ad call must degrade into “show the programme”, never into a black screen.

Tracking has to survive the same conditions, because unreported impressions are unbilled impressions.

One back end, four front ends

A headless Drupal 9 with Elasticsearch, exposing REST and GraphQL. The editorial team works in one place, and all four applications read from it. There is no “the Tizen version of the catalogue” — there is one catalogue, and four runtimes that render it.