New Episode recording only (1 Viewer)

[mm1352000]

The plugin doesn't seem to be compatible with this current version of MediaPortal.

It absolutely is compatible.

Even if it was, MediaPortal doesn't make use of the first run attribute.

Yep, you're right. The best you can currently do is as per the second post:
https://forum.team-mediaportal.com/threads/new-episode-recording-only.121128/#post-1021952

It's more than a little frustrating. I'm surprised that in 2013 it's so difficult to find a pvr solution that can reliably skip recording reruns. I can't see how this wouldn't be a requirement for anyone setting up an HTPC.

All I can say is your requirements must be different to mine.

 

[Lehmden]

Hi.

I can't see how this wouldn't be a requirement for anyone setting up an HTPC.

It is NO requirement for me as it is for nobody who wants to keep the recorded series. At 1) Schedules are often don't work due to some actual program changes At 2) the late night reruns have a lot less advertisings and normally the start and end of the episode isn't cut that much. And the overlays while episode is running are non or at least very few. So for me the late night rerun is the main target to record. And at 3) if I missed some episodes earlier I'm happy to complete the series now.
It really is easy to delete a recording I don't want but it's impossible to get a recording that did not run at all...

 

[elliottmc]

The plugin doesn't seem to be compatible with this current version of MediaPortal. Even if it was, MediaPortal doesn't make use of the first run attribute. It's more than a little frustrating. I'm surprised that in 2013 it's so difficult to find a pvr solution that can reliably skip recording reruns. I can't see how this wouldn't be a requirement for anyone setting up an HTPC.

You do realise that MediaPortal is free of charge, and that it is written by a group of volunteers.

Perhaps it is difficult to find a pvr solution that can skip reruns because it is difficult to code a pvr solution that can skip reruns.

If you know better that the very talented team, you are welcome to submit a code patch.

 

[Pat Clark]

I have noticed an anomaly when using mc2xml that may be responsible for the problem, especially since mc2xml is used only in the US (I think) and the developers are in Europe. It seems the season and episode number are combined into the episode, so that season 1 episode 18 is present in the mc2xml file as season (missing) and episode 118.

Here is fragment of the file for one program:

<programme start="20131027230000 -0400" stop="20131028000000 -0400" channel="I4.28456508.microsoft.com">
<title lang="en">Criminal Minds</title>
<sub-title lang="en">Somebody's Watching</sub-title>
<desc lang="en">Dr. Reid falls for a Hollywood starlet at the center of a murder investigation.</desc>
<credits>
.
.
.
</credits>
<date>20060329</date>
<category lang="en">Drama</category>
<category lang="en">Episodic</category>
<category lang="en">Series</category>
<episode-num system="onscreen">118</episode-num>
<episode-num system="ms_progid">1.EP007537910018</episode-num>
<episode-num system="dd_progid">EP00753791.0018</episode-num>
<audio>
<stereo>stereo</stereo>
</audio>
<previously-shown start="20060329000000" />
<subtitles type="teletext" />
<rating system="VCHIP">
<value>TV-PG</value>
</rating>
</programme>

