Replacing Web UI framework

Markus Bonet · 2026-03-22T11:19:06+00:00

I know this will be a long shot and I didn't find something in the forum about the topic. Has it been evaluated to use a different Web UI framework? The curr...

DeltaMikeCharlie

Markus Bonet There is an existing API, which would do the actual work of authentication, retrieving and manipulating data, right?

Sort of. Once the HTTP session is authenticated, then the API respects the permissions of the user.

davep

There are two use cases for a UI. The first is configuration management, setting up the system and dealing with changes in channels and services. The second is day-to-day scheduling and management of recordings.

The present interface works reasonably well for the first case, although clunky to use and definitely showing its age.

dave-p/TVHadmin-JS fills the second case for me (at least for the way I use Tvheadend!) but would not scale up to a complete solution. Should there be two UIs for the different uses?

At present there is a lot of ExtJS - specific code mixed in with core functionality. Should the UI be self-contained, communicating with Tvheadend solely via HTTP/HTSP APIs?

DeltaMikeCharlie

davep Should there be two UIs for the different uses?

A nice idea. However, due to the fact that both sets of uses rely on idnodes, the idnode module would have to be written for both. The only minor variation are 'adaptors', these objects use an tree display.

I was thinking that TVH could be adapted to support multiple concurrent user interfaces relatively easily. Just add an interface selector to the url http://tvh_ip:tvh_port/interface/abcd with an empty selector using the default interface that could be selected by the user but would be the existing 'classic' interface unless otherwise set. We could realise your idea by only building new user modules (EPG & DVR) and leaving the old WebUI for admin.

Perhaps the interfaces could be a configuration option, sort of like skins, that could be installed. Your TVHadmin-JS solution could be just another skin. However, TVH could become aware of it and serve it as the default interface if required.

It's a shame that the existing interface is monolithic without the ability to go directly to certain tabs. This could allow a custom interface to call a tab of the existing interface for functionality it does not contain.

I have an outstanding PR that enables the user to select a default home tab. Perhaps that could be augmented to allow the url to control which tab is displayed on startup http://tvh_ip:tvh_port/tab/config-users for example. Maybe a new interface could use an <iframe> to display the config screen of the old interface. It might look ugly, but if it is only used occasionally for admin purposes, it could be tolerable.

DeltaMikeCharlie

davep At present there is a lot of ExtJS - specific code mixed in with core functionality. Should the UI be self-contained, communicating with Tvheadend solely via HTTP/HTSP APIs?

I think that I like what you are implying. It is similar to what I was thinking of with the idnodes, only for the whole UI. There could be a core module dealing with communications to TVH and maintaining a live object store. Maybe it could even implement its own mini API of sorts allowing a wrapper front-end to setup callbacks to receive updated live data, etc.

In the current system, the ExtJS controls have functionality that allows them to directly fetch data from TVH via JSON/HTTP. We could still find an external library that specialises in the JSON/HTTP part and then bolt our front-end-of-choice onto that.

DeltaMikeCharlie

I created a virtual machine with TVH in order to view the 3 alternate interfaces that have been mentioned so far:

Bernhard Berger: https://gitlab.com/bernhardberger/tvh-webui

Poul Kalff: PoulKalff/angularJS

dave-p: dave-p/TVHadmin-JS

The solution from Bernhard Berger is based on Vue.js. Unfortunately, I was unable to build it successfully. It appears to be fairly old and relies on Python2 to build. I was able to build Python2 from source code and the interface build process did progress slightly. Unfortunately, numerous additional failures lead to me abandoning my attempt.

I personally like Vue.js as a framework and I have used it before when I built a quick prototype. I may return to trying to get this to build, just not today.

🙁

The solution from Poul Kalff is based on Angular, is incomplete and feels more like an early prototype. There is a basic EPG grid screen, without navigation. A number of configuration page displays exist, but none appear to have any editing functionality. Although, I did manage to delete a scheduled recording!

The colours are not particularly appealing, however, I personally often use strongly contrasting colours during UI development so that I can see alignments, etc, before selecting a more suitable pallet closer to release. The menu can collapse, which is good for conserving screen real estate.

It does have a consolidated status page that looks nice. In the configuration screen, instead of having sub-tabs, only the major categories are used and the sub-categories are merged into a single page.

I have seen the solution from @davep before and it looks good. It has a nice EPG grid that can be used to set recording an individual programme or a series. The series record is based on the CRID, which is a nice touch. There is also a tabular EPG that is filtered by channel and date that can also add recordings.

