I am having an issue where i get in dmesg;

This happens when I have multiple tuners scheduled (2 or 3) to start simultaneously. The shows video is pixelated and drops ot for ~5 seconds and then it works fine.

I found http://svn.mythtv.org/trac/ticket/1660 that talks about a patch to be applied. If I download the source I can apply the patch. Are there additional "KnoppMyth" modifications (patches/diffs) I should consider before .configure && make && make install? Will doing this likely cause any harm?

I am running R5E50 with a PVR-500 and a PVR-150.

There is a "compile from svn" page on the wiki which has most of the info you're looking for, search for "svn" and it should come up near the top of the list. WattoToydarian also put together a script which automates most of it which is posted around here, search for "compile mythtv from svn script" and don't forget to click the "search for all terms" button.

sg-

I have the same issue. If you document the full process, including the patch, and post it here, I'd appreciate it. Sounds like the patch won't be in mythtv proper till the next release.

-brendan

I wanted to update all compponents to the latest fixes when I did this so...
I used ssh as root for all of this except the install (as mythtv) I had read there were issues. I did it last night. I will let you know if I see any more errors. Best of luck.

Credit goes where credit is due. I used the WattoToydarian script as a model. http://mysettopbox.tv/phpBB2/viewtopic. ... hlight=svn



Update #1
Mythweb gets a little messed up... I need to track it down (just a page display issue) but it should be no big deal. I will update when I get it.

Update #2
To fix mythweb run;


-sg

Looks like the patch does not work.

I have a lot less instances but the buffer full messages still pop up.

Anyone else seen this?

Hmm, how about also increasing the ivtv buffers, e.g.:

Add to the /etc/mythtv/modules/ivtv file :



-brendan

I added it then, then

Time will tell.

I did not have any errors at all today. So I think the patch helped a lot but we will see if this makes it go away fully. I appreciate the input. I had been trying but it was crashing on boot... I noticed in the it does specify the defaults but not the max mins. Maybe I was using too much memory in my option line.

Is the update-modules call necessary? The man page says it is obsolete, but calls /sbin/update-modules.modutils if it exists, which it does.

But...

I thought that these changes to the options were picked up automatically, as evidenced by my own typos in the file preventing ivtv from loading in the past.

Let me know if the patch, the module options or both seem to be required to get it working without bits of lost mpeg stream.

-brendan

So far with both the errors and pixelation have gone away. I will update again tomorrow.

The Mythtv Setup CARDS screen no longer allows us to set the VBI options, while the backend apparently resets the VBI options on a regular basis, overriding any v4l2-ctl passed vbi changes I make.

However, the Setup GENERAL screen (first one) allows us to set Closed Captioning to None (not the default), which does the trick. Mythtv 0.20 knows a little more about the ivtv driver than older versions, so this tells mythtv to notify the ivtv driver that vbi is not needed at all. Stepping back for a moment, I suppose that change to both screens was about being user friendly.

Whether or not this will impact the issue sgunther is working on above, I'm not sure, but I think it might. I'm going from 8% CPU per ivtv-vbi-enc task thread (with 3 cards in my system) to near 0. I'll post whether the larger buffers plus the CC disable also do the trick.

If you need CC, however, this solution won't be very helpful. In the long run, some ivtv and perhaps mythtv fixes, such as the patch above, will be needed.

-brendan

I have VBI on and am getting ~10% per ivtv-enc-vbi.

If when you turn off the VBI you no longer get video errors it may point to CPU loading.

I am wondering if the CPU loading of multiple tuners, MythTV programs, and the mySQL access is the issue. If the loading is the issue then the spike in loading could be mitigated with either turning off VBI or staggering the mySQL writes.

I ran a time based trace on mysql as two shows finished and wrote their metadata to the database...