When such a program is recorded with a file name template that includes "S{season}E{episode}" (however it's specified), you get "SE118". Perhaps the software is silently rejecting these items for the purpose.

 

[elliottmc]

I have noticed an anomaly when using mc2xml that may be responsible for the problem, especially since mc2xml is used only in the US (I think) and the developers are in Europe. It seems the season and episode number are combined into the episode, so that season 1 episode 18 is present in the mc2xml file as season (missing) and episode 118.

And here is the problem. How does MP know that this genuinely isn't episode 118? If the season info is missing, we cannot simply guess, and we cannot code for every regional variation. Apart from anything else, that provider might switch to the correct information in 3 months time.

Honestly, this sort of thing is an absolute minefield.

It isn't because the developers are in Europe. We'd love more US developers. Just need them to step forward.

 

[Pat Clark]

It isn't because the developers are in Europe. We'd love more US developers. Just need them to step forward.

No insult was intended -- you're all unusually responsive and I thank you all. But, if this is indeed the problem, I can imagine the software interpreting it as season 0, episode 118, which would work fine. Maybe the programmer was too zealous in data checking.

By mentioning that you're in Europe, I only meant that you can't see the issue "live." Not to mention that you're not all in Europe!![DOUBLEPOST=1382652907][/DOUBLEPOST]I checked some other data, and found an episode encoded as "100112" !!
I wonder what the hell the provider thinks that's good for? It's sure not season 100, episode 112. I presume it's unique, however.
I also noticed in the Criminal Minds case, that thetvdb.com has that number (118) as the "production code".

 

[mm1352000]

It isn't because the developers are in Europe. We'd love more US developers. Just need them to step forward.

No insult was intended -- you're all unusually responsive and I thank you all. But, if this is indeed the problem, I can imagine the software interpreting it as season 0, episode 118, which would work fine. Maybe the programmer was too zealous in data checking.

Ummmm... just a bit confused here as we seem to be talking about two different things.
Some people are talking about a "new" or "first airing" flag; other people are talking about episode numbers.

Let me clear the record.

Categorically: we do not have a column in our TV Server database to hold a "new" flag. Therefore, unless you're using a plugin that maintains its own database, adds columns to our database, or uses some other means to only schedule only new-by-your-definition programmes it is not possible to only record new programmes.

FYI, here is the definition of the relevant table so you can see what we do store:
https://github.com/MediaPortal/Medi...TvEngine3/TVLibrary/TVDatabase/Program.cs#L37

It is not a big issue to add a new column to the table. In fact that is probably the easiest part of adding support for such a feature.

TV Server EPG data comes from a variety of different sources (in-band, XMLTV, WebEPG, SchedulesDirect etc.). Each source would have to add support separately because the original data content and format is different, and the way the data is imported into TV Server varies.

Let's take the XMLTV format as an example because it is so popular.
Here is the XMLTV spec:
http://xmltv.cvs.sourceforge.net/xmltv/xmltv/xmltv.dtd?view=markup

Is there a "new" flag?
Well, yes there is (line 490)... but on closer reading of the description you'll see that it doesn't mean "new" in the sense that is discussed here. It means the first episode of the first season of a brand new show.
Okay, is there an alternative?
Maybe "premiere" (line 453)? The problem with premiere is that it is ambiguous. As the description says: "different channels have different meanings for this word". It might be equivalent to what you want... or it might not... and that might vary from channel to channel or data source to data source.
What about "previously-shown" (line 449)?
Well, this is not really a new flag - it is really the inverse. If every programme that was not "new" were marked with this attribute then by definition it still doesn't mean that the unmarked shows are "new". As the description says: "the absence of this element does not say for certain that the programme is brand new".

My take on the above is that there is no universally correct and unambiguous way to encode the "new" attribute in an XMLTV file. Therefore, any implementation will be imperfect and subject to per-channel and per-source problems.

This is only one example of the problems one would encounter if attempting to implement support for this feature. I hope it helps to illustrate that it is not as easy as you might think.

@Pat Clark
In relation to your comments about episode number...
Here is the XMLTV plugin code that reads the episode number details:
https://github.com/MediaPortal/Medi...brary/Plugins/XmlTvImport/XMLTVImport.cs#L618

Succinctly, the points I want to make are:
1. Of the three episode number attributes in your example, the "onscreen" system is the only system that the TV Server XMLTV plugin supports. The other two episode numbers are ignored.
2. We support "onscreen" and "xmltv_ns" systems because these are the only two systems specified in the XMLTV specification (refer to the above link). We also try to parse episode numbers where the system is not specified, but this is obviously not standard.
3. Onscreen is the most ambiguous of the two supported systems (again, read the XMLTV spec). It is basically as good as no standard. We simply take the content of the episode-num tag and try to convert it into a number. If that doesn't work, the data is thrown away.
4. If onscreen or xmltv_ns episode number details are detected but thrown away, you'll see this logged in your TVService log file ("XMLTVImport::CorrectEpisodeNum, could not parse...").

The example above should import fine. From the code, I'd expect it to be interpreted as season 0 episode 118. If you've already recorded season 0 episode 118, the file still exists where TV Server thinks it should be, and you've configured TV Server to not record repeats... then I'd expect TV Server to not record that programme.

mm

 

[Pat Clark]

Ummmm... just a bit confused here as we seem to be talking about two different things.
Some people are talking about a "new" or "first airing" flag; other people are talking about episode numbers.

You're right. People have mentioned both. But I think they're after the same thing. They say they want "new" shows, but what they really want is "not old" shows.

Your explanation is thorough and appreciated. So, judging from that, it appears to me that it's a design "error" or "missing use case" or some such.

What I think people want, besides mind reading software, is this. "Don't re-record tomorrow, what I just watched tonight and deleted, or moved."

Most people I know use a PVR to time-shift and commercial detect. They watch a show ONLY after it has been recorded and comskip'ed. Then they delete it or save it somewhere else.

Many channels here in the US endlessly repeat shows in the same time frame (a week or a month), as well as repeat shows years later. Ideally, (at least as an option) MP would catch all of these situations and not re-record them. When you "remove" all the repeats, you can watch what you want, when you want, and still go out on Friday and Saturday nights!!

So even if we have "perfect" season and episode numbers, it will still be deficient for most people, since MP will re-record if the recording is missing.

I say most people, because who can afford the disk space to keep all previous recordings around indefinitely? I have 2.5 TB, and can't afford space for innumerable HD shows that I'll never watch again -- but if I delete them, then whoops, there they are again.

 

[elliottmc]

We've explained why this is very difficult because of the variations in the way the EPG data is provided. Sorting this would take a massive effort, and would almost certainly result in some situations where a new episode was not recorded due to bad data.

However, it is almost no effort to either cancel episodes of a schedule in advance or to allow them to record and then delete the duplicates. I do this all the time.

MP does have a setting to not re-record episodes. It will work as long as episode numbers are provided in the correct EPG fields. We are not responsible for the quality of EPG data provided. For example, where the BBC provides episode number information, it is usually in the text description and never includes the season number.

So, we know this is something that would be better if it could be fixed. But nagging us and telling us how important it is for _you_ won't make it happen.

 

[Pat Clark]

. . . would almost certainly result in some situations where a new episode was not recorded due to bad data.

Understood.

However, it is almost no effort to either cancel episodes of a schedule in advance or to allow them to record and then delete the duplicates. I do this all the time.

Agreed. I, too, do this all the time. To me, this is symptomatic of an underlying problem. From my point of view, the current series handling algorithm is effectively broken. At the very least, it could be improved. My wife often asks "Why are you always fiddling with it? What will I do if you're gone?"

But nagging us and telling us how important it is for _you_ won't make it happen.

There has been no intention to nag, but merely to explain, in case you have not experienced the problem. Apparently you have. Clearly, it is not a major problem, but it does exist.

As users, we are in no position to judge what you know, or to judge how difficult a revision might be. Some of the most complex-sounding problems are easily fixed, and some of the simple-sounding ones are nearly impossible. Only you guys can say.

It will work as long as episode numbers are provided in the correct EPG fields.

As explained by mm1352000, this not quite correct: the recordings must be kept "forever" for it to work.