This solution does not appear to have real-time data updates. However, as is clearly stated by @davep, this interface does what he needs it to do and would probably not scale very well.

Summary

From the brief examination that I undertook, none of these solutions would appear to be suitable as a replacement UI or even as the starting point for one. The look-and-feel of the solution from @davep is the most polished as well as having the most complete functionality.

If anyone has any experience with or opinions on Angular, React, Vue.js or other frameworks, please feel free to comment.

DeltaMikeCharlie

I was thinking about a centralised JavaScript module for communicating with TVH and it occurred to me that there are 2 communication mechanisms that could potentially be integrated. Firstly, there is the traditional HTTP query/response API mechanism and secondly there is the WebSockets mechanism.

The WebSockets mechanism is currently only used to receive asynchronous data from the server. However, it does already have ability to send JSON data back to the server, that data just currently goes nowhere.

tvheadend/tvheadendblob/eb023c5733f78c2d87cd00fe6265cbf17048b1d3/src/http.c#L1863-L1864

tvheadend/tvheadendblob/eb023c5733f78c2d87cd00fe6265cbf17048b1d3/src/webui/comet.c#L448

In comet.c in the point above, msg actually contains the JSON data, in htsmsg format, that has been received via the WebSocket interface. If there is no JSON, the pointer is NULL.

I played around on a development system and I was able to get the WebSocket interface responding to API commands without too much trouble. For example the following JavaScript:

ref++;
msg = {};
msg.api = 'channel/grid';
msg.ref = ref;
msg.args = {};
msg.args.limit = 5;
socket.send(JSON.stringify(msg));

returns the same data http://tvh_ip:tvh_port/api/channel/grid?limit=5

Just as the HTSP interface is bidirectional, would there be any advantage to having the WebSocket bidirectional as well?

One issue could be that the current HTTP API is relatively synchronous. However, JavaScript can also use promises which are asynchronous.

Another issue could be out of sequence responses. However, the HTSP interface already uses a sequence number as mechanism to manage this.

I'm not sure if there are any data throughput issues that may arise from 11k EPG records, so a lot more testing would be needed.

Is this a worthwhile enhancement that could be deployed on a future WebUI design?

Markus Bonet

What would be the benefit of the websocket approach?
Does the HTTP API lack functionality?

DeltaMikeCharlie

Markus Bonet What would be the benefit of the websocket approach?

That's what I'm asking. Perhaps using a single protocol could help streamline a library.

Markus Bonet Does the HTTP API lack functionality?

No. The WebSocket concept would access exactly the same API, just like the HTSP protocol can as well.

DeltaMikeCharlie

Here are some random thoughts that I have about an EPG Grid implementation. It could go with a new WebUI or be retrofitted to the existing WebUI. I am agnostic about its implementation.

Scaling/Zooming

The EPG Grid window should be able to be scaled both horizontally (time units per pixel) and vertically (height per channel). The maximum and minimum values should be subject to a basic sanity check.

Integrating EPG with Scheduled Recordings

If a channel has scheduled recordings, those recordings need to show as a thick coloured line beneath the EPG event block.

This line can be manually dragged to change the length of the recording.
This will be reflected in the scheduled padding.
If the recording is linked to an EPG entry, the length can not be changed to inside the bounds of the EPG event.
Projected timer entries will be shown as a different colour bar.

Display Details

Clicking on an EPG event should display a list of actions. The default action will be to display the full details, but other actions will be to schedule a recording and looking for similar events, etc. Consider right-click, but touch screen navigation also needs to work.

Maybe a new EPG API call is required to get the earliest and latest EPG entries so that the horizontal scale can be correctly calculated before all of the EPG entries arrive. The alternate would be to recalculate this every time and EPG event is added//changed/deleted.

Parental rating logos should be shown.
Perhaps the EPG events could be colour-coded by genre if desired.-

Channels

In the grid, the "Channels" column should be able to show the channel logo, name, number or a combination. If there is no logo, the number or name should be used instead. Mouse hover should always display the full channel name with the mux and network details included.

Different channels could be able to have different heights so that more frequently used channels can show more details.

Programming

All EPG events use Unix epoch times and are consequently accurate to the second.
Therefore, all events should store a duration in seconds and the overall EPG width should be measured in seconds so that relative EPG event widths can be more easily calculated.

CSS can perform arithmetic operations based on custom style variables calc(var(--custom-variable)). It should be possible to build the HTML objects so that they have custom CSS variables for start and duration and then CSS should be able to take care of determining the actual left: and width: values factoring in the screen size and zoom mode. Very little JS will be required to achieve this.

