<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Message: 7<br>
Date: Mon, 24 May 2010 15:26:51 -0500<br>
From: Johnny Walker <<a href="mailto:johnnyjboss@gmail.com">johnnyjboss@gmail.com</a>><br>
Subject: Re: [mythtv-users] HDPVR Causing Backend to Hard Freeze<br>
To: Discussion about mythtv <<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>><br>
Message-ID:<br>
<<a href="mailto:AANLkTiksBRmg2sDOdiVrnso0y5WVyCd2NVJwerVgoSIY@mail.gmail.com">AANLkTiksBRmg2sDOdiVrnso0y5WVyCd2NVJwerVgoSIY@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On Mon, May 24, 2010 at 3:16 PM, Jason Sharpe <<a href="mailto:mythtv.list@gmail.com">mythtv.list@gmail.com</a>> wrote:<br>
><br>
>> Date: Mon, 24 May 2010 11:22:37 -0500<br>
>> From: Johnny Walker <<a href="mailto:johnnyjboss@gmail.com">johnnyjboss@gmail.com</a>><br>
>> Subject: Re: [mythtv-users] HDPVR Causing Backend to Hard Freeze<br>
>> To: Discussion about mythtv <<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>><br>
>> Message-ID:<br>
>> <<a href="mailto:AANLkTilPeoGbXxGRBAgfeFd6mhijMrsuzgmb-2LzLiZL@mail.gmail.com">AANLkTilPeoGbXxGRBAgfeFd6mhijMrsuzgmb-2LzLiZL@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset=ISO-8859-1<br>
>><br>
>> On Mon, May 24, 2010 at 11:16 AM, Jason Sharpe <<a href="mailto:mythtv.list@gmail.com">mythtv.list@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> >><br>
>> >> Message: 18<br>
>> >> Date: Mon, 24 May 2010 11:36:17 -0400<br>
>> >> From: Greg <<a href="mailto:greg12866@nycap.rr.com">greg12866@nycap.rr.com</a>><br>
>> >> Subject: Re: [mythtv-users] HDPVR Causing Backend to Hard Freeze<br>
>> >> To: Discussion about mythtv <<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>><br>
>> >> Message-ID: <<a href="mailto:4BFA9CF1.5040204@nycap.rr.com">4BFA9CF1.5040204@nycap.rr.com</a>><br>
>> >> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
>> >><br>
>> >> On 05/24/2010 09:47 AM, Jason Sharpe wrote:<br>
>> >> ><br>
>> >> > Date: Sun, 23 May 2010 23:43:35 -0500<br>
>> >> > From: <<a href="mailto:mythtv.list@gmail.com">mythtv.list@gmail.com</a> <mailto:<a href="mailto:mythtv.list@gmail.com">mythtv.list@gmail.com</a>>><br>
>> >> > Subject: [mythtv-users] HDPVR Causing Backend to Hard Freeze<br>
>> >> > To: <a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a> <mailto:<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a>><br>
>> >> > Message-ID:<br>
>> >> > <<a href="mailto:AANLkTik9Zpyq8ZGeHXcEEKNrF8ZOXOqSYFqqVJguPivq@mail.gmail.com">AANLkTik9Zpyq8ZGeHXcEEKNrF8ZOXOqSYFqqVJguPivq@mail.gmail.com</a><br>
>> >> ><br>
>> >> ><br>
>> >> > <mailto:<a href="mailto:AANLkTik9Zpyq8ZGeHXcEEKNrF8ZOXOqSYFqqVJguPivq@mail.gmail.com">AANLkTik9Zpyq8ZGeHXcEEKNrF8ZOXOqSYFqqVJguPivq@mail.gmail.com</a>>><br>
>> >> > Content-Type: text/plain; charset="iso-8859-1"<br>
>> >> ><br>
>> >> > Hello,<br>
>> >> ><br>
>> >> > I have been fighting this issue for a days now and I wanted to<br>
>> >> > throw this<br>
>> >> > out there to see if anyone else has seen/heard of anything like<br>
>> >> > this. I can<br>
>> >> > recreate the issue over and over but I am not sure what is<br>
>> >> > causing<br>
>> >> > it.<br>
>> >> ><br>
>> >> > When one recording is ending on a tuner and another is beginning<br>
>> >> > on my HDPVR<br>
>> >> > my whole backend hard freezes requiring a push of the reset<br>
>> >> > button<br>
>> >> > for the<br>
>> >> > PC to come back up.<br>
>> >> ><br>
>> >> > In Other Words:<br>
>> >> > Tuner 1: HD Homerun Records from 09:00 - 10:00<br>
>> >> > Tuner 2: HDPVR Has a show starting at 10:00<br>
>> >> ><br>
>> >> > At 09:59 when the backend should start recording from the HDPVR<br>
>> >> > the backend<br>
>> >> > hard freezes.<br>
>> >> ><br>
>> >> > Using that example above, if the HDPVR starts to record at 09:30<br>
>> >> > everything<br>
>> >> > is fine. It is only when 1 show is ending and another is<br>
>> >> > beginning<br>
>> >> > on the<br>
>> >> > HDPVR.<br>
>> >> ><br>
>> >> > I can record from each tuner just fine for multiple shows back to<br>
>> >> > back on<br>
>> >> > the same tuner without issue, so the tuners work.<br>
>> >> ><br>
>> >> > Here is the strange thing, the other way around, there is no<br>
>> >> > freezing.<br>
>> >> ><br>
>> >> > Meaning:<br>
>> >> > Tuner 1: HDPVR Records from 09:00 - 10:00<br>
>> >> > Tuner 2: HD Homerun Has a show starting at 10:00<br>
>> >> ><br>
>> >> > In that senerio, everything works just fine.<br>
>> >> ><br>
>> >> > I have elimitated the HD Homerun as the source of the problem by<br>
>> >> > trying a<br>
>> >> > pcHDTV HD-3000 instead, still freezes.<br>
>> >> ><br>
>> >> > Details:<br>
>> >> > HD Homerun using Tuner 0 (Over the Air ATSC)<br>
>> >> > HDPVR and a Dishnetwork ViP 211k receiver (Component and SPDIF)<br>
>> >> ><br>
>> >> > Note: IR blasting is done via a homebrew serial blaster, I am<br>
>> >> > _not_ using<br>
>> >> > the HDPVR for blasting.<br>
>> >> ><br>
>> >> > Both the HD Homerun and the HDPVR are running the latest<br>
>> >> > firmware.<br>
>> >> > I was<br>
>> >> > going to downgrade the firmware in the HDPVR, but I read that the<br>
>> >> > previous<br>
>> >> > version had its own problems.<br>
>> >> ><br>
>> >> > I am running Mythdora 12.23, mythbackend version:<br>
>> >> > tags/release-0-23<br>
>> >> > [0.23-1.md12 (r24509).<br>
>> >> ><br>
>> >> > The backend log isn't much help, since when it freezes it can't<br>
>> >> > write to it,<br>
>> >> > heh (HW Tuner 44 is the HDPVR)<br>
>> >> ><br>
>> >> > 2010-05-23 21:58:00.784 Reschedule requested for id 0.<br>
>> >> > 2010-05-23 21:58:01.977 Scheduled 781 items in 1.2 = 0.01 match +<br>
>> >> > 1.17 place<br>
>> >> > 2010-05-23 21:58:01.991 scheduler: Scheduled items: Scheduled 781<br>
>> >> > items in<br>
>> >> > 1.2 = 0.01 match + 1.17 place<br>
>> >> > 2010-05-23 21:58:29.861 TVRec(44): ASK_RECORDING 44 29 0 0<br>
>> >> > 2010-05-23 21:59:01.227 ProgramInfo(): Updated pathname '':'' -><br>
>> >> > '5389_20100523215900.mpg'<br>
>> >> > 2010-05-23 21:59:01.346 TVRec(44): Changing from None to<br>
>> >> > RecordingOnly<br>
>> >> > 2010-05-23 21:59:01.358 TVRec(44): HW Tuner: 44->44<br>
>> >> > 2010-05-23 21:59:02.471 ret_pid(0) child(11739) status(0x0)<br>
>> >> > 2010-05-23 21:59:03.484 ret_pid(0) child(11739) status(0x0)<br>
>> >> > 2010-05-23 21:59:04.501 ret_pid(0) child(11739) status(0x0)<br>
>> >> > 2010-05-23 21:59:05.519 ret_pid(0) child(11739) status(0x0)<br>
>> >> > 2010-05-23 21:59:06.536 ret_pid(0) child(11739) status(0x0)<br>
>> >> ><br>
>> >> > The next line of the log is the backend starting after I had to<br>
>> >> > push the<br>
>> >> > reset button.<br>
>> >> ><br>
>> >> > I am at my wits end, any ideas?<br>
>> >> ><br>
>> >> > Thanks in advance for any help.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > So I spent some more time working on the issue this morning.<br>
>> >> ><br>
>> >> > I downgraded the firmware of the HDPVR, no change, still hangs as<br>
>> >> > described.<br>
>> >> ><br>
>> >> > I reloaded the newest firmware of the HDPVR into it and changed the<br>
>> >> > USB port it was plugged into making sure it was on a different bus,<br>
>> >> > no<br>
>> >> > change, still hangs as described.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > mythtv-users mailing list<br>
>> >> > <a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
>> >> > <a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
>> >> ><br>
>> >> Most people with this problem add a sleep to their channel changing<br>
>> >> script...Search this list for hdpvr channel script... I would guess<br>
>> >> that<br>
>> >> is your problem also..<br>
>> ><br>
>> ><br>
>> > Thanks for the reply.<br>
>> ><br>
>> > I had read that when I got the HDPVR, so since day 1 with the HDPVR I<br>
>> > have<br>
>> > had a 3 sec sleep at the end of the script. I just checked my script and<br>
>> > confirmed the 3.0 sec sleep at the end.<br>
>> ><br>
>> > Any other ideas?<br>
>> ><br>
>><br>
>> Seeings as you're on Mythdora and I've not used it I was trying to<br>
>> stay out of this thread.<br>
>><br>
>> However I am curious if you run the backend with '-v most' and<br>
>> pastebin the logs and post the link back here if we'd see something<br>
>> more meaningful.<br>
>><br>
>> Also is .23-release in your version number indicative that you're NOT<br>
>> following the fixes branch? Someone with more experience with a fedora<br>
>> based OS might want to suggest how to get the fixes branch on your<br>
>> box.<br>
>><br>
>> -Johnny<br>
>><br>
><br>
> Thanks all to who are replying, I have been troubleshooting all morning.<br>
><br>
> I updated the kernel hoping it would become more stable, it now is. I am<br>
> running kernel.i686 0:2.6.32.12-115.fc12.<br>
><br>
> Now the backend computer doesn't freeze when I have the problem, so it does<br>
> provide more logging. (A side note: it doesn't hang however I lose network<br>
> connectivity when this happens, a reboot brings the network back)<br>
><br>
> I am NOT running the fixes branch of mythtv.<br>
><br>
> Checking the system log messages, I get this EVERY time the IR Blaster is<br>
> accessed, either on backend startup, manually sending commands, or normal<br>
> recordings:<br>
><br>
> May 24 13:40:48 localhost lircd-0.8.6[1780]: accepted new client on<br>
> /dev/lircd1<br>
> May 24 13:40:48 localhost lircd-0.8.6[1780]: removed client<br>
> May 24 13:40:48 localhost lircd-0.8.6[1780]: buffer too small<br>
> May 24 13:40:49 localhost lircd-0.8.6[1780]: accepted new client on<br>
> /dev/lircd1<br>
> May 24 13:40:49 localhost lircd-0.8.6[1780]: removed client<br>
> May 24 13:40:49 localhost lircd-0.8.6[1780]: buffer too small<br>
> May 24 13:40:49 localhost lircd-0.8.6[1780]: accepted new client on<br>
> /dev/lircd1<br>
> May 24 13:40:50 localhost lircd-0.8.6[1780]: removed client<br>
> May 24 13:40:50 localhost lircd-0.8.6[1780]: buffer too small<br>
><br>
> running:<br>
><br>
> [root@mythtv storage] mythbackend -v most > crash.log<br>
> irsend: timeout<br>
> irsend: timeout<br>
> irsend: timeout<br>
> irsend: timeout<br>
><br>
><br>
> The timeouts don't appear when the backend starts, they show up when the<br>
> script runs to change the channel when another tuner is running.<br>
> Note: If no other tuner is recording, I can record from the HDPVR without<br>
> issue, that is the confusing part.<br>
><br>
> You can view the crash.log at: <a href="http://pastebin.com/mMWVbrjn" target="_blank">http://pastebin.com/mMWVbrjn</a><br>
><br>
> HW Tuner 44 is the HDPVR<br>
> The recording starts on line 4081<br>
> When this recording starts I am recording something on the HD Homerun<br>
><br>
> My Channel Change Script is:<br>
><br>
> #!/bin/bash<br>
> PATH=/bin:/usr/bin:/usr/sbin<br>
><br>
> REMOTE=dish<br>
> irsend --device=/dev/lircd1 SEND_START $REMOTE SELECT<br>
> sleep 4.0<br>
> for digit in `echo $1 | sed 's/\(.\)/\1 \n/g'` ; do<br>
> irsend --device=/dev/lircd1 SEND_START $REMOTE $digit<br>
> sleep 0.2<br>
> done<br>
><br>
> irsend --device=/dev/lircd1 SEND_START $REMOTE SELECT<br>
> sleep 0.2<br>
> irsend --device=/dev/lircd1 SEND_START $REMOTE CANCEL<br>
> sleep 3.0<br>
><br>
><br>
><br>
> The first select is to wake up the receiver if it is asleep, the last cancel<br>
> is to get rid of the OSD from the receiver<br>
><br>
> Thanks again, I would glady by someone a cold case of beer if they have the<br>
> answer..:)<br>
><br>
<br>
as a troubleshooting idea - if you change your channel change command<br>
to "/bin/true" and make sure the cable box is already providing signal<br>
does the problem go away?<br>
<br>
<br></blockquote><div><br>I followed your idea and changed the channel change script in mythtvsetup to /bin/true and YES the problem did go away I recorded on both tuners about 20 times switching back and forth between tuners and it didn't freeze once. It ALWAYS hung on the first time so I think it is safe to say that the problem did go away using /bin/true.<br>
<br>So with the irsend time outs and the other clues, I think it does have something with the way I am blasting.<br></div></div><br>