(Note: I pad 90 seconds to my shows so that is why it stopped at 1:30 after 00)

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND TIME
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:03.79 mysqld 22:01:30
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:03.79 mysqld 22:01:30
2871 mysql 0 0 128m 19m 2256 S 5.9 4.1 6:03.82 mysqld 22:01:31
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:03.82 mysqld 22:01:31
2871 mysql 0 0 128m 19m 2256 S 23.7 4.1 6:03.94 mysqld 22:01:32
2871 mysql 0 0 128m 19m 2256 S 11.9 4.1 6:04.00 mysqld 22:01:32
2871 mysql 0 0 128m 19m 2256 S 19.8 4.1 6:04.10 mysqld 22:01:33
2871 mysql 0 0 128m 19m 2256 S 33.5 4.1 6:04.27 mysqld 22:01:33
2871 mysql 0 0 128m 19m 2256 S 43.5 4.1 6:04.49 mysqld 22:01:34
2871 mysql 0 0 128m 19m 2256 S 35.6 4.1 6:04.67 mysqld 22:01:34
2871 mysql 0 0 128m 19m 2256 S 53.6 4.1 6:04.94 mysqld 22:01:35
2871 mysql 0 0 128m 19m 2256 S 85.7 4.1 6:05.37 mysqld 22:01:35
2871 mysql 0 0 128m 19m 2256 S 81.2 4.1 6:05.78 mysqld 22:01:36
2871 mysql 0 0 128m 19m 2256 S 65.1 4.1 6:06.11 mysqld 22:01:36
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:06.11 mysqld 22:01:37
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:06.11 mysqld 22:01:37
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:06.11 mysqld 22:01:38
2871 mysql 0 0 128m 19m 2256 S 0.0 4.1 6:06.11 mysqld 22:01:38

I was suprised to see it peak at 86%!

I had to remove the changes to ivtv buffers. I was getting out of memory errors. So I will see how the patch alone does over the next few days.

Hans indicated we should be seeing 0.5 to 1.0 seconds of video per MB of buffer space. In the case of 16MB for each MPG buffer, that should be 8 to 16 seconds, but for the default 4MB, that's just 2 to 4 seconds.

Do you think your four second (22:01:32 to 22:01:36) mysql snapshot was from a single call into the database? If so, and without the patch, if the reads had been pending on a single call with that profile (in your case, it was after the recording ended, I know), then that would have caused the loss of buffered data, right?

If you could, perhaps, profile mysql during recording and see if you can identify any large stretches of mysql activity not correlated to the beginning or end of a recording, that might help to pinpoint.



With CC off (and consequently CPU-sucking VBI encoding off), the buffers increased to 16MB each, my mythcommflag set to nice 19 (by changing the executable settings in setup), but without the mythtv patch, I'm still getting very occassional "fast enough" errors, but now reduced to 0 to 2 per recording, or so. But the problem is waaaay less of an issue than before.

-brendan

First post! I have a question related to mythtv on ubuntu 7.10 (gutsy gibbon). I realize this is a knoppmyth forum, but I think my question is distribution independent.

I have a PVR-150. The quality of my RECORDED tv is great. However, I have noticed that Live TV can be a bit "jerky" (stutter, glitchy -> alternate words for searches). However, if I pause Live TV for 4-5 seconds and then hit play, Live TV plays back as smoothly as a "recorded" show (yes I realize that live tv is recorded too). So, my conclusion is that the ~2 seconds of buffering -- where the cable signal is taken in, converted to mpeg, written to the hard drive, and then played back from the hard drive -- is just not enough when watching live TV.

So, I've been trying to figure out how to increase the buffer of mythtv playback. I tried the suggestion mentioned here. I created the file /etc/modprobe.d/ivtv whose contents is:


My dmesg |grep ivtv output after a reboot is now:


So it appears that the changes "took".

However, I still have the same problem when watching live tv. If I hit the spacebar to "save position", I see that I only have ~2 seconds of buffer. Now, if I pause the recording for 5 seconds or so, and then hit the right arrow key to skip forward 30 seconds (i.e. skip forward as far as possible) and then hit space bar to "save position", I see that I have a 4-5 second buffer! So it appears that the mpg_buffer trick only works if I pause the recording first (which was what I was trying to avoid having to do in the first place).

My question: Is there a setting I need to change somewhere in mythtv so it uses the correct 16 MB mpeg buffer all of the time instead of the default 4 MB buffer?

-teet

teet - these are two different kinds of buffers. The ivtv buffer is a driver buffer and you never want that to fill up, otherwise several seconds tv would be lost and not recorded.

The mythtv "buffer" you describe is more appropriately called a series of buffers and playback positioning steps.

They are completely unrelated.

-brendan