Tvheadend

Is there a way of determining which columns appear in the port 9981 web site "Upcoming/Current Recordings" list?

Yes, click on the right hand end of any column heading and a pop-down menu appears. Click on Columns and select those that you want (or actually, deselect those you don't want).

As to the rest of your comments, I agree. I also wish that choosing the column widths was persistent and more determinate.

As regards channel display, that information is already displayed in the Channel column, so doesn't really need to be shown again in the dialog, although it wouldn't hurt.

The channel name is displayed in the dialog title bar in the 4.3 versions. If you have channel icons, then they are also displayed in the dialog, which is useful if your HD channels have a different logo to your SD channels.

Just curious now. Does it show which version is planned to be recorded for a merged channel?

On a merged channel, they'd normally all have the same name and channel number, so they are effectively indistinguishable at the UI.

There's no actual planning for recordings.

When a recording is starting, it tries to find the best tuner for a merged channel. From memory, if a tuner is already recording from a mux that has the merged service, then that is used in preference to tying up a second tuner. I think that occurs irrespective of other settings that could influence it to use a different tuner (such as weights, prefer HD, etc.)

On non-merged channels, or systems (like mine) where some are merged and some are not, there are some settings to influence the decision on autorecs. These mostly hide in the expert settings on recording profile. So, you can prefer HD or SD; and tvh 4.3 has some options to prefer channels that have more merged services than channels showing the programme with fewer merged services, the intention being that it gives more failover ability if a service fails to tune.

So, say you have a merged channel with HD and SD and no other recordings, then with appropriate config it should prefer the HD service, but if it can't tune for some reason, it would then use the SD service, but if that fails it would retry HD then SD again, ad infinitum.

Thanks for the explanation. I suppose I expected some planning so it could give feedback to the user at the point of setting up the recording as to whether it was possible or not and if not what would not be recorded. (And having written that down, I expect I should be able to look the answer up in documents somewhere). And how does it resolve conflicts, for example where one programme is available on another channel or a later repeat whilst another programme is only available once. I confess I haven't had cause to investigate this aspect of the system yet.

It doesn't resolve conflicts. There is another PVR that does that, but it is very difficult to do, and quite difficult to retrofit in to tvh without impacting performance on slow devices since that PVR needs to make numerous passes finding the ideal tuner and timeslot to record the most programmes.

So, the user might want tuner2 to record programme A, but it can only use it if it's in timeslot X, but then that means programme B can't be recorded so it moves it to timeslot Y, but that then conflicts with programme C that is only on at that time, but if you recorded at timeslot A then you could also record programme D and programme E...You get the picture. Multiply that by a few hundred thousand epg events, a few thousand repeats, a hundred recording rules, and maybe three different sources (dvb-t, t2, s2) and you can see it can get slow to find the optimal recording slots.

In tvh, if you have a conflict then the one that is recording will continue recording, unless the conflicted recording is a higher priority in which case the earlier recording will be stopped. I can't remember if the stopped recording then gets rescheduled.

If it happens that recording A is only shown once, B is higher priority but repeated in the week, then B would still cancel A since you've said it is a higher priority.

In theory, we could do a simple look-ahead at the cancellation point and say "it's repeated, so don't cancel", but that could be confusing to people who set priorities, and might cause problems if the later repeat also had conflicts.

For many people, it's cheap nowadays to just add another tuner (like the xbox tuner), or re-record on one of the many repeat channels, so it's not as much an issue for many as it would be say ten year ago.

It doesn't resolve conflicts. There is another PVR that does that, but it is very difficult to do, and quite difficult to retrofit in to tvh without impacting performance on slow devices since that PVR needs to make numerous passes finding the ideal tuner and timeslot to record the most programmes.

The problem is that TVH allows you to schedule conflicting recordings and doesn't detect that at the time you add the recordings to the list of future recordings. The first you know about it is when one of them fails to record - in other words at the time of starting the conflicting recording. By then it's way too late for the user to be able to do something about it.

What is needed is a fairly simple test which rehearses the future recordings as if it was about to start the recordings for real, and as each recording is added to the list, it determines whether all the available tuners are already spoken for (allocating potential tuners in the order that recordings are added to the list of scheduled events). A simple message "can't add this timer event because there will not be a tuner available" is sufficient, without any clever rescheduling.

What the user does in response to this message is up to him. He may decide to cancel an existing recording to make way for the one that will fail. He may make his own search of the EPG and find that a recording is repeated later.

But the user does at least need to be informed at the time of scheduling the recordings. Detect the problem, even if you don't try to solve it.

For many people, it's cheap nowadays to just add another tuner (like the xbox tuner), or re-record on one of the many repeat channels, so it's not as much an issue for many as it would be say ten year ago.

I agree with this - I have a quad tuner and TVH precisely because there are situations on my set-top Humax dual tuner that neither it nor I can resolve plus backup for the occasions it stuffs up.

But I also agree with what Martin says about advising of conflicts at the time of scheduling, whilst the user is focussed. My Humax does at least tell me it can't record more than two things at once and offer to let me cancel (i.e. reschedule) one. Generally, at the time recording starts, I'm busy doing something else; that's one reason for making recordings.

It seems to me that this functionality is an ideal situation for a plugin. Perhaps the solution depends on which services you receive, or on your own preferences, but what doesn't change is the available information. Can TVH be persuaded to expose the EPG externally, including the programme IDs? Perhaps it already does, and I just never bothered to look. Then somebody (me perhaps) could take a look at producing an algorithm that improves on the current situation.

Everything is exposed via the web api or htsp. I've a few changes I haven't quite tested enough yet for allowing the user to show alternative schedules for a show. It will be mid-week before I deliver that, but that might be a useful base for you.

Dave H wrote:

I also agree with what Martin says about advising of conflicts at the time of scheduling, whilst the user is focussed. My Humax does at least tell me it can't record more than two things at once and offer to let me cancel (i.e. reschedule) one. Generally, at the time recording starts, I'm busy doing something else; that's one reason for making recordings.

It seems to me that this functionality is an ideal situation for a plugin.

I'd say that the best solution is this: at the time of scheduling a new recording, call the same code which allocates tuners at the instant of starting to record a real recording, but in "rehearsal mode" so as to identify which tuner will be allocated (according to tuner priorities that have already been set) to each recording that overlaps with the one being added. If there is will not be a free tuner, popup a warning. Still set the recording, in case the user wants to keep the one he's just added and delete or reschedule an existing one that is in conflict. It's important that any warning identifies the recordings that are in conflict with the one being added. Make sure that two recordings on the same multiplex are not regarded as being in conflict.

I used to use NextPVR on Windows, before I changed to using a Raspberry Pi to make recordings, and that detected conflicting recordings at the time of scheduling them. Windows Media Centre did too, but its allocation of recordings to tuners was rather naive because it would not let you have overlapping recordings even if they were on the same mux.

Tuners are relatively cheap, although each needs its own aerial feed (unless you get a multi-tuner module - and when I bought my DVB-T2 HD module, Amazon didn't have any of those on sale), so you end up with lots of two-way splitters or a multi-way amplifier with several outputs.

I've just had a thought. TVH could add an additional column in the Upcoming/Current Recordings list: the multiplex from which the recording will be made. This makes it easier to see at a glance whether overlapping recordings are from more multiplexes than you have tuners or whether they are from the same mux and therefore not a problem.

Em Smith wrote:

Everything is exposed via the web api or htsp. I've a few changes I haven't quite tested enough yet for allowing the user to show alternative schedules for a show. It will be mid-week before I deliver that, but that might be a useful base for you.

I'd be intrigued to see that, and how it can be done. I had a quick look to see if I could determine how the port 9981 web pages were generated, but couldn't work it out. One change that would be useful would be to assign a minimum column width for start and stop time which was large enough to hold the complete text in the field, which is a constant length - at least in a fixed-width font.

It is those fields which are the real problem, because there doesn't seem to be any way in a browser on Android of grabbing the field boundary and dragging sideways to alter the column width - the shortcomings of a touch rather than mouse user-interface!

I find that if I'm checking for overlaps as I'm making a new recording, I have to click on the "i" button to open each line in turn to see the start and stop times on the dialog box, which is slightly more cumbersome.

Please, replace phrase "port 9981 web site" with "Web UI"

What you must remember is that people like me run mixed system (dvb-t, t2, s2), so get some channels that have the same programmes on all three, some are only on two, some on one, and some channels are shown on multiple muxes on one service.

So, my s2 might have ten or more muxes showing a programme.

So, say it records on mux A, then it could mean channel X is also on that mux and could be recorded; but if it had started the recording on mux B instead, then channel X isn't on that mux so can't be recorded.

So, you need to avoid false positives/negatives.

Also, IIRC, we sort equal tuners at record time by the one that has historically had fewer problems. So, that could mean instead of recording on t, it records on my s2 tuner, which would then alter the muxes available for simultaneous recordings.

Sorry, I'd confused you with someone else (who was writing an epg alternative) when I mentioned that the data is all available, otherwise I would've included more info that I'd mentioned to them.

Anyway, there are some docs here:
https://github.com/dave-p/TVH-API-docs/wiki
The api is not really intended for 3rd-party use, but hopefully your changes would be part of the existing codebase.

My changes are in as a PR, so you can merge if you so desire, or wait until we get them merged.

In theory, at a minimum, the ui could calculate for itself a count of concurrent programmes; probably in the info dialog. I know some other PVRs do that.

On muxes: adding a muxes column I think would be confusing since I have numerous channels merged so the list would be long and potentially unreadable, especially when combined with the prefix of t,t2,s2.

Em Smith, since you seem to have delved into the source code, is there any reason why modifications to (for example) /usr/share/tvheadend/src/webui/static/app/dvr.js don't seem to have any effect on what appears when accessed via the web UI? Does the JS have to be compiled in some way, or should a modification to dvr.js (eg a trivial change to a pop-up "are you sure" message, as a test) take effect when the relevant circumstance is triggered after the file has been saved? I rebooted the computer in case it needed a restart of the main TVHeadend process, but to no avail.

What I'm really looking for is code which sets the minimum width for columns such as start time and stop time in the Upcoming / Current Recordings grid, but I was starting very simply to prove the concept, before embarking on trying to work out where the column widths are set.

Do you have a GitHub account? Best way to do modifications is to set up an account, fork the repository https://github.com/tvheadend/tvheadend and then do modifications there.

If not, or for initial playground, you can go to that repository and clone without needing a GitHub account (git clone https://....). There are some build instructions somewhere on the wiki for dependencies needed to do a local build (so you need dev libraries/headers to build).

There's a Makefile.webui in the repository which combines the .js files in to a .gz file, which is then served, but I just run "sudo make install" instead.

I think on Linux, if you run the tvheadend from within your own build tree, then the ui changes are then picked up automatically; otherwise a "make install". No need to restart tvh if you just make changes to the javascript files, but still need to make/install the gz file.

The widths are in the "width:" sections. Ideally it would be nice to be able to just double click and have all columns resize properly (as in Excel), but that's probably difficult to do.

I found the build instructions:
https://tvheadend.org/projects/tvheadend/wiki/Building

Em Smith, since you seem to have delved into the source code, is there any reason why modifications to (for example) /usr/share/tvheadend/src/webui/static/app/dvr.js don't seem to have any effect on what appears when accessed via the web UI? Does the JS have to be compiled in some way, or should a modification to dvr.js (eg a trivial change to a pop-up "are you sure" message, as a test) take effect when the relevant circumstance is triggered after the file has been saved? I rebooted the computer in case it needed a restart of the main TVHeadend process, but to no avail.

I would have guessed that your problem was that the browser cached the .js file so changing the file would appear to have no effect. But if you've rebooted the computer, that rules that out. Unless your browser is on a different machine to the TVH server?

In general, I for one do understand the complexity of the scheduling problem to some degree, Em. That's one reason I suggested a plugin solution so multiple possible not-quite-solutions could exist.

Apart from the complexities you mentioned about multiple sources, there's also another fundamental difficulty of course - the actual broadcast time can change from that scheduled, by a few seconds to many hours. And that is very likely to influence the particular tuner that is chosen.

Thanks for that pointer. I've examined the source for the various web page screen and they are all the same, but the crucial thing is the reference to tvh.js.gz. That's the working copy: it looks as if all the individual .js files are merged into one humungous tvh.js file (with no line breaks) which has then been gzipped.

I might create a GitHub account and have a play - investigate removing unnecessary columns from the grid and setting some minimum column widths.

I mentioned earlier about adding the channel name field in the popup information for a to-be recorded and already-recorded programme, to get around the fact that the Channel field in the grid is too narrow on a small screen device. Looking at dvr.js, it seems that Channel [name, not icon] isn't one of the values that is passed into the routine which displays that popup - and I suppose the list of fields is a function of the API that is called. Ah well, worth a try. And not necessary if I can widen the crucial columns - or find a way of widening them using a touch-screen interface on Android or iPhone.

I would have guessed that your problem was that the browser cached the .js file so changing the file would appear to have no effect. But if you've rebooted the computer, that rules that out. Unless your browser is on a different machine to the TVH server?

Good point. I rebooted the "web server" computer but I didn't clear the cache on the computer that was running the browser. But from what Em said, I think the real problem is that it doesn't use the individual .js files such as dvr.js (which is what I tried modifying), but instead "compiles" these into one big merged file which is then gzipped.

The caching is something like 10 seconds, or perhaps 30, otherwise the browser has to revalidate, but it is the gz compiled file that is served for performance reasons (bundle).

The channel name is displayed in the pop-up in the title bar.
You might (just) about be able to make it out in this dialog for a PR, in the top left dialog box title bar.

(Assuming 4.3 it's getDialogTitle).

Anyway, there are some docs here:
https://github.com/dave-p/TVH-API-docs/wiki
The api is not really intended for 3rd-party use, but hopefully your changes would be part of the existing codebase.

I was aware of that wiki but had never really looked at it. But I went to https://github.com/dave-p/TVH-API-docs/wiki/examples and now all is sweetness and light No excuses now; I need to get my thinking cap on.

Greetings:

This question seems to have gotten morphed into something regarding conflicts in scheduling...

I'm running version 4.2.4-dmo1~bpo9+1~rpt1 on a Raspberry Pi.

My question relates to the original question about columns in the WEB UI. I am constantly having to re-set the columns I want to show in the 'Upcoming / Current Recordings' and 'Finished Recordings' pages. I set them and the next time I go into the WebUI, they're all back to default again. Very frustrating. Am I doing something wrong in my config?

Any help?

Thanks!

No, you're not doing anything wrong. It's just that TVH doesn't remember anything from one invocation to the next. Although I'm running an old version and yours is even older, so who knows?