Opened 10 years ago

Closed 9 years ago

#7472 closed defect (Fixed)

LiveTV failes exits with "Video frame buffering failed too many times"

Reported by: olejl77@… Owned by: markk
Priority: minor Milestone: 0.25
Component: MythTV - DVB Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: yes

Description

I have a separate FE/BE setup. Currently running: MythTV Version : 22642 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.2 Options compiled in:

linux profile using_oss using_alsa using_pulse using_jack using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

In the attached log this happens 4 times during 1.5 hours. I have seen the same error message in other tickets, but they seems to be when exiting or changing channels. As far as I can see they are solved.

One interesting thing I can see is this error message: "RingBuffer::Reset() nonzero readpos. toAdjust: 1 readpos: 188 readAdjust: 425638016" every time before it failes (and only then).

I'm using a Technotrend S-1500 DVB card, tuned to Nilesat, and mostly watching Showtimearabia channels.

This never happens when watching LiveTV on the BE, it only fails at the FE. The frontend is a Zotac ION board, and I'm using VDPAU. The BE is ATI so no VDPAU.

Attachments (1)

Video frame buffering failed too many times.log (32.3 KB) - added by olejl 10 years ago.

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by olejl

comment:1 Changed 10 years ago by Kevin Walke <kev@…>

I also have this issue but it is happening on pre-recorded programmes. It is most notable with new recordings. I also have a separate FE/BE setup. The backend is running MythTV version:22884; Branch : branches/release-0-22-fixes; Network Protocol : 50; Library API : 0.22.20091023-1 QT Version : 4.5.0; Exactly same options compiled in as above. I am running ubunutu using their auto-builds. Recordings are all DVB-T using a Hauppauge Nova-T 500.

My frontend is a Via Epia running minimyth. Although I have tested on some ubuntu desktops and they have the same problem.

comment:2 Changed 10 years ago by Kevin Walke <kev@…>

Just thought I would report back. I have discovered the cause of this issue on my setup, and it has nothing to do with mythtv. I use an atom motherboard as my backend, which uses a Realtek gigabit ethernet. The issue is documented here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/347711

The video frame buffering error occurs when the ethernet card resets the connection.

comment:3 Changed 9 years ago by robertm

Owner: changed from Janne Grunau to markk
Status: newassigned

Mark, all of these LiveTV "frame buffering failed" bugs seem to shame VDPAU in common. Assigning to you for lack of anyone better.

comment:4 Changed 9 years ago by John.D.Nourse@…

The following is an excerpt from what I wrote in the closed report .. I hae a few more comments at the end and I feel that they are really relevant ------------------------------------------------------------------------------------------- HI, my son and I have both MythTV setups with both front and back end UBUNTU boxes, and this problem for us has been occurring with Live TV but only with On Air shows. The message appears on all of our front ends I see the same shudder when the HD on air shows change. I'm not 100% positive but it seems to me I consistently see the issue when during th live show I pause it and then resume. I know this because the error occurs when the show has ended in real time and I am behind and miss the end of the show because I paused it and did not catch up with the live real time show before it ended. Very annoying!!

OK. This has been going on for a long time now probably close to a year but it has been so long I don't actually remember the start date. Our Back end stats show that we have been recording shows on Myth for 1 year and 13 months but I do not remember seeing this initially. If requested I will try to create and provide log files as requested above. My son's setup has high def satellite from Starchoice. This does not seem to have the issue on it's high def. I have however noticed that the On Air High Definition files are huge at least twice the size of the HD files from the Star Choice box. We are both using the HDHomerun box to get the On Air digital signals onto our gigabit home networks and through to MythTV. We both use VDPAU for all the digital processing on all boxes including High Definition .

I hope this helps isolate the issue. I understand that each show either recorded or Live is actually recorded as a separate file. This makes the message relevant if there is some problem concluding writing and closing the Live TV recording before being able to start recording the subsequent live show.


New Comments

It seems to me that VDPAU is not really the culprit if the message is really true. There really are frame losses that cannot be recovered. VDPAU must display what it is sent and if frames are omitted then It cannot resync itself if there is not a huge buffer that can be compared to and synced up again. If as was stated earlier the Gigabit ethernet loses the signal then there is nothing to recover. If the recording cannot keep up (the file closed and the new one started up on time ) then this could cause the same issue. Frames not being available for VDPAU to sync to. Perhaps a simple fix would be to just restart the data stream as if a fresh.( instead of erroring out and stopping any video) Since this seems to happen only at the change time for programs and on live TV and in high Def. would it not be a good idea to complete the thread that has concluded and start a new thread. This way the first could finish writing to disk and the new be available for viewing. This means that there would need to be an overlapping recording technique for live TV. This problem does not seem to occur when programs are just recorded and not viewed live. This leads me to believe that the "Gigabit" issue is misleading and not related or the same problem would cut off the recording and I have not seen this happen.

