Modify
Warning Please read the Ticket HowTo before creating or commenting on a ticket. Failure to do so may cause your ticket to be rejected or result in a slower response.

Opened 18 months ago

Closed 15 months ago

Last modified 15 months ago

#11207 closed Bug Report - General (fixed)

fixes/0.26 LiveTV does not move recordings.

Reported by: dannyfiru@… Owned by: danielk
Priority: major Milestone: 0.25.4
Component: MythTV - Recording Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

commit [e3087dda66175a6b7308ad5a5e80a35ff7d72fd3]
Running a detached master backend with lite front end.

Both are running the above commit on fixes/0.26.

Howdy folks. I moved to 0.26 because of all the trouble I was having on 0.25 with live tv. I moved to 0.25 from 0.24 because of the native HD Homerun Prime support.

However I'm still experiencing some issues with the liveTV.

Summary:

  • Allow live TV to move recordings where possible is set on the frontend client.
  • The back end is currently running 3 tuners from the HD Homerun Prime.

Use Case:

  1. While watching the monday night football game live (yeah in the US), myth wants to record some recurring prime time show.
  2. 30 seconds before recording starts, I am prompted that Myth wants the tuner and asked if I a] want to watch it while it records, b] want to let it record and return to the main menu, b] want to cancel the recording and watch livetv.
  3. There are 2 other recording resources for it to select from. So clearly the liveTV moving recordings does NOT work currently.
  4. Selecting option a] from above will record the the show into the livetv storage group. For speed purposes this storage group is small by comparison the my NAS. So, I have recordings hanging around on my smaller livetv drive. Slowly but surely it will fill up and cause problems.

Attachments (3)

mythtv.ticket11207.tonsofpcs.20130115.tgz (576.4 KB) - added by tonsofpcs 15 months ago.
I had recordings set for 1930-2000, 2131-2200, and 2200-2300 on 34.1; 2000-2100 and 2100-2200 on 12.1; 2000-2030, 2030-2100, and 2100-2130 on 40.1; 2000-2100 and 2200-2300 on 46.1, added a recording from 2031 to 2101 to 34.1 and the 2000 recording on 46.1 shifted itself... (this around 1734). During actual 'run', based on livetv recordings, was on 46.1, moved to 34.1 at 1900, moved to 40.1 at 2000, moved to 12.1 at 2100, and 34.1 at 2200. I was not home to watch, so the dialogs just passed untouched.
tonsofpcs.20130117.mythbackend.early.log (853.4 KB) - added by tonsofpcs 15 months ago.
All times listed are Z-0500 (Eastern Standard Time) 2013-01-17 Abt 1730, I remotely (via ssh and vnc) killed the backend and frontend processes and the processes that auto-spawn them. Relaunched the backend with "-v schedule,general --loglevel info", teed to the attached log file. via vnc, I started livetv on 12.2. A quick grepping by my untrained eye shows: looks like my 10 minute audio recording (42-6, same mux as 46.*) fired at 1800 from tuner 3->3 (1->1 was in use for livetv), 1900 recording of Wheel (34.1) from 3->3 (I see no note for 1930 Jeopardy(34.1) but I imagine it too came from 3->3), 2000 recording of 30 Rock from 2->2 (2->2 is the second encoder of 1->1, 30 Rock is on 34.2) and recording of Last Resort (34.1) from 1->1... this displaced 12.2 from live. Log near 2000 shows a lot of istunable "channel is valid, but tuner is busy on a different multiplex" messages. Attached log pulled at 2033. Still logging with frontend still in LiveTV as I post this message.
11207-livetv-0.25-2.patch (4.1 KB) - added by gigem 15 months ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 18 months ago by dannyfiru@…

BTW I'm fairly new to the whole mythtv thing (a little over a year). But not new to the whole development thing. If you guys could point me to where I might look in the code, maybe I could branch, work on it and submit a pull request.

Let me know.

comment:2 Changed 17 months ago by tonsofpcs@…

Duplicated here.
8:59 PM, watching Two and a Half Men on WBNG-DT (12.1, it ends at 9:01PM), on Encoder 1 (first tuner) I got a similar popup about recording Glee on WICZ-DT (40.1). I ignore it.
9 PM, I get thrown to watching Glee. Glee starts recording on Encoder 1, Live TV is on Encoder 2 (still first tuner); Grey's Anatomy starts recording on Encoder 5 (third tuner) from WIVT-DT (34.1). Up/Down? only show 40.1 and 40.2.
9;01 PM: Person of Interest starts recording on Encoder 3 (second tuner) from WBNG-DT (12.1).

I still can only up/down between 40.1 and 40.2.

There are four ATSC channels in this market, I get all four on my two HDHomeRun Duals (four tuners). Each of the four tuners has four encoders attached (originally set for 2 each, interleaved so encoders 1,2,9,10 are hdhr1/tuner0, 3,4,11,12 are hdhr2/tuner0, 5,6,13,14 are hdhr1/tuner1, 7,8,15,16 are hdhr2/tuner1). This should *NEVER* happen (well, maybe if I actually have a show recording from every source and I try recording from all 5 programs on 42 but I would never do that).

