Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#1371 closed defect (worksforme)

Scheduled recording while on LiveTV looses Storage/PostProcessing properties

Reported by: mythtv@… Owned by: cpinkham
Priority: minor Milestone: unknown
Component: mythtv Version: 0.19
Severity: medium Keywords: livetv recording recgroup
Cc: Ticket locked: no



Watching LiveTV and the dialog pops up about a scheduled recording about to start in 30 seconds. Nothing is selected and myth correctly defaults to channel change/begin recording. The recording goes fine, but is not assigned to the proper Recording Group (stays as Default), and comm flag does not run when recording ends (as it should as per schedule properties).

Also, if you get out of LiveTV and go to Watch Recordings, while the recording is in progress, the UI doesn't highlight the show with the proper color indicating that is being recorded.

I'm _guessing_ that if the recording is supposed to be transcoded, this would not happen either.

Attachments (1)

mythbackend.log.bz2 (22.2 KB) - added by g8ecj@… 17 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 17 years ago by Kevin Atkinson <kevina@…>

I noticed this problem too. I should add that it also doesn't get the proper Recording Profile as it is assigned LiveTV. Which it how I noticed it.

comment:2 Changed 17 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham

comment:3 Changed 17 years ago by cpinkham

Resolution: fixed
Status: newclosed

(In [10565]) Modify the recorder so that it will run the proper jobs when a scheduled recording is recorded during a LiveTV session (ie, a pseudoLiveTVRecording).

This mod also honors the autoexpire and recording group of the scheduled recording instead of using the default values.

Closes #1371.

Changed 17 years ago by g8ecj@…

Attachment: mythbackend.log.bz2 added

comment:4 Changed 17 years ago by g8ecj@…

Resolution: fixed
Status: closedreopened

Still seeing the problem of not updating the Watch Recording screen when a scheduled recording interrupts a LiveTV session. Going in/out of the Watching Recording screen doesn't help.

Restarting the slave backend with the capture card aborts the recording - I'm sure that a scheduled recording should start up again if there was an interruption?

Single capture device running r10660

Log across the time of the scheduled recording starting attached as requested.

comment:5 Changed 17 years ago by cpinkham

Milestone: 0.20unknown
Resolution: worksforme
Status: reopenedclosed

Looks like you were watching LiveTV and Myth wanted to record "The Cook and The Chef".

I can see the record was inserted into the 'Default' recording group here:

2006-08-07 20:00:07.897 MSqlQuery: INSERT INTO recorded (chanid, starttime, endtime, title, subtitle, description, hostname, category, recgroup, autoexpire, recordid, seriesid, programid, stars, previouslyshown, originalairdate, findid, transcoder, playgroup, recpriority, basename, progstart, progend, profile, duplicate) VALUES ('2092', '2006-08-07T20:00:06', '2006-08-07T20:30:00', 'The Cook And The Chef', , 'Cook Maggie Beer & executive chef Simon Bryant buy seasonal produce & transform the fresh ingredients into dishes that everyone can cook, providing helpful tips on how food is best bought & prepared.', 'media', , 'Default', 1, 269, '221963302', ,0, 0, '2006-08-07', 0, 0, 'Default', 0, '2092_20060807200006.mpg', '2006-08-07T20:00:00', '2006-08-07T20:30:00', 'Default', 0)

Then, I can see the commercial flagging job fire off here:

2006-08-07 20:00:35.222 JobQueue?: Commercial Flagging Starting for The Cook And The Chef recorded from channel 2092 at Mon Aug 7 20:00:06 2006

Then, for some reason the backend tells the slave to delete the recording:

2006-08-07 20:01:02.595 read <- 9 619 DELETE_RECORDING[]:[]The Cook And The Chef[]:[][]:[]Cook Maggie Beer & executive chef Simon Bryant buy seasonal produce & transform the fresh ingredients into dishes that everyone can cook, providing helpful tips on how food is best bought & prepared.[]:[][]:[]2092[]:[]38[]:[]Food TV[]:[]Food[]:[]/mnt/store/2092_20060807200006.mpg[]:[]0[]:[]17096488[]:[]1154937600[]:[]1154939400[]:[]0[]:[]0[]:[]0[]:[]media[]:[]0[]:[]0[]:[]0[]:[]0[]:[]-3[]:[]269[]:[]0[]:[]15[]:[]6[]:[]1154937606[]:[]1154939400[]:[]0[]:[]44[]:[]Default[]:[]0[]:[][]:[]221963302[]:[][]:[]1154937646[]:[]0.000000[]:[]1154865600[]:[]1[]:[]Default[]:[]0

I can't tell why this happens without seeing the master backend logs, but that is why you don't see the recording show up like it should, because it's been deleted.

I see that it then looks like you went back into LiveTV about 30 seconds later, probably after looking on the Watch Recordings screen for the recording.

What keystrokes are you using to get out of the LiveTV session once the recording has started? It almost looks like you are going into LiveTV then exitting by using the DELete key which deletes the recording, then you don't see the recording because you deleted it. The recording doesn't restart when you restart the slave backend because it isn't in charge of the scheduler.

Closing ticket again. If you can provide both master and slave logs when this happens and you aren't deleting the recordings yourself then you can reopen the ticket.


comment:6 Changed 17 years ago by cpinkham

(In [10951]) Don't reset the recstartts when we start a pseudoLiveTVRecording.

Normally LiveTV recordings have their recstartts set to the exact time, to the second, that the recording starts. For pseudoLive recordings this is bad because it can cause the scheduler to lose track of the recording since the recstartts in the recorder (and starttime in the database) do not match the recstartts that is in the scheduler for that recording.

This fixes #2038. The Watch Recordings screen will now properly highlight these psuedoLive recordings as in-progress.

References #1371 because #1371 ticket mentions the same issue as #2038 among other things.

Note: See TracTickets for help on using tickets.