Project

General

Profile

Bug #5351

Re-Recording issue: Weak stream

Added by Mark Nowiasz about 6 years ago. Updated almost 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
General
Target version:
-
Start date:
2018-11-26
Due date:
% Done:

0%

Estimated time:
Found in version:
4.2.7.
Affected Versions:

Description

Hi,

Occasionally I'm having some stream issues (DVB-C), which isn't the problem here. I've recorded one film with 60 data errors, tvheadend automatically rerecorded the movie, which was quite acceptable (only 4 data errors). So far so good, but TVHeadend insisted that the superior recording (the one with 4 instead of 60 errors) had a "Weak stream" and was considered a "Failed Recording". Thankfully the recording in question hasn't been automatically deleted :-/

But this is odd behaviour - I mean, why would TVHeadend prefer the worse recording to the good one?

History

#1

Updated by Joe User almost 6 years ago

I have seen this also.
From the source code:

static int
dvr_entry_rerecord(dvr_entry_t *de)
{
  uint32_t rerecord;
  epg_broadcast_t *e, *ev;
  dvr_entry_t *de2;
  char buf[512];
  int64_t fsize1, fsize2;
  time_t pre;
  uint32_t warm;
  htsmsg_t *conf;

  if (dvr_in_init || de->de_dont_rerecord)
    return 0;
  rerecord = dvr_entry_get_rerecord_errors(de);
  if (rerecord == 0)
    return 0;
  if ((de2 = de->de_parent) != NULL) {
    if (de->de_sched_state == DVR_COMPLETED &&
        de->de_errors == 0 &&
        de->de_data_errors < de->de_parent->de_data_errors) {
      fsize1 = dvr_get_filesize(de, DVR_FILESIZE_TOTAL);
      fsize2 = dvr_get_filesize(de2, DVR_FILESIZE_TOTAL);
      if (fsize1 / 5 < fsize2 / 6) {
        goto not_so_good;
      } else {
        dvr_entry_cancel_delete(de2, 1);
      }
    } else if (de->de_sched_state == DVR_COMPLETED) {
      if(dvr_get_filesize(de, 0) < 0) {
delete_me:
        dvr_entry_cancel_delete(de, 0);
        dvr_entry_rerecord(de2);
        return 1;
      }
not_so_good:
      de->de_retention = DVR_RET_ONREMOVE;
      de->de_removal = DVR_RET_REM_1DAY;
      dvr_entry_change_parent_child(de->de_parent, NULL, NULL, 1);
      dvr_entry_completed(de, SM_CODE_WEAK_STREAM);
      return 0;
    } else if (de->de_sched_state == DVR_MISSED_TIME) {
      goto delete_me;
    }

So it is not about errors, but file size. 
if (fsize1 / 5 < fsize2 / 6) {
        goto not_so_good;

where fsize1 is current and fsize2 is parent (old). So, basically the new file must be at least 20% larger than the previous recording.

Although I checked a few and this did not even seem correct because I had two recordings which were almost the same size. Could be an issue with calculating the file size???

#2

Updated by Jaroslav Kysela almost 6 years ago

It seems like that the second '} else if (de->de_sched_state == DVR_COMPLETED) {' condition is reached for a reason, so the file size check is not executed. Perhaps, de_errors are not zero ?

#3

Updated by Joe User almost 6 years ago

I was thinking that, but I just checked a few "weak stream" recordings that showed up today and none of them had any "errors" just 200-400 "Data errors" (signal issues).

Original recording: size 787MB, 0 "Errors" and 318 "Data errors" and the "weak stream" recording has a size of 787MB, 0 "Errors" and 338 "Data errors".
Original recording: size 788MB, 0 "Errors" and 253 "Data errors" and the "weak stream" recording has a size of 787MB, 0 "Errors" and 335 "Data errors".
Original recording: size 789MB, 0 "Errors" and 108 "Data errors" and the "weak stream" recording has a size of 786MB, 0 "Errors" and 411 "Data errors".

In the recording profile I have it set to re-record if more than 100 errors.

I would like to remove the line:

      de->de_removal = DVR_RET_REM_1DAY;

But due to issues I noted in other thread, I cannot upgrade to a current build. When I get that resolved, I will be able to add some more trace messages for debugging. But I will not have time for it in the near future.

Also available in: Atom PDF