Tvheadend

This is a problematic issue, specially when some TV shows can have 2 or 3 re-runs in the same day/weekend, essentially multiplying the need for disk space and manual administration (deleting) of extra episodes.

Auto-recording re-runs also means more tuners are busy than should be, which will also block other recordings.

Indeed, but it all depends on the support from your EPG provider.

Many of those that include things like original air date (such as the NA schedules direct script) provide reasonable episode identifiers which are used to block duplicates already (in 3.2).

In 3.4 I will also re-instate the description based dup detection, which while flawed as a generic/global technique can make sense on individual basis if/when requested by the user. This works for many XMLTV and OTA providers who do maintain consistent descriptions (but not all).

Adam

I am not sure I get this. Can you confirm this is fixed for NA schedules as described in the report, in 3.2?

Another way to deal with this in a more generic way would be to have the options to "Record this show only on this weekday+exact time / Record this show on any weekday+exact time" etc. - my cable-company-provided PVR uses this approach effectively.

Fabian,

If you are using the schedules direct data (or in fact anything that support dd_progid fields), this includes a unique episode ID for most (but not all) entries in the schedule. This is used internally by TVH to stop it recording duplicate shows (in fact it can be a bit too brute force at the moment and may stop you re-recording if something goes wrong, unless you first delete the broken recording - but that's another problem).

If this is not working, then please let me know as although I added the code at a users request and I believe he's been using it for a while I have no way to test it myself. But I do have an EPG source that provides a unique ID that ends up in the same TVH fields and I believe it works for me.

There is an FR #1087 that I created to do some general DVR updates, so any comments on there welcome. But I've not been able to find the time to look into it properly yet.

Adam

This is the only must-have feature that I think is currently missing from TVH. In comparison, WMC offers you the option of recording a show:

- New only
- New + reruns
- All showings (same as number 2, but doesn't retain history and will record the same reruns)

In the NA market, we have a lot of cable channels like Comedy Central that will have a single new South Park episode per week, but will easily run 30+(!!) reruns at off-hours. Clearing all those out on a regular basis just isn't feasible.

This has turned out to be a pretty big show-stopper for us.

Any suggestions on a quick hack for this functionality? I was thinking of running a separate instance of TVH solely for new recordings, and updating the XMLTV data enroute (via XPath, etc) to just allow new recordings in to that instance.

I don't suppose there's been any movement on this one? I record and archive a children's show, and it must record the same one 4 or 5 times a month (as soon as I delete a given episode, the next time the EPG grabber runs it gets added at the next airing).

If your epg source provides season/episode numbers, you could just use 'Episode Duplicate Detect' in the recording profile. Does it work for you?

Mario D wrote:

If your epg source provides season/episode numbers, you could just use 'Episode Duplicate Detect' in the recording profile. Does it work for you?

I think there might be some misunderstandings here. Duplicate detection, is not the same thing as rerun handling.

Duplicate detection (to my admittedly amateur understanding) depends on having recorded before.

However, there are lots of reasons why a user may want new airings only going forward, without having in their history every episode of every season previous.

I don't see the problem here - if there's an airdate/original air date field or just one, compare them or compare it to current time slot, mark the item as a rerun. This isn't just about duplicates, I'm not sure why this is being framed that way.

I think there might be some misunderstandings here. Duplicate detection, is not the same thing as rerun handling.

Duplicate detection (to my admittedly amateur understanding) depends on having recorded before.

However, there are lots of reasons why a user may want new airings only going forward, without having in their history every episode of every season previous.

I don't see the problem here - if there's an airdate/original air date field or just one, compare them or compare it to current time slot, mark the item as a rerun. This isn't just about duplicates, I'm not sure why this is being framed that way.

EDIT: And since there is </previously-shown> tag in official XMLTV format, simply using that would be a great standard way of supporting this functionality.

Duplicate detection should catch these reruns in advance and mark the as "reruns" in the upcoming recordings view. When create a dvr autorec, just choose the right "Duplicated Handling".

See https://github.com/tvheadend/tvheadend/pull/604#issuecomment-77873421

I think this can be closed now, any objections?

I think it should remain open since although we have fixed most of the things, I agree with Blue Note that people in the bug have confused duplicates and repeats.

I think some of what is requested is implemented, for example you can select "new" on broadcast type, but frequently "new" is not set since xmltv's definition of "new" is not the same as most people's idea of "new". And I think this is the underlying problem for Blue Note.

We parse previously-shown, but I don't think this necessarily works for detecting new episodes. For example my SD has "new" set on an episode of Castle next week, despite originalAirDate being 2015; the reason being that it's new for that channel even though it was probably shown on a premium channel earlier, and the originalAirDate probably refers to USA anyway. So, if we marked it as definite repeat when parsing the xml file then that would be incorrect.

However, if previously-shown is today then an episode could be marked as "new". It depends on what people think "new" means. We have the same episode shown at, say, 10am and 6pm and the tv channel proclaims them both as "channel premiere", when that's clearly not true.

Also, I recall that they have problems in the US due to timezones and a new programme being previously-shown the day before on the other coast.

The mythtv solution seems to me to decide that definitely "new" is a date-range around the previously-shown, so an episode is new for 14 days, relying on duplicate recording detection to avoid recording the repeats.
[[https://tvheadend.org/boards/12/topics/27917]]
But, that solution wouldn't work correctly either for the Castle example above. But would probably work for many people even if they live on the opposite coast.

It's a shame that SD has information that is accurate and useful and we then discard it for xmltv. I'd been thinking for a while that we could just have an epg api that allowed us to push epg to the server, the same as we get epg from the server; that way we could avoid xmltv conversion completely and could, in theory, take advantage of the SD "live game schedule updates" which I believe they have in the US. But, a bespoke solution could quickly become unsupported. So, I'd be tempted to just add a non-standard field to the xmltv generator to pass through proper "new" field.

I had also been thinking vaguely that perhaps a "record seasons >= X" might be useful. So every year you just bump the season number, but that seems a bit of a hassle.

I think this can now be closed.

We now support "new only", "new or unknown", "repeat", or "any" as the broadcast types. The GUI has a tickbox for easy filtering of "new only".

This is based on the existing xmltv "new" or "premiere" tags since previously-shown date cannot be used since non-premium channels often have "new" episodes that had previously been shown on a premium channel or another country a few weeks or years earlier. For example, "The Simpsons" is marked as new for my channel but had a first air date of 2014.

This is in addition to, and separate from, the duplicate checking that already existed for "record all", "unique episode", "different description", etc., and the dvr-log retention for determining when to re-record duplicates.

IMO, recording "new only" is probably a bit error-prone for episodes since if you want to record S10E2 and it fails to record then you probably want the non-new repeat showing of S10E2 to be recorded, but perhaps Comedy Central (in the poster's example) doesn't repeat new episodes in the same week. Similarly for movies, my tv guide tells me that Roger Moore Bond movies are"new" since they've not been shown before on that particular channel. But I can imagine a bit of filtering like "record all new movies shown around 9pm at the weekend on channel Y" could be useful.