[northern_star]

Hi all,

Hope you can help..........I am in the process of choosing a back-end PVR. Do any of the PVRs offer a TV wishlist function, where the PVR monitors a list of wanted TV programs and films and if they appear in the EPG, the PVR automatically records them for you.

I know Mediaportal TV server has a plugin that does this, just wondered if any of the other PVRs do or if there is another way to do this.....

thanks guys

[oldtvwatcher]

Tvheadend has an Autorecs tab, where you can create rules for programs to be recorded any of several criteria. If a scheduled show matches one or more of the Autorec rules it will be recorded. I think this would work well for you. The only thing that the autorecs will not do, unless there is a way to do it that I haven't discovered, is not record a rerun (a show that it has previously recorded at an earlier date). But if you know a show is going to be a rerun you can always delete the individual timer for that show from the Upcoming/Current Recordings tab, which will not delete the Autorec rule, just that one scheduled recording.

[rpcameron]

Tvheadend's autorecs can record based upon the guide setting the "new" element. I use this for skipping duplicates, but its use is dependent upon your guide provider properly setting this flag. (There are some issues with this flag not being properly set when using the xmltv-utils tv_grab_zz_sdjson and tv_grab_zz_sdjson_sqlite grabbers which required modifying the Perl scripts to properly set this flag, but I have patches available if you're interested.) Also, depending upon how you have duplicate handling setup in Tvheadend, it can skip a re-recording if it has already recorded the program.

Also, Tvheadend autorecs are general search string based, so I can create one autorec with "^NCIS" as the text, and the broadcast type set to "New", and it will record all new episodes of NCIS, NCIS:LA and NCIS:NO, but not the repeats. Set them "Channel" flag to any, and it can do so across any channel.

[oldtvwatcher]

Tvheadend's autorecs can record based upon the guide setting the "new" element.

I am looking at the "Add Autorec" screen in Tvheadend 4.2 and I do not see anything very obvious about selecting a "new" program. Under Duplicate Handling there are several rather confusing options that are not at all explained in the Help, and then there is a "Broadcast Type" that lets you select "New / premiere / unknown" as an option, which is what I would assume you're using?

What I don't understand is how Tvheadend determines that a program is new. I use tv_grab_file as the grabber to bring the xml listings into Tvheadend, and those listings do contain tags <new /> and <premiere>PREMIERE</premiere> (not sure why the different format) but I don't know if those are the way Tvheadend expects to see those when importing the data. I suspect that different listing sources have different ways of handling the "new" tag. Another issue is that in the EPG listings Tvheadend doesn't indicate which programs are "new".

I'd be interested in either seeing your modifications to the perl scripts, or just knowing what Tvheadend expects to see in the xml file for a "new" program.

[rpcameron]

The <new> and <premiere> elements of the <programme> element are indeed what the "Broadcast type" drop down is referring to. If the imported XMLTV file as either of these set, then it would match the Autorec rule. Conversely, if the "Broadcast type" is set to "Repeated", then the rule will only match for entries that have the <previously-shown> element present in the <programme>.

The problem is that with tv_grab_zz_sdjson, the XMLTV that is generated will always have a <previously-shown> element if the ProgramID from Schedules Direct has an originalAirDate present. MythTV would count this as a new showing if the originalAirDate was the same as the date the programme was for, Tvheadend does not. My patch for tv_grab_zz_sdjson suppresses the <previously-shown> element if it is generating a <new> element so Tvheadend will treat the programme as new.

With tv_grab_zz_sdjson_sqlite, the situation is slightly different. The code that generates the <previously-shown> and <new> elements is coupled together. However, the way it was written is that if the ProgramID from Schedules Direct had an originalAirDate, it would never generate a <new> element; <new> elements would only be generated when the ProgramID had no originalAirDate. To change that situation, I re-ordered the tests for new/originalAirDate as with the non-sqlite grabber so <previously-shown> elements are again suppressed when there is a <new> program.

