[mythtv] libcmyth failing to receive HD stream

[Chase Douglas]

On Feb 22, 2009, at 8:01 AM, Stuart Morgan wrote:
> On Saturday 21 February 2009 23:39:54 Chase Douglas wrote:
>> I'm working on a separate frontend project using libcmyth and I've
>> been able to generate and play a live tv SD stream from an IVTV card.
>> A few times I've been able to generate and play an HD stream from a
>> pcHDTV-5500 card. However, usually the HD stream playback doesn't
>> work. The frontend keeps requesting bytes (as low as 1 byte), and the
>> backend keeps returning 0.
>>
>> My guess as to why I'm seeing this only on HD streams is that the SD
>> stream from the IVTV card is "always on". There's no lag time between
>> starting a recording and the recording file being available apart  
>> from
>> the backend processes creating the recording. However, a digital
>> recording has to first tune and lock on to the signal before the
>> recording actually starts. I am guessing that my frontend is missing
>> some step between spawning live tv and beginning to request bytes of
>> the stream. I see the following in the backend log:
>>
>> 2009-02-21 17:10:46.739 Preview Error: Previewer file '/home/mythtv/
>> recordings/1840_20090221171043.mpg' is not valid.
>> 2009-02-21 17:10:46.740 Preview Error: Run() file not local: '/home/
>> mythtv/recordings/1840_20090221171043.mpg'
>> 2009-02-21 17:10:46.746 Preview Error: Preview process not ok.
>>                         fileinfo(/home/mythtv/recordings/
>> 1840_20090221171043.mpg.png) exists: 0 readable: 0 size: 0
>> 2009-02-21 17:10:51.531 RingBuf(/home/mythtv/recordings/
>> 1840_20090221171043.mpg): Invalid file (fd -1) when opening '/home/
>> mythtv/recordings/1840_20090221171043.mpg'.
>> 2009-02-21 17:10:51.567 MainServer::HandleAnnounce Playback
>> 2009-02-21 17:10:51.568 adding: mythtv as a client (events: 0)
>> 2009-02-21 17:10:51.580 RingBuf(/home/mythtv/recordings/
>> 1840_20090221171043.mpg) Error: Invalid file descriptor in  
>> 'safe_read()'
>> --- last line repeating indefinitely ---
>>
>> I've run a tcpdump of a MythTV frontend to see what messages it sends
>> back and forth. I see it send on a control port:
>>
>> MYTH_PROTO_VERSION
>> ANN Playback
>> QUERY_RECORDER SPAWN_LIVETV
>> QUERY_RECORDER IS_RECORDING (backend returns 1)
>> *QUERY_RECORDER IS_RECORDING (backend returns 1)
>> *QUERY_RECORDER GET_FRAMERATE
>> *QUERY_CHECKFILE (backend returns 1 and filename)
>> *MESSAGE RECORDING_LIST_CHANGE
>> *QUERY_RECORDER FRONTEND_READY
>> *MESSAGE RECORDING_LIST_CHANGE
>> *QUERY_CHECKFILE (backend returns 1 and filename)
>> *MESSAGE RECORDING_LIST_CHANGE
>>
>> Then a new control port and the video streaming port are spawned  
>> and I
>> see:
>>
>> ANN Playback
>> ANN FileTransfer (on the streaming port)
>> QUERY_FILETRANSFER REQUEST_BLOCK
>>
>> And from then on things progress as one would expect, with the new
>> control port requesting blocks and the new streaming port receiving
>> the blocks. My frontend using libcmyth leaves out any of the messages
>> I've starred (*) above. Which, if any, of these messages are  
>> required?
>> Does this explain why I'm having issues with the digital stream, or  
>> am
>> I missing something? Is there something on the event connection,  
>> which
>> I'm not really listening to, that is salient?
>
> I'm guessing (really just a guess) you need QUERY_CHECKFILE() to  
> check that
> the file you are trying to read from has been created before you  
> attempt
> playback.

I've been looking through the mythtv source to figure out what is  
happening. It seems that when the backend gets an "ANN FileTransfer"  
message it creates a FileTransfer object, which creates a RingBuffer  
for the file. RingBuffer::RingBuffer calls RingBuffer::OpenFile, which  
tries to open the file and read some data. After a certain amount of  
time, if it can't open and read an amount of bytes from the file, it  
gives up and sets the RingBuffer file descriptor to -1. There are no  
other calls to RingBuffer::OpenFile that I can see, so from here on  
out the whole FileTransfer object is pretty much useless. In my  
opinion, the ANN FileTransfer message shouldn't return "OK" in this  
case, but it does.

To get around this, the frontend can call "QUERY_FILETRANSFER IS_OPEN"  
to figure out if the file descriptor is valid. I don't see this used  
anywhere in the frontend though, so I'm still wondering how  
mythfrontend gets around such a scenario.

A previous work around I was trying involved repeatedly sending "ANN  
FileTransfer" messages and waiting for an OK response with a non-zero  
file size. This isn't perfect though as the file size is retrieved  
after the file opening is attempted, and there's no precondition on  
the file size that the file descriptor is valid. However, what I found  
was if the initial "ANN FileTransfer" message had a zero file size,  
further "ANN FileTransfer" messages would also have a zero file size,  
even though I can ssh into the backend and see that the file size is  
in fact non-zero. I'm perplexed how this could be happening and would  
appreciate any insight anyone has.

Thanks