Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#11119 closed Patch - Bug Fix (fixed)

Viewing Live TV Causes Recordings to be Moved to Live TV Group

Reported by: scott.harris0509@… Owned by: JYA
Priority: minor Milestone: 0.27.1
Component: MythTV - General Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

If a user begins viewing Live TV and changes the channel to the same channel as an in process recording(or the Live TV session starts on the channel), the recording group of the in process recording is changed from what ever it should be to "Live TV".

Attachments (3)

patch.txt (679 bytes) - added by jbreitner@… 10 years ago.
patch to resolve LiveTV while recording same channel issue
log4 (513.6 KB) - added by Frank Phillips <fphillips81@…> 10 years ago.
backend log with issue
11119-v2.diff (1.6 KB) - added by paulh 10 years ago.
Patch from Frank Phillips

Download all attachments as: .zip

Change History (24)

comment:1 Changed 11 years ago by scott.harris0509@…

I think I misinterpreted the events that cause this issue. If an in process recording is established, tuning to the same channel in Live TV will not cause the recording group to change. However, if you're watching Live TV at the time a scheduled recording begins on the same channel, the recording will be changed to the Live TV group, regardless of what group it is specified to be.

comment:2 Changed 11 years ago by danielk

Scott, what checkout was this with?

This is something that should be fixed in master.

comment:3 Changed 11 years ago by scott.harris0509@…

Daniel, it's with the most recent master from Mythbuntu repositories....

MythTV Version : v0.26-rc2-55-g6596484 MythTV Branch : master Network Protocol : 75 Library API : 0.26.20120822-1 QT Version : 4.8.1 Options compiled in:

linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_crystalhd using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libcec using_libcrypto using_libdns_sd using_libxml2 using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vaapi using_vdpau using_ffmpeg_threads using_live using_mheg using_libass using_libxml2

comment:4 Changed 11 years ago by stuartm

Owner: set to danielk
Status: newassigned

comment:5 Changed 11 years ago by dabears_rule@…

I am on the latest version of mythbuntu. This issue still persist for me. I have 4 tuners. Can I offer anything that may be of use in solving this?

comment:6 Changed 11 years ago by JYA

#11752 has been marked as a duplicate

comment:7 Changed 10 years ago by briann1177@…

This issue still exists in version .27 that was released 18 Sep 2013.

comment:8 Changed 10 years ago by briann1177@…

Here is an extract of my mythbackend log when this happens. I've extracted what should be the relevant information. I have my recordings scheduled to begin 30 seconds before the scheduled time.

2013-11-26 18:59:30.578767 I [942/1212] Scheduler scheduler.cpp:2644 (HandleRecordingStatusChange?) - Tuning recording: "The Biggest Loser": channel 2041 on cardid 18, sourceid 2 2013-11-26 18:59:31.364903 I [942/942] CoreContext? scheduler.cpp:705 (UpdateRecStatus?) - Updating status for "The Biggest Loser" on cardid 18 (Tuning => Recording) 2013-11-26 18:59:31.957542 I [942/1199] TVRecEvent tv_rec.cpp:4117 (TuningNewRecorder?) - TVRec[18]: rec->GetPathname?(): '/mnt/nfs/mythtv/tv_recordings/2041_20131127010000.mpg'

...

2013-11-26 19:00:00.798970 E [942/1195] TVRecEvent recordinginfo.cpp:928 (InsertProgram?) - RecordingInfo::InsertProgram?(ProgramInfo?(2041_20131127010000.mpg): channame(KFOR-DT) startts(Wed Nov 27 01:00:00 2013) endts(Wed Nov 27 02:00:00 2013)

recstartts(Wed Nov 27 01:00:00 2013) recendts(Wed Nov 27 02:00:00 2013) title(The Biggest Loser)): recording already exists...

comment:9 Changed 10 years ago by jtbreitner.lists@…

Relevant query results: http://pastebin.com/qRbKZG2y Hardware in use: Two HDHR-Prime 3-tuner units.

In the above pastebin, there is one entry for the program in mythconverg.oldrecorded and two entries in mythconverg.recorded; one for the recording and one for the LiveTV stream each with recordid=350. The query output is after the recording and live tv sessions ended thus confirming the recording group does not change.

mythconverg.oldrecorded.recordstatus remains at rsRecording until the backend is restarted. I believe OldRecordedFixUp? catches these at start and sets them to aborted. Changing oldrecorded.recordstatus to rsRecorded will release the two entries and they'll appear in the program listing.

A search for this program in the MysQL query log does not produce a "REPLACE into oldrecorded..." for this recordid that would update the recordstat.

The recording finishes first in this example, with LiveTV ending 29 seconds later.

A test of a different session with the scheduled recording scheduled to go longer than the LiveTV session produced the same results.

I am not familiar with the codebase, so if a dev/maintainer can give a hint on what might be happening, I can probably get closer to a resolution.

Changed 10 years ago by jbreitner@…

Attachment: patch.txt added

patch to resolve LiveTV while recording same channel issue

comment:10 Changed 10 years ago by briann1177@…

This patch resolved this problem for me, but it doesn't resolve the SQL error I was seeing posted previously. I will do further research on that particular issue and open a ticket if necessary.

comment:11 Changed 10 years ago by briann1177@…

The SQL problem has nothing to do with the original ticket. Sorry for the distraction and thank you for the patch.