The problem with all of this is that the XMLTV DTD is not specific about what exactly is meant by "previously shown", and the authors of the grabbers have done their best to fit it into the model that they feel works best, and is usually tailored to their use-case. Similarly, the "premiere" settings are also not specific. (First time airing ever? First time on this particular channel? Pilot/first episode of the entire program, or just for a specific season/series? Who knows? And the DTD isn't specific.)

Another problem with this is matching Schedules Direct's (or rather, Gracenote's, the upstream provider) data into these ambiguous elements. So, it's not surprising that tweaks are needed.

If you're interested in my patches, they're available on the Tvheadend forums: https://tvheadend.org/boards/12/topics/27917

[oldtvwatcher]

Thanks for the clarification. I assume that the <new /> tag (with the space and slash) is recognized by Tvheadend but I guess I will need to test that. I just wish there was some way to view the EPG in Tvheadend and make sure that the flags are set the way they should be for upcoming programs. The problem you were having with tv_grab_zz_sdjson at first glance doesn't seem to be an issue when tv_grab_file is used (or I probably should say, when zap2xml is used), although I have not gone through the xml file with a fine-toothed comb to see if such a thing occurs. It seems odd to me that you would have a <previously-shown> element alongside a <new> one; those two would seem mutually exclusive, and maybe it would be worth filing a bug report or feature request to ask that the <new> tag take precedence over any <previously-shown> tag, if only because if Tvheadend records something you didn't really want you can always delete it, but if it fails to record something you did want and there are no future airings then you are unhappy. So I think you could make a case for doing it the way MythTV does it, but I haven't personally experienced that issue due to not using the same grabber or listings source.

I would HOPE that the "new" tag means it's the first time an episode has ever been shown, at least on that network or channel. But I understand what you are saying about the ambiguity of "previously shown" - take for example when a PBS affiliate picks up a season of a program from the BBC. To PBS viewers, when the episode is first aired it's a new episode, yet it may have been previously aired some months ago in the UK. So it could both be considered "previously aired" (in the UK) and "new" (on the PBS channel), but typically you'd want the "new" to take precedence, since you probably didn't have the opportunity to watch the show when it aired in the UK.

[rpcameron]

Yes, the "new" element is an empty element, and should always be "<new />" in the xmltv; I just omitted it for brevity. The "premiere" and "last-chance" elements can either be empty ("<premiere />"), or include a description ('<premiere lang="en">First time on TV</Premiere>').

If you're curious, here's the relevant text from the DTD on those elements: http://xmltv.cvs.sourceforge.net/viewvc/.../xmltv.dtd

<!-- When and where the programme was last shown, if known. Normally
in TV listings 'repeat' means 'previously shown on this channel', but
if you don't know what channel the old screening was on (but do know
that it happened) then you can omit the 'channel' attribute.
Similarly you can omit the 'start' attribute if you don't know when
the previous transmission was (though you can of course give just the
year, etc.).

The absence of this element does not say for certain that the
programme is brand new and has never been screened anywhere before.
-->
<!ELEMENT previously-shown EMPTY>
<!ATTLIST previously-shown start CDATA #IMPLIED
channel CDATA #IMPLIED >

<!-- 'Premiere'. Different channels have different meanings for this
word - sometimes it means a film has never before been seen on TV in
that country, but other channels use it to mean 'the first showing of
this film on our channel in the current run'. It might have been
shown before, but now they have paid for another set of showings,
which makes the first in that set count as a premiere!

So this element doesn't have a clear meaning, just use it to represent
where 'premiere' would appear in a printed TV listing. You can use
the content of the element to explain exactly what is meant, for
example:

<premiere lang="en">
First showing on national terrestrial TV
</premiere>

The textual content is a 'paragraph' as for <desc>. If you don't want
to give an explanation, just write empty content:

