Tvheadend

Woo-hoo, as the saying goes.

The problem survived the upgrade to 3.1.776 (I even peered through the diffs to see if it might affect it... vain hope...), but I suddenly realised something after following a different thread. All offending shows had subtitle information, which only appears in XMLTV - despite me having switched back to EIT.

So, I stopped tvheadend, deleted /home/hts/.hts/tvheadend/epgdb.v2 (the EPG database file), and re-started the daemon again...

... and, lo and behold, as the EPG repopulated so the rules kicked into life and scheduled the recordings. I now can record multiple instances of the same programme, it seems. That said, Channel 5 does seem to be broadcasting a different description for the +1 instance for some utterly bizarre reason, so I can't be certain that this issue won't be back; I do have successfully-scheduled programmes on Kix! (yes, more Power Rangers... kids... muttermuttermumble...) that have the same description as well, so that's a positive sign.

Adam Bark - does this give you any pause for thought? Could SeriesLink be activating whether you like it or not, particularly if you've got XMLTV data in the EPG DB?

No, series linking will only work if a series indicator is set. Rejection of duplicates will only occur if proper episode identifiers exist (which they can for XMLTV, but not in the UK).

If you already had data in the database that wasn't what you expected/wanted, then its true that flushing the DB (as you did) is the only way to rectify the situation. There is an inherent (currently unconfigurable) prioritisation of EPG grabbers and if info from higher prio already exists it will not be overwritten by a lower prio one.

Also if fields (such as sub-title) already exist as provided by a previous EPG provider they will not necessarily be cleared just because the new provider doesn't provide a value.

Adam

Hmmm... then I'm none the wiser. I can't think why tvh would resolutely refuse to schedule the second instance of a programme unless it was using series linking - I could schedule events before and after the offending repeat, just not the repeat itself.

Is series linking stored anywhere other than the autorec rules? Could it be that I set up the rules originally as "record the series" and this then remained in force no matter what I did with the rules after that? Seems strange that an EPG flush could resolve it otherwise, the rules are still the same and the rest of the config is unchanged.

(I'm not doing very well here... all of my [tvheadend] problems seem to be utterly personal...!)

Cheers,

Ian

Ian,

A series link identifier has to be recorded in the autorec rule (this is the only DVR related configuration) for it to do series linking, you can see if this exists by checking the UI (there is a tick box) or looking for serieslinkid in the config files.

Any broadcast that has a matching serieslink identifier will be recorded by that rule.

The episode duplicate rejection is based on the episode IDs of the existing recordings v broadcast value. If you try to record a broadcast with ID XYZ and a recording (even a failed one - this is a shortcoming that needs fixing) with the same episode id XYZ exists in the log (dvr/logs/* - you can't see the episode ID in the UI I'm afraid) it will refuse to record regardless (again this needs to be override-able, but isn't at the moment).

So if TVH is refusing to record stuff, check whether you have recordings which "might" be the same thing. If you like mail me your .hts directory and give me an example of an event you tried (and failed) to setup a recording for.

Adam

Thanks for the offer, Adam - I'll zip it up and pop it over later (I'm assuming your email address will be obvious to find). My earlier elation has been dashed, since I thought I'd do some more testing and so deleted the rules and scheduled recordings - and now I'm back to where I was, I can schedule one recording but not the other no matter how careful I am to avoid any kind of series linking.

So, unless I'm just doing something really stupid, or unless there's an option somewhere I haven't noticed, I've no idea what's happening. I suspect that the only reason it worked above is because the C5 variant was triggering on XMLTV data and the C5+1 on EIT data... now it's all trying to use EIT, I'm back to square one.

....

Interestingly, I've just tried ignoring autorec and simply scheduling the events by hand.

• If I select the C5 variant and then the C5+1 variant, I get one event - the first schedules, the second event won't.

• However, if I do it the other way around, something even stranger happens: first, the C5+1 variant schedules, but when I say "record program" to the C5 variant, the C5+1 one is simple removed from the schedule instead of the C5 one being inserted... :-?

I can confirm this with the log files... adding the C5+1 event creates a log file for that programme, and then adding the C5 one deletes it again...

debug log shows the first event:

Oct 23 19:15:10 revo tvheadend[8119]: dvr: "Power Rangers Super Samurai" on "Channel 5+1" starting at 2012-10-27 10:59:00, scheduled for recording by "xbmc"

... but absolutely nothing for the second...

(Only other thought... I wonder if C5+1 is a channel I've merged, and whether that could be screwing something up...?)

Please report this, in particular the second issue about +1 and then non +1. I think this has been mentioned somewhere else before and I do think its a genuine bug, but because it wasn't logged in the issue tracker I'd obviously forgotten about it.

Adam

Will do - do you want separate ones for "unable to record from normal and +1 using autorec" and one for "+1 then non +1 deletes the first event", just one for the latter, or just big one that says "wibblewibblesomething'snotworkingmyhead'sfullwibble"?

(and thanks for the work on tvheadend - I feel bad about giving you more to look at, so I'm grateful!)

EDIT

I'll raise one for both, although they may be separate issues - but they're suspiciously related. I just tested trying to record the same programme on C4 and C4+1 with the same results.

If you can create 2 issues, I agree with you that there is a high probability that the solution will be the same for both. But it's easier for me to deal with things if they are separate in case this does not hold to be true.

Adam