Opened 12 years ago

Closed 10 years ago

#5094 closed defect (fixed)

Recording the same program twice causes MythTV to consider the second not active

Reported by: dknowles@… Owned by: danielk
Priority: trivial Milestone: unknown
Component: MythTV - General Version: head
Severity: low Keywords: duplicate programme program recording
Cc: Ticket locked: no

Description

To Reproduce:

(Prerequisite Multiple tuner cards)

  • Go to Live TV
  • Choose channel
  • Record programme (keystroke R)
  • Exit Live TV
  • Go to Live TV
  • Choose same channel as previously.
  • Record programme
  • Exit Live TV
  • Go to Recorded Programs

Both programmes are recording but only one is red (currently active) the other programme is white (finished recording). Entering the white programme and showing information shows that the programme is growing (i.e. still recording). Also the status screen indicates that both tuners are in use.

It is possible to stop the red recording using Stop Recording, it is not possible to do this for the white recording. In fact the only way to stop it recording is to reboot the MythTV computer.

Change History (12)

comment:1 Changed 11 years ago by danielk

Milestone: unknown0.22
Owner: changed from Isaac Richards to danielk
Status: newaccepted

This has been bugging me too... I'll look at this after stuartm checks in the MythUI changes to the watch recording screen.

comment:2 Changed 11 years ago by danielk

Resolution: duplicate
Status: acceptedclosed

dup of #4995

comment:3 Changed 11 years ago by stuartm

Ok the problem isn't a UI issue in watch recordings, so it won't be fixed by the MythUI port.

MainServer::HandleQueryRecordings?() iterates through the list from Scheduler::getAllPending() comparing each recording with and "endtime > now()", if it finds a match that recording has it's status changed to "recording"

In Scheduler::AddRecording?() we check for duplicates, but that check is broken, the following warning in the backend logs confirms it - "Scheduler: Not adding recording, '<program_title>' is already in reclist."

ProgramInfo::IsSameProgramTimeslot?(), the help text claims that it checks inputid, but it doesn't and checking input should fix this but may break other areas of the scheduler so this needs to be checked.

Assiging to danielk as per discussion in IRC.

comment:4 Changed 11 years ago by stuartm

Resolution: duplicate
Status: closednew

comment:5 in reply to:  3 Changed 11 years ago by gigem

The scheduler makes a fundamental, design, assumption that a program (as identified by title, progstartime and callsign) can only record on one input at any given time. Unless and until that assumption is removed and the scheduler design changed accordingly, the proper fix for this bug, IMO, is to not allow 'r' to be used to record the second live TV program.

comment:6 Changed 11 years ago by stuartm

Another fix might be to not compare against the scheduler list to start with, but just lookup the recording in the inuseprograms table. This might even be faster than fetching the scheduler list.

comment:7 Changed 11 years ago by stuartm

Let me clarify, I'm not saying that we shouldn't prevent the same program being recorded twice but in looking at this I'm wondering if we shouldn't be using inuseprograms anyway.

comment:8 in reply to:  7 Changed 11 years ago by gigem

Replying to stuartm:

Let me clarify, I'm not saying that we shouldn't prevent the same program being recorded twice but in looking at this I'm wondering if we shouldn't be using inuseprograms anyway.

That's what I figured you meant. I suggest using oldrecorded, though, since that's where the scheduler saves its status.

comment:9 Changed 11 years ago by danielk

Status: newaccepted
Version: 0.21-fixeshead

comment:10 Changed 11 years ago by danielk

Milestone: 0.22unknown
Priority: minortrivial
Severity: mediumlow

comment:11 Changed 10 years ago by stuartm

Component: mythtvMythTV - General

comment:12 Changed 10 years ago by danielk

Resolution: fixed
Status: acceptedclosed

At some point this appears to have been fixed in trunk.

Note: See TracTickets for help on using tickets.