schedule re-records shows it shouldn't

[xris]

I've seen this happen with several shows over the last few weeks. This recording was recorded several times, and still exists in the "deleted" recgroup. Nothing changes if I "delete forever". The --printsched output (minus unnecessary other shows) is:

Title - Subtitle                Ch Station Day Start  End   S C I  T N   Pri
Good Eats - "Wake Up Little Su  675 FOODHD  26 10:59-11:31  1 1 7  C 1   3/0
Good Eats - "Wake Up Little Su  675 FOODHD  26 14:59-15:31  1 0 0  C E   3/0

There are 3 entries for this show in oldrecorded, too:

*************************** 1. row ***************************
     chanid: 1675
  starttime: 2008-03-25 21:00:00
    endtime: 2008-03-25 21:30:00
      title: Good Eats
   subtitle: Wake Up Little Sushi
description: Sushi.
   category: Cooking
   seriesid: EP00273928
  programid: EP002739280150
     findid: 0
   recordid: 1062
    station: FOODHD
    rectype: 3
  duplicate: 0
  recstatus: 2
 reactivate: 0
    generic: 0
*************************** 2. row ***************************
     chanid: 1675
  starttime: 2008-03-25 17:00:00
    endtime: 2008-03-25 17:30:00
      title: Good Eats
   subtitle: Wake Up Little Sushi
description: Sushi.
   category: Cooking
   seriesid: EP00273928
  programid: EP002739280150
     findid: 0
   recordid: 1062
    station: FOODHD
    rectype: 3
  duplicate: 0
  recstatus: -3
 reactivate: 0
    generic: 0
*************************** 3. row ***************************
     chanid: 1675
  starttime: 2008-03-26 07:00:00
    endtime: 2008-03-26 07:30:00
      title: Good Eats
   subtitle: Wake Up Little Sushi
description: Sushi.
   category: Cooking
   seriesid: EP00273928
  programid: EP002739280150
     findid: 0
   recordid: 1062
    station: FOODHD
    rectype: 3
  duplicate: 0
  recstatus: 2
 reactivate: 0
    generic: 0

[gigem]

The program is scheduled to re-record as it should be since none of the oldrecorded rows have duplicate <> 0.

The recstatus: 2 in rows 1 and 3 means the program was not recorded because it was considered previously recorded at that time. These rows should normally have duplicate = 0 and they do.

The recstatus: -3 in row 2 means the program was recorded at that time. Normally, this row would have duplicate = 1, but in this case, it has duplicate = 0. The only way this should happen is if someone chose the delete and allow re-record option when the program was initially deleted.

[xris]

This may be a bug in mythweb.. I need to see if mythweb is even bothering to set duplicate=1 on recordings it deletes.

[xris]

Yup, definitely a mythweb bug... "no" still sets a POSTforget_old? to a true value, which is all the php checks for.

[xris]

(In [16806]) re #5048, update things so that forget_old works properly when deleting recordings... no more 'no' triggering value-exists conditionals.

[xris]

(In [16807]) close #5048, update things so that forget_old works properly when deleting recordings... no more 'no' triggering value-exists conditionals.