<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 14, 2014 at 3:03 PM, John <span dir="ltr"><<a href="mailto:reidjr@lineone.net" target="_blank">reidjr@lineone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 14/05/14 16:36, Tom Lichti wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><div class="">On Wed, May 14, 2014 at 5:46 AM,
Jean-Yves Avenard <span dir="ltr"><<a href="mailto:jyavenard@gmail.com" target="_blank">jyavenard@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14
May 2014 05:06, John <<a href="mailto:reidjr@lineone.net" target="_blank">reidjr@lineone.net</a>>
wrote:<br>
<br>
> I am intrigued by what the difference is between the
frontend being in the<br>
><br>
> kState_WatchingRecording rather than
kState_WatchingPreRecorded, as I assume<br>
> it is the dBase activity of being in the former state
that causes the issue.<br>
> As the backend shouldnt care if a frontend is
watching somthing its<br>
> recording, nulling out that activity seems to make
sense.<br>
<br>
as far as the FE is concerned, it makes no difference
except that it<br>
will know if it needs to query the database for seek
tables.<br>
<br>
your BE is obviously too busy to properly serve files
while also recording<br>
<br>
</blockquote>
<div><br>
</div>
</div><div>I would have to agree with JYA on this. My setup has 2
HDHR's recording from antenna, an HD-PVR and a PVR-150,
and I found that many recordings were damaged or would
have dropped sections (especially the HDHR recordings,
which led me down the wrong path of thinking it was signal
related), until a few weeks ago I upgraded my backend
hardware (new mobo), and more specifically moved to faster
and dedicated drives. Since I've done that, I have not had
any of the issues that you are having, and that I had
previously.</div>
<div><br>
</div>
<div>Tom</div>
<div><br>
</div>
</div>
</div>
</div><div class="">
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
mythtv-users mailing list
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a>
MythTV Forums: <a href="https://forum.mythtv.org" target="_blank">https://forum.mythtv.org</a>
</pre>
</div></blockquote>
Tom,<br>
Didnt see your reply before I posted my own. I have no problem with
the recordings. They can be watched on any frontend AFTER they have
stopped recording. There is no recording problem as such, just the
remote playback of in progress recordings on an Ion based frontend.<br>
<br></div></blockquote><div><br></div><div>Ah. Slightly different problem, but the cause could be the same. Although your backend can record at a high rate, it may not be able to simultaneous record and stream the recordings. I know on my old backend I had to use a PCI SATA card as the mobo didn't have enough SATA connections, and the drive attached to that card was noticeably slower in throughput than the one directly connected to the mobo (or might have been the reverse, I don't remember), and they were identical drives. I know it's not necessarily cost effective to throw money at the problem, but sometimes that is the solution.</div>
<div><br></div><div>Tom</div></div></div></div>