<premiere />
-->
<!ELEMENT premiere (#PCDATA)>
<!ATTLIST premiere lang CDATA #IMPLIED>

<!-- Last-chance. In a way this is the opposite of premiere. Some
channels buy the rights to show a movie a certain number of times, and
the first may be flagged 'premiere', the last as 'last showing'.

For symmetry with premiere, you may use the element content to give a
'paragraph' describing exactly what is meant - it's unlikely to be the
last showing ever! Otherwise, explicitly put empty content:

<last-chance />
-->
<!ELEMENT last-chance (#PCDATA)>
<!ATTLIST last-chance lang CDATA #IMPLIED>

<!-- New. This is the first screened programme from a new show that
has never been shown on television before - if not worldwide then at
least never before in this country. After the first episode or
programme has been shown, subsequent ones are no longer 'new'.
Similarly the second series of an established programme is not 'new'.

Note that this does not mean 'new season' or 'new episode' of an
existing show. You can express part of that using the episode-num
stuff.
-->
<!ELEMENT new EMPTY>

The DTD seems to indicate that "new" is for just the series/programme premiere or pilot, but Schedules Direct uses the { "new": true } of a ScheduleID to indicate a first showing of a particular episode. The mapping isn't perfect, but that's how it works. The XMLTV DTD and Tvheadend are both quite EU and/or DVB focused, which makes some things not map 1:1 when used in a North American context. Also, the Tvheadend EPG format is slightly different internally, and parts of it (such as Series Links) are not mapped to XMLTV elements. Some EPG features, such as running state, or rescheduling a upcoming recording when guide info changes, don't seem to apply to XMLTV guide sources.

[oldtvwatcher]

Thanks, very interesting. The use of the "new" tag to indicate a new episode (rather than a new show) seems to be the standard usage for Zap2it, TitanTV, and TVGuide (and possibly other TV listings services) in the USA and Canada (and maybe elsewhere?), so whatever the intended usage was, that's not how it's being used. Which is a good thing IMHO, because what that DTD document is calling "new" is what I would call a "Premiere". It looks like whoever created that DTD clearly didn't understand how most people would interpret those words, and thankfully in this case common sense seems to have won out over what was written. It would not be very useful to have two indicators to tell us when a new show is starting, but none to tell when a new episode of a series is being aired, since most people probably want to record the series while skipping any reruns or re-airings.

Normally I'm all for following standards but in this case, since they didn't see fit to define a specific "new episode" element, they should not be surprised when people use the "new" element for that purpose. Maybe someday the DTD will be updated to reflect actual usage, or maybe they'll decide to revise it to include a specific "new episode" tag and hope people stop using "new" for that purpose (fat chance), but I'm happy that "new" isn't being used as defined in this particular case.

[rpcameron]

Well, it's hit or miss, actually. If it wasn't, I wouldn't have had to modify the grabbers for Tvheadend to properly support them.

A small (and definitely not ready for public consumption) patch I'm working on is native Schedules Direct and HDHomeRun grabbers for Tvheadend that integrate properly and fully with its internal EPG structure. Unfortunately, this may require some outside configuration still because the grabber webUI doesn't really offer enough options for something as complicated as Schedules Direct's JSON API. (And this is also secondary to another patch set for proper CableCARD/HDHomeRun Prime support beyond my quick hacked-together one I'm using now.)

[nickr]

Mythtv certainly does what you want.

[oldtvwatcher]

Mythtv certainly does what you want.

The problem I found with MythTV is that the frontend and backend versions had to be the same, or they would not work together. So if you had one backend and several frontends and you upgraded one, you had to upgrade them all, which definitely wasn't convenient. Of course that didn't matter if you were using the Kodi PVR addon for Myth, which didn't seem to care what the backend version was, but when I last tried it the picture quality was noticeably worse (not nearly as sharp) when using Kodi and the PVR addon as opposed to the native MythTV frontend client. I have no idea if that's still the case, because the other problem I had was I could never get Myth to use my DVB-S tuner card, whereas Tvheaded had no problem with it. This was just my experience.

OTOH, I will say that for the short time I used it (with a HDHomeRun device), Myth was better at detecting and not recording shows it had already recorded at an earlier date or time. But where it fell down was if you had two back-to-back programs scheduled on the same channel, when it came time to record the second it would not utilize the stream from the first program, and would use the second tuner or if that was in use, report no tuner available (at least until the first recording finished), whereas Tvheaend has no problem using one or more streams from the same mux for simultaneous recordings (so with Tvheadend you could record the shows from a main channel and all its sub-channels on the same mux, and it would still only use one tuner, wheres Myth would want a new tuner for every recording).

Again, I haven't touched Myth in over a couple of years so maybe some of this has been addressed, I just have noticed that a lot more people seem to be using Tvheadend than Myth, so haven't felt any real need to try Myth again.

[nickr]

In terms of picture quality, mythtv is certainly optimised for playback of Live TV streams, which means concentrating on stuff like deinterlacing.

It's scheduling is a long step above anything else I have seen.

I find I have enough tuners so that the back to back problem you describe doesn't affect me. Not forgetting each tuner will record everything from a complete mux (So with 4 muxes here locally, and four tuners, I could record everything on all channels if I wanted to). Perhaps you didn't set up enough "virtual" tuners per real tuner?

[rpcameron]

MythTV is certainly more robust with recording rules/scheduling than Tvheadend, but I find Tvheadend's priority system of adapters, muxes and services, and the one:many mapping of channels to services to be a bit more robust than MythTV. MythTV does also do better with skipping already recorded items ...

I reference to this thread, I believe I remember that MythTV also allowed setting rules on cast, so if you were looking for a movie with a particular actor, this could easily be achieved. (Much like on a TiVo.) Tvheadend could theoretically achieve this win its full text search and regular expressions, but I've never gotten that feature to properly work ...

[oldtvwatcher]

In terms of picture quality, mythtv is certainly optimised for playback of Live TV streams, which means concentrating on stuff like deinterlacing.

I never watch live TV (except for breaking news) but I just recall that the MythTV frontend always had noticeably better video quality compared to Kodi and the MythTV addon. I also noticed that it did a proper lob of displaying subtitles, which Kodi didn't do at all at the time, and only does rather poorly now on recorded TV (which puzzles me because it does it right if playing from a DVD, etc. Why Kodi can't deal with things like italicized text, specific text area placement, or musical note characters in a recorded TV stream is a mystery to me).

