Broadcast H264 tuning fails due to cascade of thousands of log messages

[Matthew Grant <matthewgrant5@…>]

Race condition during tuning with broadcast H264 here in New Zealand. Box was under heavy recording load, 5 shows being recorded to disk and Live TV browsing, lots of channel changing and it is painfully slow at doing it. Thousands of Log messages produced about:

2009-09-20 07:35:21.687 [h264 @ 0x7f658b991a20]number of reference frames exceeds max (probably corrupt input), discarding one

and 2nd choke point hidden by above:

2009-09-20 10:43:57.123 DTVRec(35) Error: FindH264Keyframes: No ringbuffer

mythbackend would then segfault away into oblivion.

Fix/hack commenting out messages attached to ticket

Box has 4 HD DB-T tuners Hauppauge HVR2200s, and 2 DVBS tuners, HVR4000, and an AMD PhenomII X4 CPU, NVida 9400GT video, (will use built in ATI HD3300 when drivers are good).

With logging set to General,Important, while tuning mythbackend spends all its time formatting and logging error messages, which actually cascades and results in tuning failure - this would only show up in New Zealand or Norway as they are currently the only countries known to broadcast using the H264 codec.

Work around is to set --verbose=none - this is how I determined it was the time spent formating thousands of log messages - not very useful if you want to know what else is going on...

With this fix/hack in place TV watching works well here in NZ.

Better solution would be to implement counters in static variables that tick over every few thousand and emit one log message...

Comments about how to correct for merge would be appreciated.

[Matthew Grant <matthewgrant5@…>]

O, time spent formatting one log message in sscanf/printf type stuff meant that H264 decoding did not take place and somehow ruined tuning lock -- all the extra frames in the backend ring buffer received while formatting the message meant that the H264 decode somehow went wacky, result in the same error over again...

Race is avoided now. I guess that tuning into H264 broadcast hasn't been tested under heavy load yet.

Box is going sweetly now though, and has for the last few hours.

[Matthew Grant <matthewgrant5@…>]

And I observed the condition was affected majorly by the size of the backend ringbuffer.

[einstein@…]

same probleme here, but sometimes it works without the error... i think if i was on an encrypted channel, then it doesn't work. i have to check this...

greets st0ne

[Matthew Grant <matthewgrant5@…>]

Hi!

I need a way of seeing if the backend is tuning so that I can put an if statement around these log messages. This seems to be the cleanist way to work around them.

This is better than just commenting them out...

[einstein@…]

i think that solves the much log messages... but not the problem why it isn't tuning, or decoding the h264 stream...?

[Shane Shrybman]

You could also try the LiveTV_DTV_ringbuffer_check_debug2.diff patch on #6612. It may help with the "No ringbuffer" problem during LiveTV channel changes.

[einstein@…]

i will test it tomorrow, thanks

[Matthew Grant <matthewgrant5@…>]

Interesting ... I am still getting H264 unref short faliures when watching TV. Mostly mythfrontend recovers, but it slowly goes potty....

I think that I have just being dealing with the symptoms (log message races) of a tuning problem in the H264 codec. To my intuition it involves the reference frame counting in H264, and very likely causes a memory leak...

Can someone with experience in this area log into my machine and have a look? its quite grunty, and fast for compiles. We will have to coordinate this though....

I will have a look at that LiveTV_DTV_ringbuffer check patch, but my years of programming experience tell me the problem is somewhere else, involving H264 broadcast reception, as MPEG2 is definitely rock solid and has worked for years. i am dealing with the teething problems of a new H264 codec.

[anonymous]

Replying to gnome42:

You could also try the LiveTV_DTV_ringbuffer_check_debug2.diff patch on #6612. It may help with the "No ringbuffer" problem during LiveTV channel changes.

i've tested the patch now. it doesn't work!

i'll get now thousands of this messages:

2009-09-26 11:20:43.573 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.628 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.683 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.739 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.794 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.849 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.905 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:43.960 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.015 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessAudioTSPacket() no ringBuffer. Start buffering
2009-09-26 11:20:44.071 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.126 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.183 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.239 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.294 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessAudioTSPacket() no ringBuffer. Start buffering
2009-09-26 11:20:44.349 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.
2009-09-26 11:20:44.405 DVBRec(19:/dev/dvb/adapter2/frontend0): ProcessVideoTSPacket() no ringBuffer. Start buffering.

[Shane Shrybman]

Replying to anonymous:

Replying to gnome42:

You could also try the LiveTV_DTV_ringbuffer_check_debug2.diff patch on #6612. It may help with the "No ringbuffer" problem during LiveTV channel changes.

i've tested the patch now. it doesn't work!

The patch only deals with the lack of a ringBuffer during some LiveTV channel changes. It does not do anything codec specific. I agree your problems are likely H264 codec teething problems which I can't help with.

i'll get now thousands of this messages:

BTW: It looks like you might have applied version one of the patch which is too verbose.

[Janne Grunau]

please retest

[robertm]

No response from submitter.