[mythtv-users] Why I prefer to watch sport via "Live TV" vs. recorded

[Michael T. Dean]

On 11/12/2012 06:31 AM, Mike Perkins wrote:
> On 12/11/12 00:26, Gary Buhrmaster wrote:
>> On Sun, Nov 11, 2012 at 3:02 PM, Mike Perkins  wrote:
>> ...
>>> Personally, I would have considered that the fact that the status is 
>>> still
>>> 'recording' but the file cannot be found is prime evidence that 
>>> something
>>> has failed. Why does the recording not fail immediately when the 
>>> file is
>>> missing?
>>
>> How would MythTV know the difference between the channel
>> tuned is currently not sending the any data from the specified
>> program/serviceid (i.e. no data) vs. the capture card has failed
>> silently with no indication of failure?  If the capture card is failing
>> to send data with no error messages than this is a driver issue
>> (and MythTV does not claim to handle drivers that silently fail).
>> Some drivers are probably better than others in detecting
>> capture card failures (some do seem to do a handshake that
>> if it stops, the driver produces errors; perhaps your driver
>> could be enhanced to do something similar).
>>
>> I would recommend sending the error reports to the group
>> (or individual) supporting your card.  They may be able to
>> assist, or work with you to provide appropriate debugging
>> assistance.  I hate to suggest it, but sometimes the
>> Linux drivers are not as robust as those in other OSs
>> (and sometimes they are more robust).
>>
> Either the error message is wrong or the argument you present above is 
> not relevant. The output file is *missing*. Does mythtv /really/ wait 
> for the first buffer-load of data before the output file is created?
>
> To me, the OP's log sequence indicated that data was available but the 
> recording thread couldn't find anywhere to put it, so dumped it.


No, the log said that the job queue was unable to run jobs because the 
file didn't exist, and the commercial detector was unable to detect 
commercials because the file didn't exist.  This is why one shouldn't be 
mixing messages from various mythtv programs into one log file (and is 
exactly why the logging was rewritten to do things properly in 
0.26+--unless, of course, someone uses syslog to stir them all back into 
one log file)

>
> Either the fault condition which produced this log sequence needs to 
> be analysed and better error messages produced, or the order in which 
> events happen when a recording started need to be investigated.
>
> I don't doubt that a failing tuner might result in a 0.0Gb file, but a 
> message that states "...mpg cannot be found" does not represent the 
> same condition as an existing but zero-length file.
>

Again, there's no error, yet.  Again, talk to the guys who make the 
hardware or the drivers and explain to them that if they don't produce 
any data for the app to read, /they/ should make the decision that an 
error occurred and /they/ should report the error, rather than writing 
MythTV to assume a failure exists and break working hardware...

Mike