[mythtv-users] Live TV playback frustration

[Thomas Mashos]

On Fri, Aug 24, 2012 at 8:14 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 08/24/2012 10:55 AM, Thomas Mashos wrote:
>>
>> On Fri, Aug 24, 2012 at 3:50 AM, Michael T. Dean wrote:
>>>
>>> On 08/23/2012 03:15 PM, Ian Wilkinson wrote:
>>>>
>>>> You could setup a recording and watch it live from the recordings list
>>>> (as
>>>> is the recommended method in Myth).  However, if you were channel
>>>> surfing
>>>> and stumbled across it (perhaps you'd forgotten it was on but fancied
>>>> watching it there and then), you could wind back to the start of the
>>>> show
>>>> without going to the recordings list.  It just used the recording file
>>>> when
>>>> you reached this channel when surfing.
>>>>
>>>> Does myth do this? No, it insists on creating two recordings of the same
>>>> thing, because myth is not looking at providing the user with the
>>>> content,
>>>> myth is just looking at it as two different consumers that both happen
>>>> to be
>>>> receiving the same data.
>>>
>>>
>>> In MythTV, Live TV has an implied contract that the Live TV viewer is the
>>> "owner" of the tuner.  If you were channel surfing and stumbled across a
>>> channel on which a scheduled recording is occurring and MythTV noticed
>>> and
>>> instead started playing back the scheduled recording, it would presumably
>>> "release" the tuner you were using for Live TV.  And, unlucky you, your
>>> wife
>>> just happened to start Live TV--and claim that just-released tuner--right
>>> before you hit channel up, again.  Now you've lost your tuner, so what to
>>> do?
>>>
>>> What you describe is easy to implement in a single-system setup.  MythTV
>>> is
>>> a multi-system DVR that may have more than just one concurrent user on
>>> any
>>> of potentially many frontend systems.  We need a way to ensure that Live
>>> TV
>>> continues to work like Live TV even if you surf through channels with
>>> scheduled recordings.
>>
>> That seems like you could fix that by locking the tuner to a frontend
>> while it was in "live tv mode", just because it's locked to the
>> frontend doesn't  mean it has to be recording though, it could be in
>> "standby". I suspect that when the backend attempt to start another
>> live tv session (for another user) or a recording that is only checks
>> if the tuner is currently recording. This functionality would seem to
>> resolve both mentioned issues. (FWIW, I don't use Live TV, so I don't
>> know of any of the issues.
>
>
> Oh, but then it's wasting a tuner, and users wonder why, "My tuner isn't in
> use, but it won't let others use it."  Or, "We always go into Watch TV to
> find something to watch, but then it locks up extra tuners, even though I
> end up watching recordings."
>
> That said, I'm all for notifying the user that, "This episode is currently
> recording," or, "A previous showing of this episode was recorded," and
> offering to let the user exit Live TV and begin playback of the recording.
> With that approach, the user has to tell us that's what they want and they
> no longer have expectations that Live TV things will work (like channel
> surfing or whatever).
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

True, so you're going to piss people off either way. And when that
happens, MythTV devs just need to draw a line in the sand "this is
what we decided, this is why, no we aren't going to change it or I'll
be having this same conversation in six months with the other side.".
It could be a configurable checkbox to which way to do it, but there
are already too many configurable things in the frontend anyway.

I'd probably error on the side of "less recording means less work for
the backend to do, less wear on the drives, etc" and just have the
tuner in a 'reserved' state.

Thanks,

Thomas Mashos