Opened 10 years ago

Closed 10 years ago

#6583 closed defect (duplicate)

Video frame buffering failed too many times

Reported by: Wayne Gibson <gr8gib@…> Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: MythTV - Video Playback Version: unknown
Severity: low Keywords: Video frame buffering failed too many times
Cc: Ticket locked: no


First of all, I'm not a developer, but I am a hacker:) I've been using MythTV for many years and it is a very good FREE and OPEN SOURCE program. However, I always had some issue with it that I couldn't get past the WAF. Within the past year, I've been downloading the SVN version and trying it on a regular basis(very nice work with QT4). Currently I am using the 20414M trunk version. I have been having an issue with LiveTV channel changing and also when a LiveTV program ends at the top or bottom of the hour. In a totaly random manner(I have not been able to decipher a pattern), when changing channels(not every time), the LiveTV will quit and go back to the main menu and give me a pop up box saying "Video frame buffering failed too many times". This happened to many times for the WAF, so I started trying to hack/fix it. There were a couple of things I noticed in the mythfrontend log when this would happen. The first thing I noticed was the "Prebuffer wait timed out 10 times." message. It would climb to 100 and give me that popup I mentioned earlier. So I figured I would find that message in the code and throw in a hackish system() call to a bash file to reset livetv. The external bash script was just telneting to the frontend(on the same PC as backend) and sending an escape key, wait for 1/10 of a second, then send the jump livetv command. This script was called with the "&" so the rest of the myth code would not wait for a response. This system() call was placed in the NuppelVideoPlayer?.cpp around line 2,714 or there about. With some hackish sleep code in my external bash script, I got this to work. The only problem was I would still get the "Video frame buffering failed too many times" popup message when LiveTV would be shut down, in fact I would get that popup however many times that the external script was run durring that LiveTV session. So if the hack was triggerd 3 times, when I would be finnished watching livetv and go back to the main menu, I would have to hit the "OK" button 3 times for 3 popups. On top of that and the fact that it was very very hackish(even for my standards:) it still took to long to reset(it would have to prebuffer timeout 100 times before the hack was triggered) and when it did get triggered the TV screen would turn an ugly grey untill the LiveTV came back(about 10 seconds). So my next step was to reduce the number of prebuffer tries from 100 to 50 because I noticed on a good channel change or program switch the prebuffer tries would not go above 20. Then I commented out the setting of the error object around line 2,718 in the NuppelVideoPlayer?.cpp. This last step was a mistake because without the error object getting set, the prebuffer tries would just continue forever. So to get past this, I uncommented the set error object code in NuppelVideoPlayer?.cpp that I had just commented out and found where the error was actully being acted on in tv_play.cpp around line 379("if (!nvpError.isEmpty())"). I nested another if statement in there that looked to see if the error was the "Video frame buffering failed too many times" error and if it was, just ignore it. Doing this made the hackish external script work better, but I still was not satisfied. So back to reading logs:). That is when I noticed something else when ever the hack script would be activated. There would be a message in the mythfrontend log saying "Attempting to setup a player, but it already exists.". So I went looking for that error in the code. I found it on line 447 in playercontext.cpp. I also noticed that when ever it would prebuffer 100 times and go back to the main menu, the mythfrontend log would say "We have a playbackURL"blahblahblah" & cardtype mpeg" and "We have a RingBuffer?", but then it would say "LiveTV not successfully started" and just quit. I found that in the playercontext.cpp code, it was checking to see if the SetNVP already existed before trying to create a new one. So I got the bright idea of reseting the setNVP variable at this point. I accomplished this by puting another "if (!ok)" block in tv_play somewhere around line 1,732. That if block just does a ctx->nvp->StopPlaying?(); and a ctx->SetNVP(NULL); This seems to the key to this whole issue so I will paste the code below.

tv_play.cpp around line 1,732


if (ctx->playingInfo && StartRecorder?(ctx,-1))

if (ctx->playingInfo) {

Cache starting frame rate for this recorder ctx->last_framerate = ctx->recorder->GetFrameRate?();

ok = StartPlayer?(mctx, ctx, desiredNextState);


"Starting Player!!!!!!!!!!!!");



if (!ok) {




if (ctx->playingInfo) not trying to start recorder as it should already be running


ctx->last_framerate = ctx->recorder->GetFrameRate?();

ok = StartPlayer?(mctx, ctx, desiredNextState);


"Starting Player!!!!!!!!!!!!");



if (!ok) {


"LiveTV not successfully started");





system("/home/mythtv/bin/resetlivetv &");


