Opened 10 years ago

Closed 10 years ago

#7105 closed defect (invalid)

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

Reported by: Matthew Grant <matthewgrant5@…> Owned by: Janne Grunau
Priority: minor Milestone: unknown
Component: MythTV - Video Playback Version: head
Severity: low Keywords:
Cc: steven@… Ticket locked: no

Description

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.

Attachments (1)

mythtv-trunk-log-message-fix.diff (2.0 KB) - added by Matthew Grant <matthewgrant5@…> 10 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by Matthew Grant <matthewgrant5@…>

comment:1 Changed 10 years ago by 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.

comment:2 Changed 10 years ago by Matthew Grant <matthewgrant5@…>

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

comment:3 Changed 10 years ago by 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

comment:4 Changed 10 years ago by 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...

comment:5 Changed 10 years ago by einstein@…

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

comment:6 Changed 10 years ago by 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.

comment:7 Changed 10 years ago by einstein@…

i will test it tomorrow, thanks

comment:8 Changed 10 years ago by 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.

comment:9 in reply to:  6 ; Changed 10 years ago by 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.

comment:10 in reply to:  9 Changed 10 years ago by Shane Shrybman

Component: MythTV - GeneralMythTV - Video Playback
Owner: changed from Isaac Richards to Janne Grunau
Priority: criticalminor
Severity: highlow

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.

comment:11 Changed 10 years ago by Janne Grunau

Status: newinfoneeded_new

please retest

comment:12 Changed 10 years ago by robertm

Resolution: invalid
Status: infoneeded_newclosed

No response from submitter.

Note: See TracTickets for help on using tickets.