Opened 5 years ago

Last modified 7 months ago

#11817 new Bug Report - General

Switching via OSD to another virt. tuner kills recording if tuning fails

Reported by: warpme@… Owned by: danielk
Priority: minor Milestone: 29.2
Component: MythTV - Recording Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

If user changes in OSD to another virtual tuner on the same phy tuner and tuning fails - recording on this mplex will be halted and subsequent launches of LiveTV are failed until user finishes/deletes broken halted recording on mplex in question.

Change History (10)

comment:1 Changed 5 years ago by Jim Stichnoth

Milestone: unknown0.28
Resolution: Fixed
Status: newclosed

I'm going to mark this as fixed - sorry that it's probably not fixed the way you might prefer.

MythTV has some ever-evolving logic to try to minimize tuning failures in Live TV. This logic is based on the sometimes flawed assumption that if the channel was tunable in the past, it is probably tunable now, and the logic currently involves the hidden setting DefaultChanID as the default starting channel, and the database column cardinput.startchan as the last known "good" channel on the tuner. That logic doesn't always work, most notably when a previously good channel goes off the air.

The best way to handle this might be to initiate some kind of channel scan upon tuning failure, or some dialog to let the user pick an alternate channel. In a sense, the latter approach is now implemented for Master / 0.28 via #11913, which allows the user to start Live TV on a specific channel from the Program Guide.

(Unfortunately, #11913 can't be back-ported to 0.27-fixes because it introduces a new translatable string in the Program Guide menu, and I didn't find a suitable already-translated string to reuse.)

comment:2 Changed 5 years ago by warpme@…

Jim, I think we have 2 separate issues here:

-1\ issue with starting LiveTV on channel which become unavailable (so gives failed tune)

-2\ failed tuning on such channel kills ongoing recording on another channel.

While I fully age with Your regarding 1\, in case of 2\ issue is IMHO serious as it kills silently ongoing recording. Sure - fulfilling conditions You mention in Your replay can minimise chance for 2\ - but if 2\ happens - user is really disappointed. And I think in practice 2\ will happen not so rarely as almost in every country it happens that SAT providers are moving channels between mplexes or changing SID for channels in mplexes. This will always cause 2\ if user hits LiveTV on such channel in such cases. I don't want to be too principal here - so it You want - pls close this ticket - but I think assigning status "fixed" is too optimistic.

BTW: I back ported #11913 to 0.27. It works as designed - but 2\ is still present :-(

comment:3 Changed 5 years ago by Jim Stichnoth

Resolution: Fixed
Status: closednew

Thanks for the clarification. I misunderstood the phrase "recording on this mplex will be halted", thinking you only meant the recording corresponding to the Live TV viewing.

It would be helpful to know whether this happens just with Live TV, or if failure to tune a channel for a scheduled recording also kills another scheduled recording on the multiplex.

comment:4 Changed 5 years ago by warpme@…

Jim, Failed tuning causes issue for LiveTV and for background ongoing recording. Summarising: if user select channel which can't be successfully tuned this will cause:

  1. halt ongoing recordings on other virtual tuners belonging to this phy. tuner
  1. if user tries LiveTV on virtual tuner on this phi.tuner - LiveTV waits with (TL_)

For unblocking 1 & 2 user must manually stop halted recording(s) on virt.tuner(s)

comment:5 Changed 5 years ago by warpme@…

Arhg - forgot to answer exactly Your question. Answer is YES. When schedulled recording fails on can't be tuned channel - other recordings on girt. tuners on this phy. tuner WILL be halted.

comment:6 Changed 2 years ago by Stuart Auchterlonie

Milestone: 0.280.29

Moving to 0.29

comment:7 Changed 2 years ago by Stuart Auchterlonie

Milestone: 0.2929.0

Milestone renamed

comment:8 Changed 9 months ago by Stuart Auchterlonie

Milestone: 29.029.1

comment:9 Changed 7 months ago by Stuart Auchterlonie

Milestone: 29.10.28.2

Moving remaining open tickets to 0.28.2 milestone

comment:10 Changed 7 months ago by Stuart Auchterlonie

Milestone: 0.28.229.2

Moving remaining open tickets to 29.2 milestone

Note: See TracTickets for help on using tickets.