comment:12 Changed 10 years ago by warpme@…

Hi, U think first hunk it patch.txt is wrong as it causes LiveTV progress bar will show not playback position:LiveTV duration but playback position:already aired show time. i.e. If show is 04:00 - 5:00 and user starts livetv at 04:45, after 5sec of playback and 10sec of buffering, OSD progress bar will be 0:05 : 45:15 instead of 0:05 : 0:15.

comment:13 Changed 10 years ago by jtbreitner.lists@…

There is another approach to take on solving this problem that does not have this kind of interaction.

comment:14 Changed 10 years ago by warpme@…

@jtbreitner, May You be little more verbose pls?

comment:15 Changed 10 years ago by Frank Phillips <fphillips81@…>

Since no one has explicitly stated it, I wanted to mention that this issue causes users to lose recordings if they don't notice in time. I think that warrants it a more serious priority. My analysis of the problem follows.

Following #10943, an ApplyRecordRecGroupChange() was added near the end of GetProgramRingBufferForLiveTV() to update recorded.recgroup before it is queried in StartedRecording().

The problem arises because we don't have the correct recstartts for ApplyRecordRecGroupChange() until later when we successfully insert the program in RecordingInfo::StartedRecording.

In this example, we updated the recgroup for 20140329233000 instead of 20140329233001

2014-03-29 18:30:00.873242 D [15834/15852] TVRecEvent mythdbcon.cpp:689 (exec) - MSqlQuery::exec(DBManager4) UPDATE recorded SET recgroup = 'LiveTV' WHERE chanid = '1361' AND starttime = '2014-03-29T23:30:00Z'
+----------+--------------+----------+-------------------------+
| recgroup | storagegroup | recordid | basename                |
+----------+--------------+----------+-------------------------+
| LiveTV   | Default      |      978 | 1361_20140329233000.mpg |
| LiveTV   | LiveTV       |      978 | 1361_20140329233001.mpg |
+----------+--------------+----------+-------------------------+

By the time we get to the query in StartedRecording(), we have the correct recstartts.

2014-03-29 18:30:00.886798 D [15834/15852] TVRecEvent mythdbcon.cpp:689 (exec) - MSqlQuery::exec(DBManager4) SELECT recgroup FROM recorded WHERE chanid    = '1361' AND       starttime = '2014-03-29T23:30:01Z'

My patch changes the query to GetRecordingGroup() so we don't need to update the DB beforehand and we can use SetRecordingGroup() instead. This avoids the incorrect recstartts issue.

+----------+--------------+----------+-------------------------+
| recgroup | storagegroup | recordid | basename                |
+----------+--------------+----------+-------------------------+
| Default  | Default      |      982 | 1541_20140407050000.mpg |
| LiveTV   | LiveTV       |      982 | 1541_20140407050001.mpg |
+----------+--------------+----------+-------------------------+

I've run this patch for the last week with no regressions that I can see. All recgroups are set appropriately.

Regarding the patch in comment 9, and no disrespect to its author, I think it treats the symptom rather than the cause.

For master: https://github.com/fphillips/mythtv/commit/e6ca74c1a497bd82ca62aa74738d4543043d8656

Changed 10 years ago by Frank Phillips <fphillips81@…>

Attachment: log4 added

backend log with issue

comment:16 Changed 10 years ago by Stuart Auchterlonie

Milestone: unknown0.28
Owner: changed from danielk to JYA

Re-assigning to jya as he's been playing with livetv a lot lately Contains a link to a simple patch, which should be easy to test.

comment:17 Changed 10 years ago by Frank Phillips <fphillips81@…>

Please mark this as Patch - Bug Fix

Changed 10 years ago by paulh

Attachment: 11119-v2.diff added

Patch from Frank Phillips

comment:18 Changed 10 years ago by paulh

Type: Bug Report - GeneralPatch - Bug Fix

comment:19 Changed 10 years ago by Frank Phillips <frankalso@…>

Resolution: fixed
Status: assignedclosed

In 9c666b602edc41781853e0698191f3239341a33b/mythtv:

Keep some recordings from getting a LiveTV recgroup

Following #10943, an ApplyRecordRecGroupChange?() was added near the
end of GetProgramRingBufferForLiveTV() to update recorded.recgroup
before it is queried in StartedRecording?().

The problem arises because we don't have the correct recstartts for
ApplyRecordRecGroupChange?() until later when we successfully insert
the program in RecordingInfo::StartedRecording?.

Fixes #11119
Signed-off-by: David Engel <dengel@…>

comment:20 Changed 10 years ago by Frank Phillips <frankalso@…>

In 1023a65e883f5d1dc245d622709fd77a26bc75c4/mythtv:

Keep some recordings from getting a LiveTV recgroup

Following #10943, an ApplyRecordRecGroupChange?() was added near the
end of GetProgramRingBufferForLiveTV() to update recorded.recgroup
before it is queried in StartedRecording?().

The problem arises because we don't have the correct recstartts for
ApplyRecordRecGroupChange?() until later when we successfully insert
the program in RecordingInfo::StartedRecording?.

Fixes #11119
Signed-off-by: David Engel <dengel@…>

(cherry picked from commit 9c666b602edc41781853e0698191f3239341a33b)

comment:21 Changed 10 years ago by gigem

Milestone: 0.280.27.1
Note: See TracTickets for help on using tickets.