[mythtv-users] System crashes on start of DVB-S recording

[Jelte Veldstra]

Thanks for your quick reply. The happysat forum was tried as well, but no
clues there to a solution.



On Sun, Feb 8, 2009 at 7:26 PM, OCG Technical Support <support at ocg.ca>wrote:

>  You'll likely get some negative feedback – sasc-ng is a "no no" on this
> list...
>
>
>
> Have you asked on the happysat forum?  A new ECM or code will lock
> sasc-ng.  While this shouldn't lock the system, it can cause the backend to
> freeze.
>
>
>
> *From:* mythtv-users-bounces at mythtv.org [mailto:
> mythtv-users-bounces at mythtv.org] *On Behalf Of *Jelte Veldstra
> *Sent:* February 8, 2009 1:17 PM
> *To:* Myth TV Users List
> *Subject:* [mythtv-users] System crashes on start of DVB-S recording
>
>
>
> This issue really drives me mad and I was wondering if others have
> experienced the same.
>
> I have built a dedicated backend based on CentOS 5 (with DVB support from
> centos.plus kernels) and MythTV 0.21-fixes. It is currently fitted with two
> Hauppauge Nova-S (budget) DVB-S adapters. Encrypted channels are decrypted
> using open-sasc-ng and a subscription card in a phoenix smartcard reader.
>
> This setup works quite well but every now and then (~ 1 in 100 recordings)
> I have this setup hardlocking on me as a recording is started. After
> restarting the system and looking into the logfiles there is nothing that
> hints what happened that made it crash. It looks as if the power plug was
> pulled as syslog shows nothing on the Linux level. The backend log only
> shows the line that indicates a recording is started and nothing since. The
> sasc-ng log shows no attempt of the backend connecting to it for this
> recording. The system has had its share of stress tests to rule out memory,
> power or overheating problems and has shown no such issues.
>
> As MythTV and sasc-ng run as non-privileged users it seems like something
> is going on on kernel and driver level. This thought is enforced as it only
> seems to happen with stv0299 based adapters (such as the Nova-S). Having
> used a single Twinhan 1030A DVB-S adapter (dvb-bt8xx based) for a while
> never failed on me. And when I mixed both types (I really want a twin-tuner
> system) it would occasionally crash on the Nova-S but never on the Twinhan.
>
> So somehow it seems related to the hardware, but as I tried three different
> stv0299 based tuners, it's not a faulty adapter is seems but rather a driver
> issue. If I could find a second 1030A then I would try that for sure, but I
> havent been able to find one, plus I'd really like to understand what's
> going on here. Searching linuxtv.org mail archives doesn't provide answers
> on that.
>
> Googling for it revealed some possible hints. One suggestion was that it
> could be multirec in combination with open-sasc-ng. Others have found that
> multirec not being 100% working with open-sasc-ng but had no crashes. To
> rule is out I have disabled multirec, but still have had crashes. Another
> suggestion was that a race condition could arrise between software RAID5
> code and the DVB subsystem (would explain why there are no kernel messages
> during or after the crash). As I used soft RAID5 I have since removed that
> configuration from my setup, but still no luck.
>
> So I have spent quite some time googling and trying out what I found there,
> but no luck yet. I'm runnning out of ideas and wondered if other MythTV
> users have had similar issues or found a pattern. So far I cannot reproduce
> it and the only pattern so far is that it only happens at the start of a
> recording (never during or outside recordings) and on stv0299 based
> adapters.
>
> If you recognise this or have any pointers for me to try, please share.
>
> Thanks in advance,
>
>
> Jelte
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090208/1e35e8a4/attachment.htm>