MythTV Version : v0.25.2-15-g46cab93
MythTV Branch : fixes/0.25
Network Protocol : 72
Library API : 0.25.20120506-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:3 Changed 17 months ago by gigem

  • Status changed from new to infoneeded_new

First, please make sure you have the "Allow Live TV to move scheduled shows" setting enabled. It's on the first page in Setup / Video / General. Second, please run the master backend with "-v schedule --loglevel debug" and attach the log to this ticket if you can reproduce the problem.

Changed 15 months ago by tonsofpcs

I had recordings set for 1930-2000, 2131-2200, and 2200-2300 on 34.1; 2000-2100 and 2100-2200 on 12.1; 2000-2030, 2030-2100, and 2100-2130 on 40.1; 2000-2100 and 2200-2300 on 46.1, added a recording from 2031 to 2101 to 34.1 and the 2000 recording on 46.1 shifted itself... (this around 1734). During actual 'run', based on livetv recordings, was on 46.1, moved to 34.1 at 1900, moved to 40.1 at 2000, moved to 12.1 at 2100, and 34.1 at 2200. I was not home to watch, so the dialogs just passed untouched.

Changed 15 months ago by tonsofpcs

All times listed are Z-0500 (Eastern Standard Time) 2013-01-17 Abt 1730, I remotely (via ssh and vnc) killed the backend and frontend processes and the processes that auto-spawn them. Relaunched the backend with "-v schedule,general --loglevel info", teed to the attached log file. via vnc, I started livetv on 12.2. A quick grepping by my untrained eye shows: looks like my 10 minute audio recording (42-6, same mux as 46.*) fired at 1800 from tuner 3->3 (1->1 was in use for livetv), 1900 recording of Wheel (34.1) from 3->3 (I see no note for 1930 Jeopardy(34.1) but I imagine it too came from 3->3), 2000 recording of 30 Rock from 2->2 (2->2 is the second encoder of 1->1, 30 Rock is on 34.2) and recording of Last Resort (34.1) from 1->1... this displaced 12.2 from live. Log near 2000 shows a lot of istunable "channel is valid, but tuner is busy on a different multiplex" messages. Attached log pulled at 2033. Still logging with frontend still in LiveTV as I post this message.

comment:4 Changed 15 months ago by danielk

  • Status changed from infoneeded_new to new

Gigem, assigning to you. If it is a recorder problem and not scheduling feel free to punt back.

Changed 15 months ago by gigem

comment:5 Changed 15 months ago by warpme@…

Gigem, I think I observe OP issue also on my 0.26-fixes. It is possible to prepare patch also for 0.26-fixes ?

comment:6 Changed 15 months ago by gigem

I will probably commit the fix for this ticket this weekend. When I do that, I will make a version for 0.26.

comment:7 Changed 15 months ago by David Engel <dengel@…>

  • Resolution set to fixed
  • Status changed from new to closed

In b05ecd4666a540648627e0af8f3666bb008a0e1c/mythtv:

Fix issues which sometimes prevente scheduling around live TV.

There are some cases where we don't attempt to schedule around live
TV. This change cleans up the logic which determines when to do that
and fixes some of the bugs found in the process.

NB: the case where a user enters live TV immediately before a
recording is scheduled to start is still not handled gracefully.
Fixing that is a lot tougher and will likely mean involving the
scheduler in choosing which input to use for live TV.

Fix #11207

comment:8 Changed 15 months ago by David Engel <dengel@…>

In 14aa70771e85e401c68cac78a49b8ef344cce873/mythtv:

Fix issues which sometimes prevente scheduling around live TV.

Backport of SHA1:b05ecd46 to fixes/0.26.

There are some cases where we don't attempt to schedule around live
TV. This change cleans up the logic which determines when to do that
and fixes some of the bugs found in the process.

NB: the case where a user enters live TV immediately before a
recording is scheduled to start is still not handled gracefully.
Fixing that is a lot tougher and will likely mean involving the
scheduler in choosing which input to use for live TV.

Refs #11207

comment:9 Changed 15 months ago by David Engel <dengel@…>

In 79a24c90efd3308895880cbad4a4e550986aedda/mythtv:

Fix issues which sometimes prevente scheduling around live TV.

Backport of SHA1:b05ecd46 to fixes/0.25.

There are some cases where we don't attempt to schedule around live
TV. This change cleans up the logic which determines when to do that
and fixes some of the bugs found in the process.

NB: the case where a user enters live TV immediately before a
recording is scheduled to start is still not handled gracefully.
Fixing that is a lot tougher and will likely mean involving the
scheduler in choosing which input to use for live TV.

Refs #11207

comment:10 Changed 15 months ago by wagnerrp

  • Milestone changed from unknown to 0.25.4

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'new'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.