To the application "42174113:25721910:0" and "0:25721910:0" are entirely different unique ids. It doesn't know anything about some epg sources constructing their unique id from multi bits of info, where only one part is enough to be a match.
I am aware of one issue with the application's duplicate checking logic. When it looks for new shows to schedule, it takes in to account whether there is already another 'ready' or 'pending' recording with the same unique id...BUT, it only looks for those pending/ready recordings that are related to the current recurring recording. It does catch it if you have multiple recurring recordings for a particular show (like handling airings on different channels etc).
As a work around I have asked my son to write me a script to remove the "SeriesID" part of the data from the XML file created by EPG Collector.
Duplicate Recordings now being avoided!!
I am using EPG Collector to download the UK Freeview DVB-T EPG data into an XML file instead of using the standard DVB EPG setting in NextPVR. The main advantage is that EPG Collector is able to collect the “Episode Number” data used by UK Freeview PVRs to do “Series” recordings and to avoid duplicate recordings. I dont think NZ use exactly the same “Episode Number” data format. Sub added support for XML EPG files generated by EPG Collector in v2.5.5.
Below is typical episode number data with the first part being the “Series ID” and the second part being the “Unique Programme ID”:-
<episode-num system="xmltv_ns">/L3DR8K . /AX9JCG . 0</episode-num>
This appears in the EPG_Event database under “unique_id” in the form:-
NextPVR does not support the use of “SeriesID” and regards the whole number above as the “UniqueID” given to each programme so avoiding duplicate recordings does not work. I asked my son to write a script for me that would remove the SeriesID from every “episode-num” entry in the xml file and leave it in the format:-
<episode-num system="xmltv_ns">0 . /AX9JCG . 0</episode-num>
Which becomes this in the database:-
I tried removing the leading and trailing zeros but the data will not load into the NextPVR database without them.
I then had to edit all the entries in the Recently_Deleted database to replace every “SeriesID” with a “0” then did the same with all the recent existing recordings which have been given an ID in the Scheduled_Recordings database.
Now after an EPG update using the modified XML file NPVR.log has numerous entries indicating that duplicate recordings were being avoided. It seems to have handled a particular weekly event where a programme called “Click” is broadcast 8 times over a weekend but this weekend is only recorded twice, the second being a shorter version with different ID. This must mean that as well as checking “Deleted Recordings” and “Existing Recordings” for duplicates it is also checks “Scheduled Recordings”.