Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Firewire code and ticket #10277: Warning: No Input in xxx msec

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


cats22 at comcast

Apr 29, 2012, 3:33 PM

Post #1 of 3 (287 views)
Permalink
Firewire code and ticket #10277: Warning: No Input in xxx msec

I had developed a fix for the firewire bug where never ending messages
occur filling up logs and losing recordings: Warning: No Input in 50
msec . . . etc.

This was working perfectly on mythtv 0.24 for a few months.

Version 0.25 has broken my fix. I am reworking it. I am astonished how
many changes there are to the firewire code since Daniel had said that
he sees not much future for it since so few people are using it.

The logging is considerably changed, but I suppose that is a generic
change across everything.
StartRecording() is renamed run().
The way StopRecording() works is changed and it moved up to RecorderBase.
The pause in the run() loop is changed from 50 ms to 1 second.
A new function call ResetForNewFile() is added to the Open(). I am
guessing this is trying to make sure the start of a file is on a key frame?
However what is I believe an existing bug (the firewire port is never
closed) is not fixed - I have the fix for that in my patch.

I am not complaining - the opposite in fact. It looks like a lot of nice
work is being done even in firewire where so few people are using it.

Hopefully I will have my 0.25 patch working soon and attach it to the
ticket.

Peter


mlp00 at optonline

Apr 29, 2012, 4:26 PM

Post #2 of 3 (253 views)
Permalink
Re: Firewire code and ticket #10277: Warning: No Input in xxx msec [In reply to]

Peter,

thank you very much for working on this; I haven't found much time to
invest in anything with firewire lately (I'm the author of the
"sa_control" channel changer for one flavor of the SciAtlanta cable
boxes - now that I have a new box I may get back to it).

I was surprised at Daniel's statement that few people use firewire. I
record the majority of my channels through firewire, and I personally
know two more people who do, so while 3 may not be a big number, your
work is highly appreciated. And as long as there are providers which
keep most of the channels open and not 5C-protected, it's hard to beat
the quality of the all-digital recordings.

Which brings me to a slightly related issue. Every once in a while, a
new channel gets added which is protected, or a so-far open channel goes
dark. In this case, we can never get a lock, and the backend
continuously loops the "no input..." message but also never arrives at a
failure state. The messages continue past the nominal end of the
recording, and the backend seems stuck indefinitely (I have to release
it by manually ending the recording). If you can find a way to make the
backend give up gracefully after it has exhausted all the options you
mention and return to an idle state, that would be great. If you need
another guinea pig to test something, please drop me a mail.

Thank you very much,

` Martin

On 04/29/12 18:33, Peter Bennett wrote:
> I had developed a fix for the firewire bug where never ending messages
> occur filling up logs and losing recordings: Warning: No Input in 50
> msec . . . etc.
>
> This was working perfectly on mythtv 0.24 for a few months.
>
> Version 0.25 has broken my fix. I am reworking it. I am astonished how
> many changes there are to the firewire code since Daniel had said that
> he sees not much future for it since so few people are using it.
>
> The logging is considerably changed, but I suppose that is a generic
> change across everything.
> StartRecording() is renamed run().
> The way StopRecording() works is changed and it moved up to RecorderBase.
> The pause in the run() loop is changed from 50 ms to 1 second.
> A new function call ResetForNewFile() is added to the Open(). I am
> guessing this is trying to make sure the start of a file is on a key frame?
> However what is I believe an existing bug (the firewire port is never
> closed) is not fixed - I have the fix for that in my patch.
>
> I am not complaining - the opposite in fact. It looks like a lot of nice
> work is being done even in firewire where so few people are using it.
>
> Hopefully I will have my 0.25 patch working soon and attach it to the
> ticket.
>
> Peter
>
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


cats22 at comcast

Apr 29, 2012, 5:52 PM

Post #3 of 3 (248 views)
Permalink
Re: Firewire code and ticket #10277: Warning: No Input in xxx msec [In reply to]

On 04/29/12 18:33, Peter Bennett wrote:

> I had developed a fix for the firewire bug where never ending messages
> occur filling up logs and losing recordings: Warning: No Input in 50
> msec . . . etc.
>
> This was working perfectly on mythtv 0.24 for a few months.
>
> Version 0.25 has broken my fix. I am reworking it. I am astonished how
> many changes there are to the firewire code since Daniel had said that
> he sees not much future for it since so few people are using it.
>
> The logging is considerably changed, but I suppose that is a generic
> change across everything.
> StartRecording() is renamed run().
> The way StopRecording() works is changed and it moved up to RecorderBase.
> The pause in the run() loop is changed from 50 ms to 1 second.
> A new function call ResetForNewFile() is added to the Open(). I am
> guessing this is trying to make sure the start of a file is on a key frame?
> However what is I believe an existing bug (the firewire port is never
> closed) is not fixed - I have the fix for that in my patch.
>
> I am not complaining - the opposite in fact. It looks like a lot of nice
> work is being done even in firewire where so few people are using it.
>
> Hopefully I will have my 0.25 patch working soon and attach it to the
> ticket.
>
> Peter
>
>
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev


On 4/29/2012 7:26 PM, Martin Purschke wrote:
> Peter,
>
> thank you very much for working on this; I haven't found much time to
> invest in anything with firewire lately (I'm the author of the
> "sa_control" channel changer for one flavor of the SciAtlanta cable
> boxes - now that I have a new box I may get back to it).
>
> I was surprised at Daniel's statement that few people use firewire. I
> record the majority of my channels through firewire, and I personally
> know two more people who do, so while 3 may not be a big number, your
> work is highly appreciated. And as long as there are providers which
> keep most of the channels open and not 5C-protected, it's hard to beat
> the quality of the all-digital recordings.
>
> Which brings me to a slightly related issue. Every once in a while, a
> new channel gets added which is protected, or a so-far open channel goes
> dark. In this case, we can never get a lock, and the backend
> continuously loops the "no input..." message but also never arrives at a
> failure state. The messages continue past the nominal end of the
> recording, and the backend seems stuck indefinitely (I have to release
> it by manually ending the recording). If you can find a way to make the
> backend give up gracefully after it has exhausted all the options you
> mention and return to an idle state, that would be great. If you need
> another guinea pig to test something, please drop me a mail.
>
> Thank you very much,
>
> ` Martin
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>
Hi Martin

My patch is designed so that if after a couple of attempts it cannot
recover from the error, it will fail the recording. That part was
working in 0.24 and I should be able to get it working in 0.25. A good
test for this is to unplug the firewire cable while recording, the
released versions 0.24 and 0.25 go into the loop of "No Input .. "
messages until the end of the recording time. My patch will fail the
recording after a minute or so, then at least the system can try record
it again and you do not get the log full of those errors.

I am not sure about it going past the end of the recording time. I did
have that issue yesterday but it was caused by my coding bug I believe.

If you are on 0.24, my patch is already available in the ticket. I hope
to have the 0.25 soon. Any testing you can do is helpful - if you notice
any problem with the patch let me know.

You said you have a channel changer for scientific altanta boxes. I had
never got that to work so eventually I got an IR blaster. I have the
scientific atlanta 3250. Do you have a solution for that?

Unfortunately some of my channels are copy protected - in haphazard way,
for example History channel and the HD version of FX, but On-Demand is
not protected. I called Comcast and they assured me that EVERYTHING was
protected, so no joy there.

Peter

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.