I hope that this helps. Let me know If there is anything I can do to assist.

Regards,

John Nourse

comment:5 Changed 9 years ago by anonymous

Not sure they should have duped the frame buffering fails on the hour bug against this one. Here's what I'm seeing, on the hour, or program change. I'm running 0.24-fixes (27220) installed from the mythbuntu nightly ppa. Using HDHomeRun and vdpau. Separate backend and frontend. Here's what my log shows when the event happened. I'll try and recapture with higher logging.

Backend log:

2010-11-20 09:00:00.455 AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
2010-11-20 09:00:00.473 LoadFromScheduler(): Error, called from backend.
2010-11-20 09:00:00.711 Finished recording Good Morning America: channel 1111
2010-11-20 09:00:01.174 TVRec(9): RingBufferChanged()
2010-11-20 09:00:01.205 Finished recording Good Morning America: channel 1111
2010-11-20 09:00:04.245 RecBase(9:9): GetKeyframePositions(61,9223372036854775807,#3) out of 6
2010-11-20 09:00:06.038 MainServer::ANN Monitor
2010-11-20 09:00:06.045 adding: ubuntu-server as a client (events: 0)
2010-11-20 09:00:06.060 MainServer::ANN Monitor
2010-11-20 09:00:06.064 adding: ubuntu-server as a client (events: 1)
2010-11-20 09:00:25.773 TVRec(9): Changing from WatchingLiveTV to None
2010-11-20 09:00:25.969 Finished recording ABC 11 Eyewitness News at 9AM: channel 1111
2010-11-20 09:00:26.066 MainServer::ANN Playback
2010-11-20 09:00:26.069 adding: myth2 as a client (events: 0)
2010-11-20 09:00:26.077 TVRec(9): Changing from None to WatchingLiveTV
2010-11-20 09:00:26.102 TVRec(9): HW Tuner: 9->9
2010-11-20 09:00:26.119 LoadFromScheduler(): Error, called from backend.
2010-11-20 09:00:26.122 AutoExpire: CalcParams(): Max required Free Space: 3.0 GB w/freq: 14 min
2010-11-20 09:00:26.142 TVRec(9): Changing from WatchingLiveTV to None
2010-11-20 09:00:26.184 Finished recording ABC 11 Eyewitness News at 9AM: channel 1111

Frontend Log:

2010-11-20 09:00:05.741 RingBuf(/mythtv/livetv/1111_20101120090000.mpg): RingBuffer::Reset() nonzero readpos.  toAdjust: 1 readpos: 9964 readAdjust: 1489976892
2010-11-20 09:00:06.618 ALSA, Error: WriteAudio: buffer underrun
2010-11-20 09:00:06.853 Player(0): Waited 100ms for video buffers AAAAAaaALAAAAAAAA
2010-11-20 09:00:06.855 Player(0): Waited 100ms for video buffers AAAAAaaALAAAAAAAA
.
.
.
2010-11-20 09:00:26.702 Player(0): Waited 100ms for video buffers AAAAAaaALAAAAAAAA
2010-11-20 09:00:26.755 Player(0), Error: Waited too long for decoder to fill video buffers. Exiting..
2010-11-20 09:00:27.573 Using protocol version 63
2010-11-20 09:00:27.584 Spawning LiveTV Recorder -- begin
2010-11-20 09:00:27.640 Spawning LiveTV Recorder -- end
2010-11-20 09:00:27.646 We have a playbackURL(/mythtv/livetv/1111_20101120090026.mpg) & cardtype(DUMMY)
2010-11-20 09:00:27.646 We have a RingBuffer
2010-11-20 09:00:27.647 playCtx, Error: Attempting to setup a player, but it already exists.
2010-11-20 09:00:27.647 TV Error: LiveTV not successfully started

comment:6 Changed 9 years ago by anonymous

Forgot to mention, I've run into this for several releases now. At least since 0.22

comment:7 Changed 9 years ago by anonymous

Whilst trying to watch live TV on a Verizon DVR over firewire I also have the same symptoms: "Waited 100ms for video buffers AAAAAaaALAAAAAAAA" and "2010-11-20 09:00:26.755 Player(0), Error: Waited too long for decoder to fill video buffers"

comment:8 Changed 9 years ago by Kenni Lund [kenni a kelu dot dk]

Ticket locked: set

Guys, read the TicketHowTo...please don't spam us, unless you actually have something valuable to add.

comment:9 Changed 9 years ago by tralph

Milestone: unknown0.25
Resolution: Fixed
Status: assignedclosed
Version: unknownTrunk Head

This should have been fixed by recent commits to master. Please open a new ticket for any new problems.

Note: See TracTickets for help on using tickets.