<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I did some further investigating:<br>
<br>
I tried VPDAU Normal and Slim profiles with the same results.<br>
<br>
I tried without VDPAU, using only the CPU and 2xBob (CPU is beefy enough<br>
for that) with the same results.<br>
<br>
Now, it happened 2 times, that the hiccups occurred not only every 2-10<br>
minutes, but every few seconds and on both occasions, mythfrontend tried<br>
to contact mythlcdserver, which had crashed (see my other thread in<br>
mythtv-dev list about that crash)!<br>
<br>
So, if contacting mythlcdserver triggers the hiccup and the message<br>
about dropping frames in the log, it could be something strange inside<br>
mythfrontend and not necessarily with my hardware. And BTW, mplayer<br>
plays flawlessly on the same hardware.<br>
<br>
Anyone any suggestions on how to find the real problem? Could writing to<br>
the log (mythlogserver) be the problem? The log file is on an NFS share,<br>
because this is a PXE (diskless) frontend.<br></blockquote><div><br></div><div>Because the duration between skips is so great, I don't think it's your playback profile. It could be any number of things inside or outside of Mythtv.</div>
<div><br></div><div>Keep in mind that, because you are running a diskless frontend, any disk IO on your frontend could impact playback. Because you have no issues in mplayer, I would look to other things besides just playback that mythtv may be doing. For example, mythtv may access the seek table in the database during playback... if the database is busy updating EIT data or scheduling, you may get a hiccup.</div>
<div><br></div><div style>The fact that it seems to occur more at the ends of recordings, and because it came up in another thread, makes me wonder about disk fragmentation. When starting a recording, a certain amount of disk space is preallocated (not sure how much), and once that block is filled it will allocate another block that may or may not be contiguous. I believe it will typically it will start writing an area with a lot of contiguous blocks free... then once it runs out it starts to write in another location on the disk. Perhaps playback is ok when on the contiguous part of the file, but once it has to start seeking your playback degrades?</div>
</div></div></div>