Duplicate recordings since 0.28

[Ajharvey]

Since upgrading to 0.28 I have been getting duplicate recordings. In particular we have a number of "+1" channels in New Zealand (same as the main channel, but delayed by one hour) which are useful for overlapping recordings, but I cam getting both the main showing and the +1 showing recorded. On 0.27 the first showing recorded, but the repeat did not.

In addition, as it's possibly related, one recording set to keep one only is not deleting the recording from the previous day.

Is anyone else having the same issue? Or what I might check? Has anything changed in way 0.28 matches recordings?

Thanks!

[dekarl]

My first thought it that there may have been changes in the guide data aquisition code that leads to the programmes not being indentified as duplicates anymore.
Can you verify that in the upcoming recordings / guide both programmes have identical data? E.g. programid, seriesid, title, subtitle, description. How about starttime and the channels callsign/number?

[Ajharvey]

Thanks for those ideas - when I looked into that data on the previously recorded screen (after finding no difference in he guide) I noticed that the recordings are "failing". I.e.:

MythTV Status
Recorder Failed

But the recording is complete and watchable all the way through. I guess I will need to dig into the logs somehow to figure out why it thinks it's failing?

[bill6502]

Could be poor quality in the recording that you won't even notice, e.g.:

Code: Select all

2016-04-26 01:40:00.853866 I [2478/2493] TVRecEvent tv_rec.cpp:848 (FinishedRecording) - TVRec[30]: FinishedRecording(2632_2016-04-26T06:10:00Z) damaged recq:<RecordingQuality overall_score="0.835" key="2632_2016-04-26T06:10:00Z" countinuity_error_count="45" packet_count="14000762">
    <Gap start="2016-04-26T06:12:08Z" end="2016-04-26T06:13:47Z" duration="99" />
</RecordingQuality>

That can cause the episode to be re-recorded if it's considered as damaged,
as above.

[Ajharvey]

Ok, I've been through the logs and it seems that it was hitting a tuning timeout whereby if it didn't get a signal lock in 3s it marks the recording as failed. I've upped the timeout to 5s and we'll see if that makes a difference on the next recording.

Thanks for all your help - I'll report back when I've got it tested.