With this code in tv_play.cpp, I removed my hackish system() call, restored nuppelvideoplayer.cpp back to its original state(100 prebuffer tries) and uncommented the "return false" command(returning it back to it's original state) in the playercontext.cpp around line 450 and gave it a try. It worked!!!! So at this point I have a rock solid MythTV .22 box that the WAF has been enjoying for the past week without ANY complaints.

So to recap what I have found and did.

tv_play.cpp: around line 1,732 I added an if(!ok) block to reset the SetNVP variable if needed. Also around line 381 I put in a if block to check if the error is the "Video frame buffer..." error and if it is, just ignore it and put it in the log instead of a popup

playercontext.cpp: essentially nothing was done here as I'm sure I put everything back to it's original state

NuppelVideoPlayer?.cpp: After confirming that it worked with 100 prebuffer tries, I lowered it to 50 tries to catch this condition sooner and it works even faster now.

With these changes to the code, I have not had livetv quit on me unexpectedly for the past 2 weeks(4 straight days with livetv running and no quits, my house can't take another day of the DIY network!!!:) ) and like I said before the WAF has a whole week without calling me at work complaining about the TV:) Sorry about the long winded message but I wanted to make sure I documented everything I did as I have been working on this for quite some time now.

I have not seen any ramifications from using this code in the past 2 weeks. If any of you developers see a potential problem, you can shoot me an email with your problem scenario and I will give it a try if I can. That being said I guess I should mention I'm using A PVR-150. I do have another PVR-150, but I haven't got a chance to stick it in the PC and check to see if this would work with more than 1 tuner card.

I also want to be very very clear here. THIS WAS NOT AND IS NOT A PC OR MYTH CONFIGURATION ISSUE!!! It's not ARTS, it's not pulse audio(neither installed) or even an ALSA CONF ISSUE. It's NOT A MYSQL CONFIGURATION ISSUE. It's NOT A FILESYSTEM ISSUE. I have been trying to get to the bottom of this for quite some time now and have read tons of postings and tried it all. Nothing but this code change has fixed this issue for me. As far as putting this code change in SVN, I don't really care, you can take it or leave it. I know it works for me and will keep the code for myself, just want to try help out you developers and tell you how I got a rock solid MythTV .22 box:)

Thanks, Wayne Gibson

P.S. There was 1 setting that did seem to reduce the frequency of this issue. At the begining of this ordeal I turned off the temporal filter on the PVR-150 card which made it less frequent(I think anyway) but it would still error with the "Video frame buffering...." error and since it gives me a better picture with it turned off, I just left it off. I know the recomendation is to have it turned on and set to 8 if your doing fullscreen(720X480) capture, which I am, but I must be the 1% weird case that gets a better picture with it turned off.

Attachments (1)

patchtvplay (2.6 KB) - added by Wayne Gibson <gr8gib@…> 10 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by satfan39

I have the same problem ( especially problematic with dvb-s2 ). Please post the diff tv_play.cpp file or even the whole tv_play.cpp file, it will be easier to test and implement. I have some problems locating the exact code that need to be modified based on the instructions you gave.

comment:2 Changed 10 years ago by anonymous

Two questions;

(a) ctx->recorder->StopLiveTV();

This lines needs to be commented ? or uncommented ?

(b) To close your if satement don't you need an additional "}" at the end ?

comment:3 Changed 10 years ago by satfan39

please execute from the /trunk/mythtv directory

#svn diff ./libs/libmythtv/tv_play.cpp -r 20414 > patchtvplay

and post the "patchtvplay" file created, it will contain all adaptations that you have made to the tv_play.cpp file ( in comparison with r 20414 )

Changed 10 years ago by Wayne Gibson <gr8gib@…>

Attachment: patchtvplay added

comment:4 Changed 10 years ago by Wayne Gibson <gr8gib@…>

I attached the patch you asked for. For the most part this code is in the HandleStateChange?() function. The ctx->recorder->StopLiveTV(); line was supposed to be commented out(something I tried but didn't work). Yes, there was supposed to be a closing bracket, sorry about that. The patch I attached is alot cleaner now then it would have been because I cleaned up my commented out tries before making this one. I have also now added to my fix because I found that when this code would hit, LiveTV would come back and play just fine, but I was not able to interact with it(e.g. change channels , change volume, etc) until the next successful program switch(usually top or bottom of the hour). So it was like LiveTV was playing but the livetvchain didn't know it was playing. So I added the ctx->UpdateTVChain(); line to my existing code and WOW! It works very well now. LiveTV comes back and continues playing and I can interact with it now. Not only that, but now the problem(whatever it is), is getting caught and fixed much quicker. It doesn't even do the prebuffer pause thing 10 times now. I do see some new error messages in the frontend log that I have not seen before(mostly decoder errors I think) when this happens, but it seems to be able to recover from them. So I hope this helps. I did see that there have been some changesets made that may or may not pertain to this but I have not had the time to try any new revisions yet. I also saw that there was a change to the autoexpire code. I want to mention that at one point I thought that may be my problem. So I ran Myth with the -noautoexpire switch for a few days. That did not help the situation at all and in fact craeted a big mess for me to clean up. But I do agree with the change that was do so as not to hold anything else up while it fires.

Thanks, Wayne Gibson

P.S. The last little chunk of that patch is my own personal hack to turn off the TV after the sleep timer times out, so you can ignore that.

comment:5 Changed 10 years ago by satfan39

I have tested your mod and I confirm that it brings some added value for users that do not want toi restart manually live_tv after a serie of pre buffering error. This patch does not prevent preburing errors themselves but it manages them differently ( much better I think ) thant the current implementaton in trunk.

If a given user experiments occasional preburing errors, you patch will resume the corresponding live tv channel automatically resulting in a better experience for the user ( less disruption ).

Of course if the user selected th option to show the OSD grid every time live tv starts, the user will have to get out of the OSD grid to continue watching the channel.

comment:6 Changed 10 years ago by Stuart Auchterlonie

Cc: Stuart Auchterlonie added

comment:7 Changed 10 years ago by Shane Shrybman

Cc: Stuart Auchterlonie removed
Resolution: duplicate
Severity: mediumlow
Status: newclosed

Closing this as a duplicate of #6605

Feel free to try the patches on #6605 and #6612, hopefully they resolve your issue.

Note: See TracTickets for help on using tickets.