DeltaMikeCharlie

A GitHub user by the name of 'oliversluke' has submitted a proposal for a new WebUI and asked for some feedback. tvheadend/tvheadend2098

As not everyone on the forum can build TVH from scratch, I thought that I would share some screenshots here for people to see and discuss.

At the moment, it only does the DVR and Status modules, but for a proof-of-concept, that's perfectly fine and provides enough working parts to get an idea of how a full implementation would behave.

Here is the DVR screen and main menu:

It has a fixed left side menu and a tab menu at the top to navigate within an area.

I tried it in Firefox 'Responsive Design Mode' to emulate a smallish phone screen and it seems to adapt well. I'm not sure that it's perfect, but it was certainly able to automatically adjust between a desktop and phone mode. It also responds automatically to changes in landscape/portrait orientation when in phone mode.

I'm not a big mobile phone user, so other opinions will definitely be more valuable here.

It receives live object updates OK. When I change a recording in the original UI from another browser, it changes in the new UI without having to manually refresh.

I think that the menu system, as it currently stands, can be improved. Having the menu fixed at the left and the tabs at the top wastes space. When in small screen mode, the left menu becomes a hamburger icon with drop downs. Maybe I'm used to the existing UI, but the new one wastes too much space. I think that the entire menu should be at the top.

Perhaps the left menu could be hidden by default providing more visible screen real estate. A hamburger icon could slide the left menu into view when needed.

I like the fact that each tab has its own URL meaning that the user can navigate directly to a tab rather than having to navigate via a monolithic app.

I like the idnode management window and the fact that it shows the tooltips by default. It would be nice to be able to switch tooltips off because it makes the window very tall.

The existing UI shows tooltips when the mouse hovered over a field, but it did not stay on for long enough and probably did not work on touch screens. Maybe a little icon up in the title area could be used to toggle the tooltips on and off as required.

The existing TVH system also has some help pages and it would be nice to integrate these in the fullness of time.

The themes concept is good. It is early days so some tweaking may be required.

The 'enabled' property is currently not shown on the grid display. Again, early days.

Idnode grids currently have an option to display 'All'. This is currently missing.

Also, columns can not currently be reordered and hidden. 'Early days'.

When an item is selected, a new block appears announcing this. I feel that this occupies too much space and makes the list jump around.

Please don't think that I am being overly negative or critical. Feedback can often be received in this way, but I genuinely like a lot of what I have seen so far.

Please feel free to provide feedback or ask for any screenshots that you think that I have overlooked in my evaluation. I hope that the author joins us here in the forum so that we can continue this discussion.

DeltaMikeCharlie

It's still 'early days', however, there are some existing UI parameters in the config that could be useful for the proposed new UI.

/api/config/load

theme_ui, page_size_ui, ui_quicktips, uilevel, uilevel_nochange, caclient_ui, info_area, chname_num, chname_src, date_mask, default_tab, dvr_show_seconds, label_formatting, language, prefer_picon, chiconscheme

http_server_name (Show next to the logo if not the default)

Several of these also have user-specific versions.

DeltaMikeCharlie

There has been some discussion in the admin/dev chat group. It was too long to copy verbatim, so here is a summary:

The density of the modern UI needs some work. The classic UI is not pretty, but it is efficient and effective.

The classic UI does too many things at once for day-to-day use. It has 2 overall function groups that are integrated: configuration/administration and end users. User permissions and view levels go some way to addressing this already. Although not universally agreed, perhaps once the initial config has been complete (Wizard) then then config could be hidden behind a drop-down menu or an icon.

Some thought was given to having 2 UIs, but profiles controlling a single UI seemed preferable. This opinion was not universal, as some saw the existing config tab as being unobtrusive enough.

A timeline EPG was mentioned as being highly desirable in a modern UI. The ability to filter the EPG grid by channel was mentioned as was the ability to perform a search.

Perhaps there should be 2 EPG tabs, one for the classic tabular format and one for the modern timeline format.

-- # --

With respect to EPG search, my personal opinion is that it should be possible to search via CRID for other occurrences of this episode as well as other episodes in this series with the ability to set recordings for found events directly from the results list. The search should indicate if the event is already being recorded, or not, which can be set with a single click or maybe checkbox or slider switch. Full search capabilities based on title / description / genre / time-of-day / channel / bouquet / etc, should be considered standard.