[mythtv-users] Comcast encrypting World Series on FoxHD

[Michael T. Dean]

On 11/03/2014 12:58 PM, Eric Sharkey wrote:
> On Mon, Nov 3, 2014 at 11:42 AM, Ronald Frazier wrote:
>> On Sat, Nov 1, 2014 at 3:55 PM, Bob Shanteau wrote:
>>> Oops, sorry. I thought I had told you that I was not able to record World
>>> Series games on my local (Salinas, CA, USA) FoxHD channel with either a
>>> Motorola DCH3200 using firewire or an HDHomerun Prime using ethernet.
>>
>> Oops...premature post via keyboard shortcut on that last message :-(
>>
>> Anyway, I'll add an additional thought to this (regarding the prime...I
>> don;t know much about firewire DRM). Cable companies usually don't flip CCI
>> flags on individual programs. They usually do it per channel and it never
>> changes unless someone goes in and reconfigures. So most likely the DRM is
>> coming from the analog CGMS flags.
> Ideally, MythTV should be a bit smarter about this and attempt to
> reschedule the recording on another video source in real-time if one
> is available.  For example, many users seem to have both 1 HDHR Prime
> + 1 HDPVR (I do).  If no recording is scheduled on the HDPVR, and a
> recording fails on Prime, the recording should dynamically switch to
> the other tuner as soon as it's practical.  This would work equally
> well for multiple types of failures whether it's CGMS flags or (in a
> recent event at my house) a cat damaging the cable feeding the Prime.
>
> (I know, easier said than done, patches welcome, etc. etc.)

Does MythTV even know that the recording failed?  TTBOMK, we only figure 
it out when, after the recording ends, we still haven't been given any 
data for the recording.  I know this happens when using standard DVB/V4L 
recorders, but don't know for sure what happens with OCUR recorders (do 
we actually get an error from the driver when we try to use it to tune 
the locked/encrypted channel?).

When a recording fails--and we are told it failed (i.e. a channel change 
script returns a failure code)--MythTV does change the state of the 
recording to failed and re-runs the scheduler.  At that point any future 
showings of the episode will be considered for recording (where a future 
showing is always preferred over a partial showing, as would be the case 
for the in-progress showing that already failed to record on one input).

I don't think MythTV will currently consider recording a partial showing 
(i.e. re-start recording the current showing) from a different 
source/input due to a failure of the recording on the scheduled input 
because MythTV had already decided (based on schedule order and 
priorities) to record the episode from the source/channel it just tried 
using with the input it just tried using because that's what you told it 
to use (with schedule order/priorities).  It may be possible to change 
it to consider partial recordings from other inputs after failing to 
record on the scheduled input, but doing so will open a can of worms for 
handling "broken" hardware.  For example, we'd need to try to prevent 
the whole "keep doing the same thing and expecting different results" 
insanity creating an infinite (or at least runtime length) loop of 
try/fail/write copious error messages to log cycles.  And, if we end up 
doing things like, "just mark the input as failed," how do we know when 
to use it again (after this particular showing's end time or after some 
number of hours/days or until the user "recertifies" the input or...) 
and how does this affect scheduling (do we mark the input as unavailable 
for other recordings that start during this showing's run time and/or 
shows that start at this showing's end time and how do we handle 
conflicts that exist only because we're now thinking that input isn't 
available (do we try our best to use other inputs and only fall back to 
the just-failed input as a last resort, at least while it's marked as 
unavailable) and what happens when we loop over all the inputs and fail 
them all out just because of some channel-specific issue and a user 
loses all their favorite prime-time shows because their low-priority 
recording of (an oft-repeated) Nova episode from PBS failed because of 
some short-term transient broadcast issue that occurred only for a 
minute or two at the start of the showing--which then brings up the 
question of whether we should, after trying and failing with all inputs, 
wait a few minutes and try again in case it was a transient broadcast 
(or reception) issue...).

Basically, it's a lot easier to just require/presume working "hardware" 
(where I'm considering CCI/CGMS failures under the heading of "hardware" 
failures because there's nothing we can do about them).  And doing so 
has predictable results that--while perhaps not optimal for everyone in 
every situation with every possible hardware configuration--never make 
things worse for anyone.

Mike