It's scheduling is a long step above anything else I have seen.

I find I have enough tuners so that the back to back problem you describe doesn't affect me. Not forgetting each tuner will record everything from a complete mux (So with 4 muxes here locally, and four tuners, I could record everything on all channels if I wanted to). Perhaps you didn't set up enough "virtual" tuners per real tuner?

That could well be, because I don't recall seeing anything about "virtual" tuners in the settings, then again I think I was back on something like version 0.25. Maybe this is something they have fixed. As I said, the things that most caused me to leave Myth behind were the fact that no matter what I did it would not play or record from my DVB-S tuners (it could see that they were there, it just refused to use them) and that stupid thing about the frontend and backend version numbers having to be in sync. I only upgrade systems when I feel like I have to, and never more than one on the same day. Plus if I recall correctly, Myth is like most Linux software in that if you are doing a new install you get whatever version is offered in the repo, and can't easily get a specific version. That more than anything caused me to move to Tvheadend even for use with my HDHomeRun device, because I just hated that you couldn't update the backend (with a more recent version of the Ubuntu Server distro, for example, which would then require getting the latest Myth version from the repo) without breaking all your frontends.

But I definitely wish Tvheadend had scheduling capabilities more like those that Myth offers.

[rpcameron]

Kodi's issue with regard to subtitles on broadcast TV is mostly unrelated to subtitle display for other video formats.

In North America, "subtitles" are really Closed Captions (EIA-608/CC or CEA-708/DTVCC), and these are embedded in the vertical blanking interval (VBI) of the video stream itself, not a separate stream such as SSA/ASS or SRT text files (such as in a MKV file) or DVB subtitles (dvb_sub) or DVD subtitles (SUB/IDX), which are really just bitmaps.

Closed Captioning is actually quite difficult to properly parse and present, and Kodi has a long way to go to do this right. IIRC, Kodi is relying on libzvbi support in ffmpeg to handle this, but ffmpeg barely handles this properly. Kodi's subtitling also poorly handles formatting in subtitles across the board (except for bitmapped subtitles), and this is an area where work is definitely needed.

In my personal experience, PVR only became usable with 16, and improvements were made in 17 that made it sufficient and workable. But, Kodi still has a long way to go before I feel that it can be considered a full and proper PVR frontend.