Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Users

Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point

 

 

MythTV users RSS feed   Index | Next | Previous | View Threaded


sbmythtv at cox

May 5, 2012, 1:25 PM

Post #1 of 14 (2069 views)
Permalink
Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point

Summary of problem:

After I reboot both my master backend and slave backend I schedule recordings (that are currently on) to test my three tuners (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All three tuners record their respective shows and I am able to play back during recording. I delete the shows and try again for a different set of programs on different channels. Once again everything works and I am pleased thinking my kids will be happy with the new Mickey Mouse Clubhouse show that is scheduled to be recorded the next morning.

The following morning I wake up to find that the first show that was scheduled for recording at 2am (Phineas and Ferb) recorded fine although the backend did report a database error (see below). However, the second show (Doc McStuffins at 7:30am) and the third show (Mickey Mouse Club House at 8am) did not record, although they show up in grey on my list of recordings. All three shows were scheduled to use Tuner 1 (PVR-250).

I am puzzled so I sellect three other shows (such as the highly provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for immediate recording. All three appear to be recording. However, when I check Tuner 1 I see that it is not. I stop the recording on Tuner 1 (leaving the others recording) and try LiveTV and receive the following error: "Error opening jump program buffer." The other two tuners are in fact recording. However, I am able to recreate the same issue with any of the tuners. For example, the other night I decided to disable Tuner 1 so that Tuner 2 was the first in line to record. The next morning same problem. I then disabled Tuners 1 and 2, and the same problem occurred with Tuner 3 (on slave backend). They all initially record fine, but fail during a later scheduled recording, usually after successfully recording the first show.

Extended Discussion:

Unfortunately, this started about two weeks ago when I upgraded from 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At first I thought it was a power supply problem because we had been having some power problems in our area and I found my master backend completely off one morning. However, I believe that was a false alarm and now it appears to be a software problem. The system was very stable and recording away happily before the upgrade.

I have noted that other people have been reporting similar problems with their PVRs although the descriptons vary a some and many seem to be focused on LiveTV. We never watch LiveTV, always recorded shows so I know it isn't a problem solely related to LiveTV.

See for exampe:

http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
https://bugs.archlinux.org/task/29627

I did discover that there is a possible fix, but I"m not sure when its going to get into the packages:

https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da14196cedd8c

However, I'm not completely convinced that is the only problem on my system since I can't seem to make it fail on will. It's repeatable in that after a reboot, it will happen (probably overnight).

1. I'm curious if anyone else has had similar issues and was able to fix it without the above mentioned fix (I did try deleting all the tuners and inputs and adding them back in and it did not help).

2. Does anyone think that a setting in my BIOS could be to blame? If so, what should I look for. (I'm doubful, but I did have some power problems...)

3. I may have to revert back to 0.24. Unfortunately it means loosing some of my information since the upgrade. (Since the database got an upgrade as well). Any thoughts?

4. I also wonder if this is caused by a database problem with mythconverg. I say this because the very last show ("Phineas and Ferb") recorded with Tuner 1 caused the following error (although it did record):

2012-05-05 02:14:28.676742 E [2651/3621] RecThread mythdb.cpp:192 (DBError) - DB Error (Resolution insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, type, data) VALUES ( ?, ?, ?, ?, ?);
Bindings were:
:CHANID=1030, :DATA=720, :MARK=26461, :STARTTIME=2012-05-05T02:00:00, :TYPE=30
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '1030-2012-05-05 02:00:00-30-26461' for key 'PRIMARY'

2012-05-05 02:14:28.677277 E [2651/3621] RecThread mythdb.cpp:192 (DBError) - DB Error (Resolution insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, type, data) VALUES ( ?, ?, ?, ?, ?);
Bindings were:
:CHANID=1030, :DATA=480, :MARK=26461, :STARTTIME=2012-05-05T02:00:00, :TYPE=31
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '1030-2012-05-05 02:00:00-31-26461' for key 'PRIMARY'

How do I fix this, assuming its a problem?

5. Thereafter, the next time Tuner 1 tried to record ("Doc McStuffins" and "Mickey Mouse Clubhouse") the following errors were observed:

2012-05-05 07:29:45.119117 I [2651/2661] Scheduler scheduler.cpp:2460 (HandleRecordingStatusChange) - Tuning recording: "Doc McStuffins":"Un-burr-able; Righty-on-Lefty": channel 1030 on cardid 1, sourceid 1
2012-05-05 07:29:45.123460 I [2651/2651] CoreContext scheduler.cpp:635 (UpdateRecStatus) - Updating status for "Doc McStuffins":"Un-burr-able; Righty-on-Lefty" on cardid 1 (Tuning => Recording)
2012-05-05 07:29:45.155409 I [2651/2659] TVRecEvent tv_rec.cpp:3950 (TuningNewRecorder) - TVRec(1): rec->GetPathname(): '/data/recordings/1030_20120505073000.mpg'
2012-05-05 07:29:48.062264 E [2651/3889] DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
2012-05-05 07:29:48.062330 E [2651/3888] RecThread mpegrecorder.cpp:1010 (run) - MPEGRec(/dev/video0): Device error detected
2012-05-05 07:29:52.998076 E [2651/3891] DeviceReadBuffer DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2

6. Finally, I also see the following errors in my mythbackend logs:

2012-05-04 22:25:36.643577 I [2651] ProcessRequest mainserver.cpp:1362 (HandleAnnounce) - adding: MythTV1 as a client (events: 1)
2012-05-04 22:25:43.867922 E [2651/2741] FreeSpaceUpdater playbacksock.cpp:139 (SendReceiveStringList) - PlaybackSock::SendReceiveStringList(): Response too short
2012-05-04 22:25:58.864844 E [2651/2741] FreeSpaceUpdater playbacksock.cpp:139 (SendReceiveStringList) - PlaybackSock::SendReceiveStringList(): Response too short
2012-05-04 22:26:13.854012 E [2651/2741] FreeSpaceUpdater playbacksock.cpp:139 (SendReceiveStringList) - PlaybackSock::SendReceiveStringList(): Response too short

and

2012-05-04 22:23:53.949587 I [2651/2659] TVRecEvent tv_rec.cpp:1014 (HandleStateChange) - TVRec(1): Changing from RecordingOnly to None
2012-05-04 22:23:54.399907 E [2651/2748] DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
2012-05-04 22:23:54.400213 E [2651/2746] RecThread mpegrecorder.cpp:1010 (run) - MPEGRec(/dev/video0): Device error detected
2012-05-04 22:23:56.851670 E [2651/2861] DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error

Any insights, help, suggestions, would be appreciated as I currently have to reboot my system before each important recording in order to have a 50% chance of success.

Thanks!

-Kenan



_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mike at rochestervball

May 8, 2012, 4:44 AM

Post #2 of 14 (1914 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

Quoting Kenan Ezal <sbmythtv [at] cox>:

> Summary of problem:
>
> After I reboot both my master backend and slave backend I schedule
> recordings (that are currently on) to test my three tuners
> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend).
> All three tuners record their respective shows and I am able to play
> back during recording. I delete the shows and try again for a
> different set of programs on different channels. Once again
> everything works and I am pleased thinking my kids will be happy
> with the new Mickey Mouse Clubhouse show that is scheduled to be
> recorded the next morning.
>
> The following morning I wake up to find that the first show that was
> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> although the backend did report a database error (see below).
> However, the second show (Doc McStuffins at 7:30am) and the third
> show (Mickey Mouse Club House at 8am) did not record, although they
> show up in grey on my list of recordings. All three shows were
> scheduled to use Tuner 1 (PVR-250).
>
> I am puzzled so I sellect three other shows (such as the highly
> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> immediate recording. All three appear to be recording. However, when
> I check Tuner 1 I see that it is not. I stop the recording on Tuner
> 1 (leaving the others recording) and try LiveTV and receive the
> following error: "Error opening jump program buffer." The other two
> tuners are in fact recording. However, I am able to recreate the
> same issue with any of the tuners. For example, the other night I
> decided to disable Tuner 1 so that Tuner 2 was the first in line to
> record. The next morning same problem. I then disabled Tuners 1 and
> 2, and the same problem occurred with Tuner 3 (on slave backend).
> They all initially record fine, but fail during a later scheduled
> recording, usually after successfully recording the first show.
>
> Extended Discussion:
>
> Unfortunately, this started about two weeks ago when I upgraded from
> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> first I thought it was a power supply problem because we had been
> having some power problems in our area and I found my master backend
> completely off one morning. However, I believe that was a false
> alarm and now it appears to be a software problem. The system was
> very stable and recording away happily before the upgrade.
>
> I have noted that other people have been reporting similar problems
> with their PVRs although the descriptons vary a some and many seem
> to be focused on LiveTV. We never watch LiveTV, always recorded
> shows so I know it isn't a problem solely related to LiveTV.
>
> See for exampe:
>
> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> https://bugs.archlinux.org/task/29627
>
> I did discover that there is a possible fix, but I"m not sure when
> its going to get into the packages:
>
> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da14196cedd8c
>
> However, I'm not completely convinced that is the only problem on my
> system since I can't seem to make it fail on will. It's repeatable
> in that after a reboot, it will happen (probably overnight).
>
> 1. I'm curious if anyone else has had similar issues and was able to
> fix it without the above mentioned fix (I did try deleting all the
> tuners and inputs and adding them back in and it did not help).
>
> snip

I can add a "me too". Upgraded from 0.24 to 0.25 last night using
Mythbuntu. My PVR-350 now exhibits the same behavior. It will work
once following a reboot. I can watch live tv once, then failure, or
record one show, then failure.

Log;

May 8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent
tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23
0 0

May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to
RecordingOnly

May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1

May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0):
SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0

May 8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler
autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required
Free Space: 2.0 GB w/freq: 15 min

May 8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler
scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording:
"College Football Live": channel 1216 on cardid 1, sourceid 1

May 8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler
scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording:
"College Football Live": channel 1216 on cardid 1, sourceid 1

May 8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent
tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname():
'/mnt/store/d4/video/1216_20120508073000.mpg'

May 8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2

May 8 07:29:53 mythtv-server mythbackend[1930]: E RecThread
mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected

I will dig into this a bit more when I get home from work tonight.
Mike

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

May 8, 2012, 8:36 AM

Post #3 of 14 (1905 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On 05/08/2012 07:44 AM, Michael Harnden wrote:
> Quoting Kenan Ezal:
>
>> Summary of problem:
>>
>> After I reboot both my master backend and slave backend I schedule
>> recordings (that are currently on) to test my three tuners
>> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All
>> three tuners record their respective shows and I am able to play back
>> during recording. I delete the shows and try again for a different
>> set of programs on different channels. Once again everything works
>> and I am pleased thinking my kids will be happy with the new Mickey
>> Mouse Clubhouse show that is scheduled to be recorded the next morning.
>>
>> The following morning I wake up to find that the first show that was
>> scheduled for recording at 2am (Phineas and Ferb) recorded fine
>> although the backend did report a database error (see below).
>> However, the second show (Doc McStuffins at 7:30am) and the third
>> show (Mickey Mouse Club House at 8am) did not record, although they
>> show up in grey on my list of recordings. All three shows were
>> scheduled to use Tuner 1 (PVR-250).
>>
>> I am puzzled so I sellect three other shows (such as the highly
>> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
>> immediate recording. All three appear to be recording. However, when
>> I check Tuner 1 I see that it is not. I stop the recording on Tuner 1
>> (leaving the others recording) and try LiveTV and receive the
>> following error: "Error opening jump program buffer." The other two
>> tuners are in fact recording. However, I am able to recreate the same
>> issue with any of the tuners. For example, the other night I decided
>> to disable Tuner 1 so that Tuner 2 was the first in line to record.
>> The next morning same problem. I then disabled Tuners 1 and 2, and
>> the same problem occurred with Tuner 3 (on slave backend). They all
>> initially record fine, but fail during a later scheduled recording,
>> usually after successfully recording the first show.
>>
>> Extended Discussion:
>>
>> Unfortunately, this started about two weeks ago when I upgraded from
>> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
>> first I thought it was a power supply problem because we had been
>> having some power problems in our area and I found my master backend
>> completely off one morning. However, I believe that was a false alarm
>> and now it appears to be a software problem. The system was very
>> stable and recording away happily before the upgrade.
>>
>> I have noted that other people have been reporting similar problems
>> with their PVRs although the descriptons vary a some and many seem to
>> be focused on LiveTV. We never watch LiveTV, always recorded shows so
>> I know it isn't a problem solely related to LiveTV.
>>
>> See for exampe:
>>
>> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
>> https://bugs.archlinux.org/task/29627
>>
>> I did discover that there is a possible fix, but I"m not sure when
>> its going to get into the packages:
>>
>> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da14196cedd8c
>>
>>
>> However, I'm not completely convinced that is the only problem on my
>> system since I can't seem to make it fail on will. It's repeatable in
>> that after a reboot, it will happen (probably overnight).
>>
>> 1. I'm curious if anyone else has had similar issues and was able to
>> fix it without the above mentioned fix (I did try deleting all the
>> tuners and inputs and adding them back in and it did not help).
>>
>> snip
>
> I can add a "me too". Upgraded from 0.24 to 0.25 last night using
> Mythbuntu. My PVR-350 now exhibits the same behavior. It will work
> once following a reboot. I can watch live tv once, then failure, or
> record one show, then failure.
>
> Log;
>
> May 8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent
> tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23
> 0 0
>
> May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to
> RecordingOnly
>
> May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
>
> May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0):
> SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
>
> May 8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler
> autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required
> Free Space: 2.0 GB w/freq: 15 min
>
> May 8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler
> scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording:
> "College Football Live": channel 1216 on cardid 1, sourceid 1
>
> May 8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler
> scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording:
> "College Football Live": channel 1216 on cardid 1, sourceid 1
>
> May 8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent
> tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname():
> '/mnt/store/d4/video/1216_20120508073000.mpg'
>
> May 8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer
> DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
>
> May 8 07:29:53 mythtv-server mythbackend[1930]: E RecThread
> mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
>
> I will dig into this a bit more when I get home from work tonight.

Did you guys do a "Delete all capture cards" (not "Delete all capture
cards on <hostname>"), then re-create cards and re-connect inputs? (Any
time you change cards or drivers, you should probably do that--and
should definitely do that if you have failures after the upgrade.) It
won't affect Video Sources or channels, so, it's a quick 30-second
process that allows MythTV to configure your cards for the current drivers.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


SBMythTV at cox

May 8, 2012, 10:25 AM

Post #4 of 14 (1915 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On Tue, 2012-05-08 at 11:36 -0400, Michael T. Dean wrote:

> Did you guys do a "Delete all capture cards" (not "Delete all capture
> cards on <hostname>"), then re-create cards and re-connect inputs? (Any
> time you change cards or drivers, you should probably do that--and
> should definitely do that if you have failures after the upgrade.) It
> won't affect Video Sources or channels, so, it's a quick 30-second
> process that allows MythTV to configure your cards for the current drivers.
>
> Mike

Hi Mike,

I did read somewhere that people having problems changing channels with
LiveTV and using PVRs were able to correct their problem as you
suggested. Unfortunately, yes, I have deleted all capture cards (not
just on host) and re-created cards and re-connected inputs. I've done it
several different times adding cards in different orders. I've also
disabled one or more cards hoping to isolate the problem to one card. So
far failure for every case. I think I've ruled out a hardware problem
because all three cards on two machines exhibit the same problem.

-Kenan

> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users


_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mike at rochestervball

May 8, 2012, 1:17 PM

Post #5 of 14 (1902 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > Quoting Kenan Ezal:
> >> Summary of problem:
> >>
> >> After I reboot both my master backend and slave backend I schedule
> >> recordings (that are currently on) to test my three tuners
> >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All
> >> three tuners record their respective shows and I am able to play back
> >> during recording. I delete the shows and try again for a different
> >> set of programs on different channels. Once again everything works
> >> and I am pleased thinking my kids will be happy with the new Mickey
> >> Mouse Clubhouse show that is scheduled to be recorded the next morning.
> >>
> >> The following morning I wake up to find that the first show that was
> >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> >> although the backend did report a database error (see below).
> >> However, the second show (Doc McStuffins at 7:30am) and the third
> >> show (Mickey Mouse Club House at 8am) did not record, although they
> >> show up in grey on my list of recordings. All three shows were
> >> scheduled to use Tuner 1 (PVR-250).
> >>
> >> I am puzzled so I sellect three other shows (such as the highly
> >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> >> immediate recording. All three appear to be recording. However, when
> >> I check Tuner 1 I see that it is not. I stop the recording on Tuner 1
> >> (leaving the others recording) and try LiveTV and receive the
> >> following error: "Error opening jump program buffer." The other two
> >> tuners are in fact recording. However, I am able to recreate the same
> >> issue with any of the tuners. For example, the other night I decided
> >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> >> The next morning same problem. I then disabled Tuners 1 and 2, and
> >> the same problem occurred with Tuner 3 (on slave backend). They all
> >> initially record fine, but fail during a later scheduled recording,
> >> usually after successfully recording the first show.
> >>
> >> Extended Discussion:
> >>
> >> Unfortunately, this started about two weeks ago when I upgraded from
> >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> >> first I thought it was a power supply problem because we had been
> >> having some power problems in our area and I found my master backend
> >> completely off one morning. However, I believe that was a false alarm
> >> and now it appears to be a software problem. The system was very
> >> stable and recording away happily before the upgrade.
> >>
> >> I have noted that other people have been reporting similar problems
> >> with their PVRs although the descriptons vary a some and many seem to
> >> be focused on LiveTV. We never watch LiveTV, always recorded shows so
> >> I know it isn't a problem solely related to LiveTV.
> >>
> >> See for exampe:
> >>
> >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> >> https://bugs.archlinux.org/task/29627
> >>
> >> I did discover that there is a possible fix, but I"m not sure when
> >> its going to get into the packages:
> >>
> >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da1419
> >> 6cedd8c
> >>
> >>
> >> However, I'm not completely convinced that is the only problem on my
> >> system since I can't seem to make it fail on will. It's repeatable in
> >> that after a reboot, it will happen (probably overnight).
> >>
> >> 1. I'm curious if anyone else has had similar issues and was able to
> >> fix it without the above mentioned fix (I did try deleting all the
> >> tuners and inputs and adding them back in and it did not help).
> >>
> >> snip
> >
> > I can add a "me too". Upgraded from 0.24 to 0.25 last night using
> > Mythbuntu. My PVR-350 now exhibits the same behavior. It will work
> > once following a reboot. I can watch live tv once, then failure, or
> > record one show, then failure.
> >
> > Log;
> >
> > May 8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent
> > tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23
> > 0 0
> >
> > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to
> > RecordingOnly
> >
> > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
> >
> > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0):
> > SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> >
> > May 8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler
> > autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required
> > Free Space: 2.0 GB w/freq: 15 min
> >
> > May 8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler
> > scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording:
> > "College Football Live": channel 1216 on cardid 1, sourceid 1
> >
> > May 8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler
> > scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording:
> > "College Football Live": channel 1216 on cardid 1, sourceid 1
> >
> > May 8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent
> > tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname():
> > '/mnt/store/d4/video/1216_20120508073000.mpg'
> >
> > May 8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer
> > DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
> >
> > May 8 07:29:53 mythtv-server mythbackend[1930]: E RecThread
> > mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
> >
> > I will dig into this a bit more when I get home from work tonight.
>
> Did you guys do a "Delete all capture cards" (not "Delete all capture
> cards on <hostname>"), then re-create cards and re-connect inputs? (Any
> time you change cards or drivers, you should probably do that--and
> should definitely do that if you have failures after the upgrade.) It
> won't affect Video Sources or channels, so, it's a quick 30-second
> process that allows MythTV to configure your cards for the current drivers.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
Hi Mike,
I ran "Delete all capture cards" and had the same results (recording failure).
After some more googling, I shut my server down (not just a reboot), waited a
minute or so and restarted. So far I have been able to record 5 separate times
on that tuner. So I think I am good. I'll observe for a couple of days and
report back.

I managed to break live TV in my Delete all cards process, so I am off to
investigate that.
Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


sbmythtv at cox

May 8, 2012, 2:19 PM

Post #6 of 14 (1903 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

---- Michael Harnden <mike [at] rochestervball> wrote:
> On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> > On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > > Quoting Kenan Ezal:
> > >> Summary of problem:
> > >>
> > >> After I reboot both my master backend and slave backend I schedule
> > >> recordings (that are currently on) to test my three tuners
> > >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All
> > >> three tuners record their respective shows and I am able to play back
> > >> during recording. I delete the shows and try again for a different
> > >> set of programs on different channels. Once again everything works
> > >> and I am pleased thinking my kids will be happy with the new Mickey
> > >> Mouse Clubhouse show that is scheduled to be recorded the next morning.
> > >>
> > >> The following morning I wake up to find that the first show that was
> > >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> > >> although the backend did report a database error (see below).
> > >> However, the second show (Doc McStuffins at 7:30am) and the third
> > >> show (Mickey Mouse Club House at 8am) did not record, although they
> > >> show up in grey on my list of recordings. All three shows were
> > >> scheduled to use Tuner 1 (PVR-250).
> > >>
> > >> I am puzzled so I sellect three other shows (such as the highly
> > >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> > >> immediate recording. All three appear to be recording. However, when
> > >> I check Tuner 1 I see that it is not. I stop the recording on Tuner 1
> > >> (leaving the others recording) and try LiveTV and receive the
> > >> following error: "Error opening jump program buffer." The other two
> > >> tuners are in fact recording. However, I am able to recreate the same
> > >> issue with any of the tuners. For example, the other night I decided
> > >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> > >> The next morning same problem. I then disabled Tuners 1 and 2, and
> > >> the same problem occurred with Tuner 3 (on slave backend). They all
> > >> initially record fine, but fail during a later scheduled recording,
> > >> usually after successfully recording the first show.
> > >>
> > >> Extended Discussion:
> > >>
> > >> Unfortunately, this started about two weeks ago when I upgraded from
> > >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> > >> first I thought it was a power supply problem because we had been
> > >> having some power problems in our area and I found my master backend
> > >> completely off one morning. However, I believe that was a false alarm
> > >> and now it appears to be a software problem. The system was very
> > >> stable and recording away happily before the upgrade.
> > >>
> > >> I have noted that other people have been reporting similar problems
> > >> with their PVRs although the descriptons vary a some and many seem to
> > >> be focused on LiveTV. We never watch LiveTV, always recorded shows so
> > >> I know it isn't a problem solely related to LiveTV.
> > >>
> > >> See for exampe:
> > >>
> > >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> > >> https://bugs.archlinux.org/task/29627
> > >>
> > >> I did discover that there is a possible fix, but I"m not sure when
> > >> its going to get into the packages:
> > >>
> > >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da1419
> > >> 6cedd8c
> > >>
> > >>
> > >> However, I'm not completely convinced that is the only problem on my
> > >> system since I can't seem to make it fail on will. It's repeatable in
> > >> that after a reboot, it will happen (probably overnight).
> > >>
> > >> 1. I'm curious if anyone else has had similar issues and was able to
> > >> fix it without the above mentioned fix (I did try deleting all the
> > >> tuners and inputs and adding them back in and it did not help).
> > >>
> > >> snip
> > >
> > > I can add a "me too". Upgraded from 0.24 to 0.25 last night using
> > > Mythbuntu. My PVR-350 now exhibits the same behavior. It will work
> > > once following a reboot. I can watch live tv once, then failure, or
> > > record one show, then failure.
> > >
> > > Log;
> > >
> > > May 8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent
> > > tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23
> > > 0 0
> > >
> > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to
> > > RecordingOnly
> > >
> > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
> > >
> > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0):
> > > SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> > >
> > > May 8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler
> > > autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required
> > > Free Space: 2.0 GB w/freq: 15 min
> > >
> > > May 8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler
> > > scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording:
> > > "College Football Live": channel 1216 on cardid 1, sourceid 1
> > >
> > > May 8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler
> > > scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording:
> > > "College Football Live": channel 1216 on cardid 1, sourceid 1
> > >
> > > May 8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent
> > > tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname():
> > > '/mnt/store/d4/video/1216_20120508073000.mpg'
> > >
> > > May 8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer
> > > DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
> > >
> > > May 8 07:29:53 mythtv-server mythbackend[1930]: E RecThread
> > > mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
> > >
> > > I will dig into this a bit more when I get home from work tonight.
> >
> > Did you guys do a "Delete all capture cards" (not "Delete all capture
> > cards on <hostname>"), then re-create cards and re-connect inputs? (Any
> > time you change cards or drivers, you should probably do that--and
> > should definitely do that if you have failures after the upgrade.) It
> > won't affect Video Sources or channels, so, it's a quick 30-second
> > process that allows MythTV to configure your cards for the current drivers.
> >
> > Mike
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users [at] mythtv
> > http://www.mythtv.org/mailman/listinfo/mythtv-users
> Hi Mike,
> I ran "Delete all capture cards" and had the same results (recording failure).
> After some more googling, I shut my server down (not just a reboot), waited a
> minute or so and restarted. So far I have been able to record 5 separate times
> on that tuner. So I think I am good. I'll observe for a couple of days and
> report back.
>
> I managed to break live TV in my Delete all cards process, so I am off to
> investigate that.
> Mike

Mike,

When you say you were able to record 5 seperate times, do you mean that you manually told
the tuner to to record a show, stopped the recording, and told it to record another show, possibly
on another channel? [Or were these previously scheduled recordings?]

If so, I was able to do the same thing, but after leaving the machine with previously scheduled
programs, the first scheduled program fails to record. For example, after a reboot,
I went into Manage Recordings and selected a currently running program for recording. It would
successfully record. I would stop the recording and go to another channel and do the same thing
with another program. Once again no problem. However, after thinking everything is Ok I would come
back the next morning to find an empty file for a previously scheduled recording using that same tuner.

I was wondering if there is something related to the scheduler going on...?

However, tonight I will try complete shutdown of both machines after I remove my cards from setup. I will
then re-select the cards after starting the machine and see what happens. I may also shutdown after
re-selecting. I'll try anything now...

-Kenan

-Kenan
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mike at rochestervball

May 8, 2012, 3:29 PM

Post #7 of 14 (1904 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On Tuesday, May 08, 2012 05:19:26 PM Kenan Ezal wrote:
> ---- Michael Harnden <mike [at] rochestervball> wrote:
> > On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> > > On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > > > Quoting Kenan Ezal:
> > > >> Summary of problem:
> > > >>
> > > >> After I reboot both my master backend and slave backend I schedule
> > > >> recordings (that are currently on) to test my three tuners
> > > >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend). All
> > > >> three tuners record their respective shows and I am able to play back
> > > >> during recording. I delete the shows and try again for a different
> > > >> set of programs on different channels. Once again everything works
> > > >> and I am pleased thinking my kids will be happy with the new Mickey
> > > >> Mouse Clubhouse show that is scheduled to be recorded the next
> > > >> morning.
> > > >>
> > > >> The following morning I wake up to find that the first show that was
> > > >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> > > >> although the backend did report a database error (see below).
> > > >> However, the second show (Doc McStuffins at 7:30am) and the third
> > > >> show (Mickey Mouse Club House at 8am) did not record, although they
> > > >> show up in grey on my list of recordings. All three shows were
> > > >> scheduled to use Tuner 1 (PVR-250).
> > > >>
> > > >> I am puzzled so I sellect three other shows (such as the highly
> > > >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> > > >> immediate recording. All three appear to be recording. However, when
> > > >> I check Tuner 1 I see that it is not. I stop the recording on Tuner 1
> > > >> (leaving the others recording) and try LiveTV and receive the
> > > >> following error: "Error opening jump program buffer." The other two
> > > >> tuners are in fact recording. However, I am able to recreate the same
> > > >> issue with any of the tuners. For example, the other night I decided
> > > >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> > > >> The next morning same problem. I then disabled Tuners 1 and 2, and
> > > >> the same problem occurred with Tuner 3 (on slave backend). They all
> > > >> initially record fine, but fail during a later scheduled recording,
> > > >> usually after successfully recording the first show.
> > > >>
> > > >> Extended Discussion:
> > > >>
> > > >> Unfortunately, this started about two weeks ago when I upgraded from
> > > >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> > > >> first I thought it was a power supply problem because we had been
> > > >> having some power problems in our area and I found my master backend
> > > >> completely off one morning. However, I believe that was a false alarm
> > > >> and now it appears to be a software problem. The system was very
> > > >> stable and recording away happily before the upgrade.
> > > >>
> > > >> I have noted that other people have been reporting similar problems
> > > >> with their PVRs although the descriptons vary a some and many seem to
> > > >> be focused on LiveTV. We never watch LiveTV, always recorded shows so
> > > >> I know it isn't a problem solely related to LiveTV.
> > > >>
> > > >> See for exampe:
> > > >>
> > > >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> > > >> https://bugs.archlinux.org/task/29627
> > > >>
> > > >> I did discover that there is a possible fix, but I"m not sure when
> > > >> its going to get into the packages:
> > > >>
> > > >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7da
> > > >> 1419
> > > >> 6cedd8c
> > > >>
> > > >>
> > > >> However, I'm not completely convinced that is the only problem on my
> > > >> system since I can't seem to make it fail on will. It's repeatable in
> > > >> that after a reboot, it will happen (probably overnight).
> > > >>
> > > >> 1. I'm curious if anyone else has had similar issues and was able to
> > > >> fix it without the above mentioned fix (I did try deleting all the
> > > >> tuners and inputs and adding them back in and it did not help).
> > > >>
> > > >> snip
> > > >
> > > > I can add a "me too". Upgraded from 0.24 to 0.25 last night using
> > > > Mythbuntu. My PVR-350 now exhibits the same behavior. It will work
> > > > once following a reboot. I can watch live tv once, then failure, or
> > > > record one show, then failure.
> > > >
> > > > Log;
> > > >
> > > > May 8 07:29:25 mythtv-server mythbackend[1930]: I TVRecEvent
> > > > tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 23
> > > > 0 0
> > > >
> > > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > > tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to
> > > > RecordingOnly
> > > >
> > > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > > tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
> > > >
> > > > May 8 07:29:49 mythtv-server mythbackend[1930]: I TVRecEvent
> > > > v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0):
> > > > SetInputAndFormat(2, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> > > >
> > > > May 8 07:29:49 mythtv-server mythbackend[1930]: N Scheduler
> > > > autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required
> > > > Free Space: 2.0 GB w/freq: 15 min
> > > >
> > > > May 8 07:29:49 mythtv-server mythbackend[1930]: I Scheduler
> > > > scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording:
> > > > "College Football Live": channel 1216 on cardid 1, sourceid 1
> > > >
> > > > May 8 07:29:50 mythtv-server mythbackend[1930]: I Scheduler
> > > > scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording:
> > > > "College Football Live": channel 1216 on cardid 1, sourceid 1
> > > >
> > > > May 8 07:29:50 mythtv-server mythbackend[1930]: I TVRecEvent
> > > > tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname():
> > > > '/mnt/store/d4/video/1216_20120508073000.mpg'
> > > >
> > > > May 8 07:29:53 mythtv-server mythbackend[1930]: E DeviceReadBuffer
> > > > DeviceReadBuffer.cpp:513 (Poll) DevRdB(/dev/video0): Poll giving up 2
> > > >
> > > > May 8 07:29:53 mythtv-server mythbackend[1930]: E RecThread
> > > > mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error
> > > > detected
> > > >
> > > > I will dig into this a bit more when I get home from work tonight.
> > >
> > > Did you guys do a "Delete all capture cards" (not "Delete all capture
> > > cards on <hostname>"), then re-create cards and re-connect inputs? (Any
> > > time you change cards or drivers, you should probably do that--and
> > > should definitely do that if you have failures after the upgrade.) It
> > > won't affect Video Sources or channels, so, it's a quick 30-second
> > > process that allows MythTV to configure your cards for the current
> > > drivers.
> > >
> > > Mike
> > > _______________________________________________
> > > mythtv-users mailing list
> > > mythtv-users [at] mythtv
> > > http://www.mythtv.org/mailman/listinfo/mythtv-users
> >
> > Hi Mike,
> > I ran "Delete all capture cards" and had the same results (recording
> > failure). After some more googling, I shut my server down (not just a
> > reboot), waited a minute or so and restarted. So far I have been able to
> > record 5 separate times on that tuner. So I think I am good. I'll observe
> > for a couple of days and report back.
> >
> > I managed to break live TV in my Delete all cards process, so I am off to
> > investigate that.
> > Mike
>
> Mike,
>
> When you say you were able to record 5 seperate times, do you mean that you
> manually told the tuner to to record a show, stopped the recording, and
> told it to record another show, possibly on another channel? [Or were these
> previously scheduled recordings?]
>
> If so, I was able to do the same thing, but after leaving the machine with
> previously scheduled programs, the first scheduled program fails to record.
> For example, after a reboot, I went into Manage Recordings and selected a
> currently running program for recording. It would successfully record. I
> would stop the recording and go to another channel and do the same thing
> with another program. Once again no problem. However, after thinking
> everything is Ok I would come back the next morning to find an empty file
> for a previously scheduled recording using that same tuner.
>
> I was wondering if there is something related to the scheduler going on...?
>
> However, tonight I will try complete shutdown of both machines after I
> remove my cards from setup. I will then re-select the cards after starting
> the machine and see what happens. I may also shutdown after re-selecting.
> I'll try anything now...
>
> -Kenan
>
> -Kenan
Hi Kenan,
Now you have me concerned, because that is exactly what I did. Told it to
record a show, stopped it, picked another on a different channel, etc.

I am using a PVR-350 and the interesting thing is that it is only the S-Video
feed into the card that I was having problems with. I have the tuner portion
of the card connected directly to my cable, and the S-Video input I am using
to record from my cable box. The tuner portion has worked fine all along.

I will schedule some shows on the S-Video feed overnight and report back.
Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mike at rochestervball

May 9, 2012, 2:14 AM

Post #8 of 14 (1888 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On Tuesday, May 08, 2012 06:29:04 PM Michael Harnden wrote:
> On Tuesday, May 08, 2012 05:19:26 PM Kenan Ezal wrote:
> > ---- Michael Harnden <mike [at] rochestervball> wrote:
> > > On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> > > > On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > > > > Quoting Kenan Ezal:
> > > > >> Summary of problem:
> > > > >>
> > > > >> After I reboot both my master backend and slave backend I schedule
> > > > >> recordings (that are currently on) to test my three tuners
> > > > >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend).
> > > > >> All
> > > > >> three tuners record their respective shows and I am able to play
> > > > >> back
> > > > >> during recording. I delete the shows and try again for a different
> > > > >> set of programs on different channels. Once again everything works
> > > > >> and I am pleased thinking my kids will be happy with the new Mickey
> > > > >> Mouse Clubhouse show that is scheduled to be recorded the next
> > > > >> morning.
> > > > >>
> > > > >> The following morning I wake up to find that the first show that
> > > > >> was
> > > > >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> > > > >> although the backend did report a database error (see below).
> > > > >> However, the second show (Doc McStuffins at 7:30am) and the third
> > > > >> show (Mickey Mouse Club House at 8am) did not record, although they
> > > > >> show up in grey on my list of recordings. All three shows were
> > > > >> scheduled to use Tuner 1 (PVR-250).
> > > > >>
> > > > >> I am puzzled so I sellect three other shows (such as the highly
> > > > >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> > > > >> immediate recording. All three appear to be recording. However,
> > > > >> when
> > > > >> I check Tuner 1 I see that it is not. I stop the recording on Tuner
> > > > >> 1
> > > > >> (leaving the others recording) and try LiveTV and receive the
> > > > >> following error: "Error opening jump program buffer." The other two
> > > > >> tuners are in fact recording. However, I am able to recreate the
> > > > >> same
> > > > >> issue with any of the tuners. For example, the other night I
> > > > >> decided
> > > > >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> > > > >> The next morning same problem. I then disabled Tuners 1 and 2, and
> > > > >> the same problem occurred with Tuner 3 (on slave backend). They all
> > > > >> initially record fine, but fail during a later scheduled recording,
> > > > >> usually after successfully recording the first show.
> > > > >>
> > > > >> Extended Discussion:
> > > > >>
> > > > >> Unfortunately, this started about two weeks ago when I upgraded
> > > > >> from
> > > > >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> > > > >> first I thought it was a power supply problem because we had been
> > > > >> having some power problems in our area and I found my master
> > > > >> backend
> > > > >> completely off one morning. However, I believe that was a false
> > > > >> alarm
> > > > >> and now it appears to be a software problem. The system was very
> > > > >> stable and recording away happily before the upgrade.
> > > > >>
> > > > >> I have noted that other people have been reporting similar problems
> > > > >> with their PVRs although the descriptons vary a some and many seem
> > > > >> to
> > > > >> be focused on LiveTV. We never watch LiveTV, always recorded shows
> > > > >> so
> > > > >> I know it isn't a problem solely related to LiveTV.
> > > > >>
> > > > >> See for exampe:
> > > > >>
> > > > >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> > > > >> https://bugs.archlinux.org/task/29627
> > > > >>
> > > > >> I did discover that there is a possible fix, but I"m not sure when
> > > > >> its going to get into the packages:
> > > > >>
> > > > >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7
> > > > >> da
> > > > >> 1419
> > > > >> 6cedd8c
> > > > >>
> > > > >>
> > > > >> However, I'm not completely convinced that is the only problem on
> > > > >> my
> > > > >> system since I can't seem to make it fail on will. It's repeatable
> > > > >> in
> > > > >> that after a reboot, it will happen (probably overnight).
> > > > >>
> > > > >> 1. I'm curious if anyone else has had similar issues and was able
> > > > >> to
> > > > >> fix it without the above mentioned fix (I did try deleting all the
> > > > >> tuners and inputs and adding them back in and it did not help).
> > > > >>
> > > > >> snip
> > > > >
> > > > >
> > > > > I will dig into this a bit more when I get home from work tonight.
> > > >
> > > > Did you guys do a "Delete all capture cards" (not "Delete all capture
> > > > cards on <hostname>"), then re-create cards and re-connect inputs?
> > > > (Any
> > > > time you change cards or drivers, you should probably do that--and
> > > > should definitely do that if you have failures after the upgrade.) It
> > > > won't affect Video Sources or channels, so, it's a quick 30-second
> > > > process that allows MythTV to configure your cards for the current
> > > > drivers.
> > > >
> > > > Mike
> > > > _______________________________________________
> > > > mythtv-users mailing list
> > > > mythtv-users [at] mythtv
> > > > http://www.mythtv.org/mailman/listinfo/mythtv-users
> > >
> > > Hi Mike,
> > > I ran "Delete all capture cards" and had the same results (recording
> > > failure). After some more googling, I shut my server down (not just a
> > > reboot), waited a minute or so and restarted. So far I have been able to
> > > record 5 separate times on that tuner. So I think I am good. I'll
> > > observe
> > > for a couple of days and report back.
> > >
> > > I managed to break live TV in my Delete all cards process, so I am off
> > > to
> > > investigate that.
> > > Mike
> >
> > Mike,
> >
> > When you say you were able to record 5 seperate times, do you mean that
> > you
> > manually told the tuner to to record a show, stopped the recording, and
> > told it to record another show, possibly on another channel? [Or were
> > these
> > previously scheduled recordings?]
> >
> > If so, I was able to do the same thing, but after leaving the machine with
> > previously scheduled programs, the first scheduled program fails to
> > record.
> > For example, after a reboot, I went into Manage Recordings and selected a
> > currently running program for recording. It would successfully record. I
> > would stop the recording and go to another channel and do the same thing
> > with another program. Once again no problem. However, after thinking
> > everything is Ok I would come back the next morning to find an empty file
> > for a previously scheduled recording using that same tuner.
> >
> > I was wondering if there is something related to the scheduler going
> > on...?
> >
> > However, tonight I will try complete shutdown of both machines after I
> > remove my cards from setup. I will then re-select the cards after starting
> > the machine and see what happens. I may also shutdown after re-selecting.
> > I'll try anything now...
> >
> > -Kenan
> >
> > -Kenan
>
> Hi Kenan,
> Now you have me concerned, because that is exactly what I did. Told it to
> record a show, stopped it, picked another on a different channel, etc.
>
> I am using a PVR-350 and the interesting thing is that it is only the
> S-Video feed into the card that I was having problems with. I have the
> tuner portion of the card connected directly to my cable, and the S-Video
> input I am using to record from my cable box. The tuner portion has worked
> fine all along.
>
> I will schedule some shows on the S-Video feed overnight and report back.
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Looks like I still have the problem. I was able to record a show at 11:00 pm, then the
card failed at the end of recording.

May 8 22:59:29 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 20 0 0
May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to RecordingOnly
May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
May 8 22:59:50 mythtv-server mythbackend[1950]: N Scheduler autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
May 8 22:59:50 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
May 8 22:59:51 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
May 8 22:59:51 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname(): '/mnt/store/d4/video/1519_20120508230000.mpg'
May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 0)
May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 1)
May 8 23:02:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
May 8 23:04:08 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:09:13 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:14:18 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:17:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
May 8 23:19:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:24:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:29:25 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
May 8 23:30:10 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from RecordingOnly to None
May 8 23:30:11 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
May 8 23:30:11 mythtv-server mythbackend[1950]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
May 8 23:30:13 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
May 8 23:30:13 mythtv-server mythbackend[1950]: I CoreContext scheduler.cpp:634 (UpdateRecStatus) Updating status for Pocoyo on cardid 1 (Recording => Recorded)
May 8 23:30:13 mythtv-server mythbackend[1950]: I TVRecEvent recordinginfo.cpp:1113 (FinishedRecording) Finished recording Pocoyo: channel 1519
May 8 23:30:13 mythtv-server mythbackend[1950]: E CoreContext mainserver.cpp:871 (customEvent) MainServer: PREVIEW_SUCCESS but no receivers.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


sbmythtv at cox

May 9, 2012, 2:48 AM

Post #9 of 14 (1886 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

---- Michael Harnden <mike [at] rochestervball> wrote:
> On Tuesday, May 08, 2012 06:29:04 PM Michael Harnden wrote:
> > On Tuesday, May 08, 2012 05:19:26 PM Kenan Ezal wrote:
> > > ---- Michael Harnden <mike [at] rochestervball> wrote:
> > > > On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> > > > > On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > > > > > Quoting Kenan Ezal:
> > > > > >> Summary of problem:
> > > > > >>
> > > > > >> After I reboot both my master backend and slave backend I schedule
> > > > > >> recordings (that are currently on) to test my three tuners
> > > > > >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend).
> > > > > >> All
> > > > > >> three tuners record their respective shows and I am able to play
> > > > > >> back
> > > > > >> during recording. I delete the shows and try again for a different
> > > > > >> set of programs on different channels. Once again everything works
> > > > > >> and I am pleased thinking my kids will be happy with the new Mickey
> > > > > >> Mouse Clubhouse show that is scheduled to be recorded the next
> > > > > >> morning.
> > > > > >>
> > > > > >> The following morning I wake up to find that the first show that
> > > > > >> was
> > > > > >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> > > > > >> although the backend did report a database error (see below).
> > > > > >> However, the second show (Doc McStuffins at 7:30am) and the third
> > > > > >> show (Mickey Mouse Club House at 8am) did not record, although they
> > > > > >> show up in grey on my list of recordings. All three shows were
> > > > > >> scheduled to use Tuner 1 (PVR-250).
> > > > > >>
> > > > > >> I am puzzled so I sellect three other shows (such as the highly
> > > > > >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> > > > > >> immediate recording. All three appear to be recording. However,
> > > > > >> when
> > > > > >> I check Tuner 1 I see that it is not. I stop the recording on Tuner
> > > > > >> 1
> > > > > >> (leaving the others recording) and try LiveTV and receive the
> > > > > >> following error: "Error opening jump program buffer." The other two
> > > > > >> tuners are in fact recording. However, I am able to recreate the
> > > > > >> same
> > > > > >> issue with any of the tuners. For example, the other night I
> > > > > >> decided
> > > > > >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> > > > > >> The next morning same problem. I then disabled Tuners 1 and 2, and
> > > > > >> the same problem occurred with Tuner 3 (on slave backend). They all
> > > > > >> initially record fine, but fail during a later scheduled recording,
> > > > > >> usually after successfully recording the first show.
> > > > > >>
> > > > > >> Extended Discussion:
> > > > > >>
> > > > > >> Unfortunately, this started about two weeks ago when I upgraded
> > > > > >> from
> > > > > >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> > > > > >> first I thought it was a power supply problem because we had been
> > > > > >> having some power problems in our area and I found my master
> > > > > >> backend
> > > > > >> completely off one morning. However, I believe that was a false
> > > > > >> alarm
> > > > > >> and now it appears to be a software problem. The system was very
> > > > > >> stable and recording away happily before the upgrade.
> > > > > >>
> > > > > >> I have noted that other people have been reporting similar problems
> > > > > >> with their PVRs although the descriptons vary a some and many seem
> > > > > >> to
> > > > > >> be focused on LiveTV. We never watch LiveTV, always recorded shows
> > > > > >> so
> > > > > >> I know it isn't a problem solely related to LiveTV.
> > > > > >>
> > > > > >> See for exampe:
> > > > > >>
> > > > > >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> > > > > >> https://bugs.archlinux.org/task/29627
> > > > > >>
> > > > > >> I did discover that there is a possible fix, but I"m not sure when
> > > > > >> its going to get into the packages:
> > > > > >>
> > > > > >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7
> > > > > >> da
> > > > > >> 1419
> > > > > >> 6cedd8c
> > > > > >>
> > > > > >>
> > > > > >> However, I'm not completely convinced that is the only problem on
> > > > > >> my
> > > > > >> system since I can't seem to make it fail on will. It's repeatable
> > > > > >> in
> > > > > >> that after a reboot, it will happen (probably overnight).
> > > > > >>
> > > > > >> 1. I'm curious if anyone else has had similar issues and was able
> > > > > >> to
> > > > > >> fix it without the above mentioned fix (I did try deleting all the
> > > > > >> tuners and inputs and adding them back in and it did not help).
> > > > > >>
> > > > > >> snip
> > > > > >
> > > > > >
> > > > > > I will dig into this a bit more when I get home from work tonight.
> > > > >
> > > > > Did you guys do a "Delete all capture cards" (not "Delete all capture
> > > > > cards on <hostname>"), then re-create cards and re-connect inputs?
> > > > > (Any
> > > > > time you change cards or drivers, you should probably do that--and
> > > > > should definitely do that if you have failures after the upgrade.) It
> > > > > won't affect Video Sources or channels, so, it's a quick 30-second
> > > > > process that allows MythTV to configure your cards for the current
> > > > > drivers.
> > > > >
> > > > > Mike
> > > > > _______________________________________________
> > > > > mythtv-users mailing list
> > > > > mythtv-users [at] mythtv
> > > > > http://www.mythtv.org/mailman/listinfo/mythtv-users
> > > >
> > > > Hi Mike,
> > > > I ran "Delete all capture cards" and had the same results (recording
> > > > failure). After some more googling, I shut my server down (not just a
> > > > reboot), waited a minute or so and restarted. So far I have been able to
> > > > record 5 separate times on that tuner. So I think I am good. I'll
> > > > observe
> > > > for a couple of days and report back.
> > > >
> > > > I managed to break live TV in my Delete all cards process, so I am off
> > > > to
> > > > investigate that.
> > > > Mike
> > >
> > > Mike,
> > >
> > > When you say you were able to record 5 seperate times, do you mean that
> > > you
> > > manually told the tuner to to record a show, stopped the recording, and
> > > told it to record another show, possibly on another channel? [.Or were
> > > these
> > > previously scheduled recordings?]
> > >
> > > If so, I was able to do the same thing, but after leaving the machine with
> > > previously scheduled programs, the first scheduled program fails to
> > > record.
> > > For example, after a reboot, I went into Manage Recordings and selected a
> > > currently running program for recording. It would successfully record. I
> > > would stop the recording and go to another channel and do the same thing
> > > with another program. Once again no problem. However, after thinking
> > > everything is Ok I would come back the next morning to find an empty file
> > > for a previously scheduled recording using that same tuner.
> > >
> > > I was wondering if there is something related to the scheduler going
> > > on...?
> > >
> > > However, tonight I will try complete shutdown of both machines after I
> > > remove my cards from setup. I will then re-select the cards after starting
> > > the machine and see what happens. I may also shutdown after re-selecting.
> > > I'll try anything now...
> > >
> > > -Kenan
> > >
> > > -Kenan
> >
> > Hi Kenan,
> > Now you have me concerned, because that is exactly what I did. Told it to
> > record a show, stopped it, picked another on a different channel, etc.
> >
> > I am using a PVR-350 and the interesting thing is that it is only the
> > S-Video feed into the card that I was having problems with. I have the
> > tuner portion of the card connected directly to my cable, and the S-Video
> > input I am using to record from my cable box. The tuner portion has worked
> > fine all along.
> >
> > I will schedule some shows on the S-Video feed overnight and report back.
> > Mike
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users [at] mythtv
> > http://www.mythtv.org/mailman/listinfo/mythtv-users
>
> Looks like I still have the problem. I was able to record a show at 11:00 pm, then the
> card failed at the end of recording.
>
> May 8 22:59:29 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 20 0 0
> May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to RecordingOnly
> May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
> May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> May 8 22:59:50 mythtv-server mythbackend[1950]: N Scheduler autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> May 8 22:59:50 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
> May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
> May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
> May 8 22:59:51 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
> May 8 22:59:51 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname(): '/mnt/store/d4/video/1519_20120508230000.mpg'
> May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
> May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 0)
> May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
> May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 1)
> May 8 23:02:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> May 8 23:04:08 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:09:13 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:14:18 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:17:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> May 8 23:19:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:24:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:29:25 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> May 8 23:30:10 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from RecordingOnly to None
> May 8 23:30:11 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
> May 8 23:30:11 mythtv-server mythbackend[1950]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
> May 8 23:30:13 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
> May 8 23:30:13 mythtv-server mythbackend[1950]: I CoreContext scheduler.cpp:634 (UpdateRecStatus) Updating status for Pocoyo on cardid 1 (Recording => Recorded)
> May 8 23:30:13 mythtv-server mythbackend[1950]: I TVRecEvent recordinginfo.cpp:1113 (FinishedRecording) Finished recording Pocoyo: channel 1519
> May 8 23:30:13 mythtv-server mythbackend[1950]: E CoreContext mainserver.cpp:871 (customEvent) MainServer: PREVIEW_SUCCESS but no receivers.

Darn. I was hoping your shutdown suggestion would work. I went home tonight and did exactly that.

However, in your earlier message you stated that you were not having the same problem with your
tuner, only your S-Video feed. That is different from my experience because I'm having the problem
with my tuner. I don't use my S-Video feed.

I'm convinced that there is a software problem, but because of how we are able to record
on-demand, but not on-schedule, I think the problem has to do with the scheduler state and
the PVR command requirements. The fact that your system is working with the tuner but not
S-Video also seems to imply that the problem isn't tuner-related exactly.

I may submit a bug report but I want to comb through my now volumous logs to see if I can
spot a trend.

Unfortunately my wife is getting a little worried that we won't be recording the end of the
season episodes of her favorite shows... so the clock is ticking and I may have to revert
to 0.24.

-Kenan
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


SBMythTV at cox

May 28, 2012, 12:05 AM

Post #10 of 14 (1801 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On Wed, 2012-05-09 at 05:48 -0400, Kenan Ezal wrote:
> ---- Michael Harnden <mike [at] rochestervball> wrote:
> > On Tuesday, May 08, 2012 06:29:04 PM Michael Harnden wrote:
> > > On Tuesday, May 08, 2012 05:19:26 PM Kenan Ezal wrote:
> > > > ---- Michael Harnden <mike [at] rochestervball> wrote:
> > > > > On Tuesday, May 08, 2012 11:36:35 AM Michael T. Dean wrote:
> > > > > > On 05/08/2012 07:44 AM, Michael Harnden wrote:
> > > > > > > Quoting Kenan Ezal:
> > > > > > >> Summary of problem:
> > > > > > >>
> > > > > > >> After I reboot both my master backend and slave backend I schedule
> > > > > > >> recordings (that are currently on) to test my three tuners
> > > > > > >> (PVR-250/PVR-150 on master backend and PVR-350 on slave backend).
> > > > > > >> All
> > > > > > >> three tuners record their respective shows and I am able to play
> > > > > > >> back
> > > > > > >> during recording. I delete the shows and try again for a different
> > > > > > >> set of programs on different channels. Once again everything works
> > > > > > >> and I am pleased thinking my kids will be happy with the new Mickey
> > > > > > >> Mouse Clubhouse show that is scheduled to be recorded the next
> > > > > > >> morning.
> > > > > > >>
> > > > > > >> The following morning I wake up to find that the first show that
> > > > > > >> was
> > > > > > >> scheduled for recording at 2am (Phineas and Ferb) recorded fine
> > > > > > >> although the backend did report a database error (see below).
> > > > > > >> However, the second show (Doc McStuffins at 7:30am) and the third
> > > > > > >> show (Mickey Mouse Club House at 8am) did not record, although they
> > > > > > >> show up in grey on my list of recordings. All three shows were
> > > > > > >> scheduled to use Tuner 1 (PVR-250).
> > > > > > >>
> > > > > > >> I am puzzled so I sellect three other shows (such as the highly
> > > > > > >> provocative "Inside Edition: Butt Girl" and "Brazil Butt Lift") for
> > > > > > >> immediate recording. All three appear to be recording. However,
> > > > > > >> when
> > > > > > >> I check Tuner 1 I see that it is not. I stop the recording on Tuner
> > > > > > >> 1
> > > > > > >> (leaving the others recording) and try LiveTV and receive the
> > > > > > >> following error: "Error opening jump program buffer." The other two
> > > > > > >> tuners are in fact recording. However, I am able to recreate the
> > > > > > >> same
> > > > > > >> issue with any of the tuners. For example, the other night I
> > > > > > >> decided
> > > > > > >> to disable Tuner 1 so that Tuner 2 was the first in line to record.
> > > > > > >> The next morning same problem. I then disabled Tuners 1 and 2, and
> > > > > > >> the same problem occurred with Tuner 3 (on slave backend). They all
> > > > > > >> initially record fine, but fail during a later scheduled recording,
> > > > > > >> usually after successfully recording the first show.
> > > > > > >>
> > > > > > >> Extended Discussion:
> > > > > > >>
> > > > > > >> Unfortunately, this started about two weeks ago when I upgraded
> > > > > > >> from
> > > > > > >> 0.24 to 0.25 on Fedora 16. I use ATrpms to access the packages. At
> > > > > > >> first I thought it was a power supply problem because we had been
> > > > > > >> having some power problems in our area and I found my master
> > > > > > >> backend
> > > > > > >> completely off one morning. However, I believe that was a false
> > > > > > >> alarm
> > > > > > >> and now it appears to be a software problem. The system was very
> > > > > > >> stable and recording away happily before the upgrade.
> > > > > > >>
> > > > > > >> I have noted that other people have been reporting similar problems
> > > > > > >> with their PVRs although the descriptons vary a some and many seem
> > > > > > >> to
> > > > > > >> be focused on LiveTV. We never watch LiveTV, always recorded shows
> > > > > > >> so
> > > > > > >> I know it isn't a problem solely related to LiveTV.
> > > > > > >>
> > > > > > >> See for exampe:
> > > > > > >>
> > > > > > >> http://www.mythtv.org/pipermail/mythtv-users/2012-May/333121.html
> > > > > > >> https://bugs.archlinux.org/task/29627
> > > > > > >>
> > > > > > >> I did discover that there is a possible fix, but I"m not sure when
> > > > > > >> its going to get into the packages:
> > > > > > >>
> > > > > > >> https://github.com/MythTV/mythtv/commit/f81f712537b63502814d1f274c7
> > > > > > >> da
> > > > > > >> 1419
> > > > > > >> 6cedd8c
> > > > > > >>
> > > > > > >>
> > > > > > >> However, I'm not completely convinced that is the only problem on
> > > > > > >> my
> > > > > > >> system since I can't seem to make it fail on will. It's repeatable
> > > > > > >> in
> > > > > > >> that after a reboot, it will happen (probably overnight).
> > > > > > >>
> > > > > > >> 1. I'm curious if anyone else has had similar issues and was able
> > > > > > >> to
> > > > > > >> fix it without the above mentioned fix (I did try deleting all the
> > > > > > >> tuners and inputs and adding them back in and it did not help).
> > > > > > >>
> > > > > > >> snip
> > > > > > >
> > > > > > >
> > > > > > > I will dig into this a bit more when I get home from work tonight.
> > > > > >
> > > > > > Did you guys do a "Delete all capture cards" (not "Delete all capture
> > > > > > cards on <hostname>"), then re-create cards and re-connect inputs?
> > > > > > (Any
> > > > > > time you change cards or drivers, you should probably do that--and
> > > > > > should definitely do that if you have failures after the upgrade.) It
> > > > > > won't affect Video Sources or channels, so, it's a quick 30-second
> > > > > > process that allows MythTV to configure your cards for the current
> > > > > > drivers.
> > > > > >
> > > > > > Mike
> > > > > > _______________________________________________
> > > > > > mythtv-users mailing list
> > > > > > mythtv-users [at] mythtv
> > > > > > http://www.mythtv.org/mailman/listinfo/mythtv-users
> > > > >
> > > > > Hi Mike,
> > > > > I ran "Delete all capture cards" and had the same results (recording
> > > > > failure). After some more googling, I shut my server down (not just a
> > > > > reboot), waited a minute or so and restarted. So far I have been able to
> > > > > record 5 separate times on that tuner. So I think I am good. I'll
> > > > > observe
> > > > > for a couple of days and report back.
> > > > >
> > > > > I managed to break live TV in my Delete all cards process, so I am off
> > > > > to
> > > > > investigate that.
> > > > > Mike
> > > >
> > > > Mike,
> > > >
> > > > When you say you were able to record 5 seperate times, do you mean that
> > > > you
> > > > manually told the tuner to to record a show, stopped the recording, and
> > > > told it to record another show, possibly on another channel? [.Or were
> > > > these
> > > > previously scheduled recordings?]
> > > >
> > > > If so, I was able to do the same thing, but after leaving the machine with
> > > > previously scheduled programs, the first scheduled program fails to
> > > > record.
> > > > For example, after a reboot, I went into Manage Recordings and selected a
> > > > currently running program for recording. It would successfully record. I
> > > > would stop the recording and go to another channel and do the same thing
> > > > with another program. Once again no problem. However, after thinking
> > > > everything is Ok I would come back the next morning to find an empty file
> > > > for a previously scheduled recording using that same tuner.
> > > >
> > > > I was wondering if there is something related to the scheduler going
> > > > on...?
> > > >
> > > > However, tonight I will try complete shutdown of both machines after I
> > > > remove my cards from setup. I will then re-select the cards after starting
> > > > the machine and see what happens. I may also shutdown after re-selecting.
> > > > I'll try anything now...
> > > >
> > > > -Kenan
> > > >
> > > > -Kenan
> > >
> > > Hi Kenan,
> > > Now you have me concerned, because that is exactly what I did. Told it to
> > > record a show, stopped it, picked another on a different channel, etc.
> > >
> > > I am using a PVR-350 and the interesting thing is that it is only the
> > > S-Video feed into the card that I was having problems with. I have the
> > > tuner portion of the card connected directly to my cable, and the S-Video
> > > input I am using to record from my cable box. The tuner portion has worked
> > > fine all along.
> > >
> > > I will schedule some shows on the S-Video feed overnight and report back.
> > > Mike
> > > _______________________________________________
> > > mythtv-users mailing list
> > > mythtv-users [at] mythtv
> > > http://www.mythtv.org/mailman/listinfo/mythtv-users
> >
> > Looks like I still have the problem. I was able to record a show at 11:00 pm, then the
> > card failed at the end of recording.
> >
> > May 8 22:59:29 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1521 (HandlePendingRecordings) TVRec(1): ASK_RECORDING 1 20 0 0
> > May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from None to RecordingOnly
> > May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(1): HW Tuner: 1->1
> > May 8 22:59:49 mythtv-server mythbackend[1950]: I TVRecEvent v4lchannel.cpp:661 (SetInputAndFormat) V4LChannel(/dev/video0): SetInputAndFormat(1, NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> > May 8 22:59:50 mythtv-server mythbackend[1950]: N Scheduler autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> > May 8 22:59:50 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Tuning recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
> > May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
> > May 8 22:59:50 mythtv-server mythbackend[1950]: E ProcessRequest programinfo.cpp:2278 (GetPlaybackURL) ProgramInfo(1519_20120508230000.mpg): GetPlaybackURL: '1519_20120508230000.mpg' should be local, but it can not be found.
> > May 8 22:59:51 mythtv-server mythbackend[1950]: I Scheduler scheduler.cpp:2459 (HandleRecordingStatusChange) Started recording: Pocoyo: channel 1519 on cardid 1, sourceid 1
> > May 8 22:59:51 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:3953 (TuningNewRecorder) TVRec(1): rec->GetPathname(): '/mnt/store/d4/video/1519_20120508230000.mpg'
> > May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
> > May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 0)
> > May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1360 (HandleAnnounce) MainServer::ANN Monitor
> > May 8 23:00:00 mythtv-server mythbackend[1950]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: mythtv-server.site as a client (events: 1)
> > May 8 23:02:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> > May 8 23:04:08 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:09:13 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:14:18 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:17:50 mythtv-server mythbackend[1950]: N Expire autoexpire.cpp:263 (CalcParams) AutoExpire: CalcParams(): Max required Free Space: 2.0 GB w/freq: 15 min
> > May 8 23:19:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:24:24 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:29:25 mythtv-server mythbackend[1950]: I HouseKeeping housekeeper.cpp:225 (RunHouseKeeping) Running housekeeping thread
> > May 8 23:30:10 mythtv-server mythbackend[1950]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(1): Changing from RecordingOnly to None
> > May 8 23:30:11 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
> > May 8 23:30:11 mythtv-server mythbackend[1950]: E RecThread mpegrecorder.cpp:1010 (run) MPEGRec(/dev/video0): Device error detected
> > May 8 23:30:13 mythtv-server mythbackend[1950]: E DeviceReadBuffer DeviceReadBuffer.cpp:460 (Poll) DevRdB(/dev/video0): poll error
> > May 8 23:30:13 mythtv-server mythbackend[1950]: I CoreContext scheduler.cpp:634 (UpdateRecStatus) Updating status for Pocoyo on cardid 1 (Recording => Recorded)
> > May 8 23:30:13 mythtv-server mythbackend[1950]: I TVRecEvent recordinginfo.cpp:1113 (FinishedRecording) Finished recording Pocoyo: channel 1519
> > May 8 23:30:13 mythtv-server mythbackend[1950]: E CoreContext mainserver.cpp:871 (customEvent) MainServer: PREVIEW_SUCCESS but no receivers.
>
> Darn. I was hoping your shutdown suggestion would work. I went home tonight and did exactly that.
>
> However, in your earlier message you stated that you were not having the same problem with your
> tuner, only your S-Video feed. That is different from my experience because I'm having the problem
> with my tuner. I don't use my S-Video feed.
>
> I'm convinced that there is a software problem, but because of how we are able to record
> on-demand, but not on-schedule, I think the problem has to do with the scheduler state and
> the PVR command requirements. The fact that your system is working with the tuner but not
> S-Video also seems to imply that the problem isn't tuner-related exactly.
>
> I may submit a bug report but I want to comb through my now volumous logs to see if I can
> spot a trend.
>
> Unfortunately my wife is getting a little worried that we won't be recording the end of the
> season episodes of her favorite shows... so the clock is ticking and I may have to revert
> to 0.24.
>
> -Kenan
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Unfortunately I have been unable to get my PVRs 150/250/350 to operate
consistently since upgrading to Myth 0.25 (Fedora 16). I have tried:

1. Deleting all tuners and then re-adding them back in (along with the
inputs).
2. Completely uninstalling 0.25 after removing the tuners, and then
re-installing 0.25 and adding back the tuners.
3. One-by-one removing one of the tuners from my master backend and
trying to get it to work with the other tuner alone.
4. Uninstalling and re-installing the ivtv-firmware.
5. Repairing mythconverg (just in case)
6. Different combinations of the above.

In all cases the PVRs record X number of shows successfully before
failing on X+1. X appears to be larger if I have a single tuner in the
master backend. X~1 when I have two tuners (PVR 150 & 250) in the master
backend.

However even when the recording is successful I get the following errors
in the log:

2012-05-26 14:00:16.119246 E [2716/2758] DeviceReadBuffer
DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
2012-05-26 14:00:16.119379 E [2716/2756] RecThread mpegrecorder.cpp:1010
(run) - MPEGRec(/dev/video0): Device error detected
2012-05-26 14:00:18.586740 E [2716/2864] DeviceReadBuffer
DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error

and

2012-05-26 14:30:09.678806 E [2716/3004] Commflag_4195
previewgenerator.cpp:254 (Run) - Preview: Encountered problems running
'/usr/bin/mythpreviewgen --size 0x0 --chanid 1003 --starttime
20120526143000 --verbose general --logpath /var/log/mythtv --loglevel
info --quiet' (128)
2012-05-26 14:30:39.097627 E [2716/2966] DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
2012-05-26 14:30:39.097755 E [2716/2965] RecThread mpegrecorder.cpp:1010
(run) - MPEGRec(/dev/video0): Device error detected

and sometimes the following:

2012-05-26 14:56:30.285663 E [2716/2965] RecThread mythdb.cpp:192
(DBError) - DB Error (Resolution insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, type, data)
VALUES ( ?, ?, ?, ?, ?);
Bindings were:
:CHANID=1003, :DATA=720, :MARK=46442, :STARTTIME=2012-05-26T14:30:00, :TYPE=30
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '1003-2012-05-26 14:30:00-30-46442' for key 'PRIMARY'

2012-05-26 14:56:30.286214 E [2716/2965] RecThread mythdb.cpp:192
(DBError) - DB Error (Resolution insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, type, data)
VALUES ( ?, ?, ?, ?, ?);
Bindings were:
:CHANID=1003, :DATA=480, :MARK=46442, :STARTTIME=2012-05-26T14:30:00, :TYPE=31
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '1003-2012-05-26 14:30:00-31-46442' for key 'PRIMARY'

2012-05-26 14:56:30.286807 E [2716/2965] RecThread mythdb.cpp:192
(DBError) - DB Error (Frame rate insert):
Query was:
INSERT INTO recordedmarkup (chanid, starttime, mark, type, data)
VALUES ( ?, ?, ?, ?, ?);
Bindings were:
:CHANID=1003, :DATA=29970, :MARK=46442, :STARTTIME=2012-05-26T14:30:00, :TYPE=32
Driver error was [2/1062]:
QMYSQL3: Unable to execute statement
Database error was:
Duplicate entry '1003-2012-05-26 14:30:00-32-46442' for key 'PRIMARY'

and

2012-05-26 15:00:18.714061 E [2716/2716] CoreContext mainserver.cpp:871
(customEvent) - MainServer: PREVIEW_SUCCESS but no receivers.

and

2012-05-26 15:30:27.368775 E [2716] ProcessRequest
fileringbuffer.cpp:289 (OpenFile) -
FileRingBuf(/data/recordings/1006_20120526153000.mpg): OpenFile(): File
too small (0B).
2012-05-26 15:30:38.958626 E [2716/3134] DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
2012-05-26 15:30:38.959622 E [2716/3133] RecThread mpegrecorder.cpp:1010
(run) - MPEGRec(/dev/video0): Device error detected

and

2012-05-27 00:35:32.703992 W [2716/3532] ProcessRequest
mainserver.cpp:5801 (connectionClosed) - MainServer: Unknown socket
closing MythSocket(0x122e580)
2012-05-27 00:35:32.718470 E [2716/3532] ProcessRequest
mythsocket.cpp:358 (writeStringList) - MythSocket(122e580:-1):
writeStringList: Error, socket went unconnected.
We wrote 0 of 10 bytes with 1 errors
starts with: 2 ok


When it finally does fail:

2012-05-27 17:59:47.849584 I [2716/2724] TVRecEvent tv_rec.cpp:1014
(HandleStateChange) - TVRec(1): Changing from None to RecordingOnly
2012-05-27 17:59:47.849651 I [2716/2724] TVRecEvent mythdbcon.cpp:395
(PurgeIdleConnections) - New DB connection, total: 12
2012-05-27 17:59:47.850950 I [2716/2724] TVRecEvent tv_rec.cpp:3456
(TuningCheckForHWChange) - TVRec(1): HW Tuner: 1->1
2012-05-27 17:59:47.870471 I [2716/2724] TVRecEvent v4lchannel.cpp:661
(SetInputAndFormat) - V4LChannel(/dev/video0): SetInputAndFormat(1,
NTSC) (v4l v2) input_switch: 0 mode_switch: 0
2012-05-27 17:59:48.033973 N [2716/2725] Scheduler autoexpire.cpp:263
(CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 2.0 GB
w/freq: 15 min
2012-05-27 17:59:48.043975 I [2716/2724] TVRecEvent tv_rec.cpp:3950
(TuningNewRecorder) - TVRec(1): rec->GetPathname():
'/data/recordings/1003_20120527180000.mpg'
2012-05-27 17:59:48.070399 I [2716/2725] Scheduler scheduler.cpp:2460
(HandleRecordingStatusChange) - Started recording: "KEY News at 6":
channel 1003 on cardid 1, sourceid 1
2012-05-27 17:59:50.991443 E [2716/7354] DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
2012-05-27 17:59:50.991528 E [2716/7353] RecThread mpegrecorder.cpp:1010
(run) - MPEGRec(/dev/video0): Device error detected
2012-05-27 17:59:55.941410 E [2716/7355] DeviceReadBuffer
DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2

The above repeats until the show is (supposedly) finished recording,
then:

2012-05-27 18:30:18.270742 E [2716/7805] DeviceReadBuffer
DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
2012-05-27 18:30:18.270811 E [2716/7353] RecThread mpegrecorder.cpp:1010
(run) - MPEGRec(/dev/video0): Device error detected
2012-05-27 18:30:20.737730 E [2716/7806] DeviceReadBuffer
DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
2012-05-27 18:30:20.763897 I [2716/2716] CoreContext scheduler.cpp:635
(UpdateRecStatus) - Updating status for "KEY News at 6" on cardid 1
(Recording => Recorded)
2012-05-27 18:30:20.772835 I [2716/2724] TVRecEvent
recordinginfo.cpp:1113 (FinishedRecording) - Finished recording KEY News
at 6: channel 1003

So, it thinks it recorded the show, but the file size is 0 and there is
no preview generated.

Occasionally, the show records, but in triplicate: I see three vertical
stripes of the same scene on one screen shot.

I don't think this is a hardware problem because I can make all three of
my PVRs fail eventually (and on two different machines: a master backend
and a slave backend). I'm worried it has some connection with the
database because of the database errors that I see. Also, there may be
some link with how long the tuner has been unused. There is a higher
likelihood of a successful follow-on recording (even with error
messages) if the tuner was used recently. The longer the pause
(overnight), then the higher likelihood that the next recording will
fail

Any help or suggestions would be very much appreciated.

-Kenan











_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


mtdean at thirdcontact

May 28, 2012, 8:46 AM

Post #11 of 14 (1828 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On 05/28/2012 03:05 AM, Kenan Ezal wrote:
> Unfortunately I have been unable to get my PVRs 150/250/350 to operate
> consistently since upgrading to Myth 0.25 (Fedora 16). I have tried:
>
> 1. Deleting all tuners and then re-adding them back in (along with the
> inputs).
> 2. Completely uninstalling 0.25 after removing the tuners, and then
> re-installing 0.25 and adding back the tuners.
> 3. One-by-one removing one of the tuners from my master backend and
> trying to get it to work with the other tuner alone.
> 4. Uninstalling and re-installing the ivtv-firmware.
> 5. Repairing mythconverg (just in case)
> 6. Different combinations of the above.
>
> In all cases the PVRs record X number of shows successfully before
> failing on X+1. X appears to be larger if I have a single tuner in the
> master backend. X~1 when I have two tuners (PVR 150& 250) in the master
> backend.
>
> However even when the recording is successful I get the following errors
> in the log:
>
> 2012-05-26 14:00:16.119246 E [2716/2758] DeviceReadBuffer
> DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
> 2012-05-26 14:00:16.119379 E [2716/2756] RecThread mpegrecorder.cpp:1010
> (run) - MPEGRec(/dev/video0): Device error detected
> 2012-05-26 14:00:18.586740 E [2716/2864] DeviceReadBuffer
> DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
...
> When it finally does fail:
>
> 2012-05-27 17:59:47.849584 I [2716/2724] TVRecEvent tv_rec.cpp:1014
> (HandleStateChange) - TVRec(1): Changing from None to RecordingOnly
> 2012-05-27 17:59:47.849651 I [2716/2724] TVRecEvent mythdbcon.cpp:395
> (PurgeIdleConnections) - New DB connection, total: 12
> 2012-05-27 17:59:47.850950 I [2716/2724] TVRecEvent tv_rec.cpp:3456
> (TuningCheckForHWChange) - TVRec(1): HW Tuner: 1->1
> 2012-05-27 17:59:47.870471 I [2716/2724] TVRecEvent v4lchannel.cpp:661
> (SetInputAndFormat) - V4LChannel(/dev/video0): SetInputAndFormat(1,
> NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> 2012-05-27 17:59:48.033973 N [2716/2725] Scheduler autoexpire.cpp:263
> (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 2.0 GB
> w/freq: 15 min
> 2012-05-27 17:59:48.043975 I [2716/2724] TVRecEvent tv_rec.cpp:3950
> (TuningNewRecorder) - TVRec(1): rec->GetPathname():
> '/data/recordings/1003_20120527180000.mpg'
> 2012-05-27 17:59:48.070399 I [2716/2725] Scheduler scheduler.cpp:2460
> (HandleRecordingStatusChange) - Started recording: "KEY News at 6":
> channel 1003 on cardid 1, sourceid 1
> 2012-05-27 17:59:50.991443 E [2716/7354] DeviceReadBuffer
> DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
> 2012-05-27 17:59:50.991528 E [2716/7353] RecThread mpegrecorder.cpp:1010
> (run) - MPEGRec(/dev/video0): Device error detected
> 2012-05-27 17:59:55.941410 E [2716/7355] DeviceReadBuffer
> DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2

This indicates that the capture device isn't responding to MythTV's
requests for data. Therefore, MythTV attempts to stop the card, then
restart it (which, also, seems to fail).

> Occasionally, the show records, but in triplicate: I see three vertical
> stripes of the same scene on one screen shot.

I've seen this type of failure in the STB, not the PVR-x50. I actually
had to reboot my DISH network STB at least once/month to prevent
similar, "it's outputting garbage," issues.

> I don't think this is a hardware problem because I can make all three of
> my PVRs fail eventually (and on two different machines: a master backend
> and a slave backend). I'm worried it has some connection with the
> database because of the database errors that I see.

The only part of the database that has information that could cause a
recording failure is the part that you completely cleared and
reconfigured with "Delete all capture cards" (not "Delete all capture
cards on <hostname>"). So, assuming you actually configured things
correctly, it's not a problem.

The database errors you're getting are due to the fact that your capture
card is failing to work properly--MythTV hasn't had a lot of testing for
(let alone wasn't designed for) use with broken/failing capture devices.

> Also, there may be
> some link with how long the tuner has been unused. There is a higher
> likelihood of a successful follow-on recording (even with error
> messages) if the tuner was used recently. The longer the pause
> (overnight), then the higher likelihood that the next recording will
> fail
>
> Any help or suggestions would be very much appreciated.

FWIW, it sounds to me like an issue well below MythTV--such as with the
capture card hardware/drivers/configuration and/or OS-/kernel-level issues.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


sbmythtv at cox

May 28, 2012, 12:18 PM

Post #12 of 14 (1814 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

---- "Michael T. Dean" <mtdean [at] thirdcontact> wrote:
> On 05/28/2012 03:05 AM, Kenan Ezal wrote:
> > Unfortunately I have been unable to get my PVRs 150/250/350 to operate
> > consistently since upgrading to Myth 0.25 (Fedora 16). I have tried:
> >
> > 1. Deleting all tuners and then re-adding them back in (along with the
> > inputs).
> > 2. Completely uninstalling 0.25 after removing the tuners, and then
> > re-installing 0.25 and adding back the tuners.
> > 3. One-by-one removing one of the tuners from my master backend and
> > trying to get it to work with the other tuner alone.
> > 4. Uninstalling and re-installing the ivtv-firmware.
> > 5. Repairing mythconverg (just in case)
> > 6. Different combinations of the above.
> >
> > In all cases the PVRs record X number of shows successfully before
> > failing on X+1. X appears to be larger if I have a single tuner in the
> > master backend. X~1 when I have two tuners (PVR 150& 250) in the master
> > backend.
> >
> > However even when the recording is successful I get the following errors
> > in the log:
> >
> > 2012-05-26 14:00:16.119246 E [2716/2758] DeviceReadBuffer
> > DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
> > 2012-05-26 14:00:16.119379 E [2716/2756] RecThread mpegrecorder.cpp:1010
> > (run) - MPEGRec(/dev/video0): Device error detected
> > 2012-05-26 14:00:18.586740 E [2716/2864] DeviceReadBuffer
> > DeviceReadBuffer.cpp:460 (Poll) - DevRdB(/dev/video0): poll error
> ...
> > When it finally does fail:
> >
> > 2012-05-27 17:59:47.849584 I [2716/2724] TVRecEvent tv_rec.cpp:1014
> > (HandleStateChange) - TVRec(1): Changing from None to RecordingOnly
> > 2012-05-27 17:59:47.849651 I [2716/2724] TVRecEvent mythdbcon.cpp:395
> > (PurgeIdleConnections) - New DB connection, total: 12
> > 2012-05-27 17:59:47.850950 I [2716/2724] TVRecEvent tv_rec.cpp:3456
> > (TuningCheckForHWChange) - TVRec(1): HW Tuner: 1->1
> > 2012-05-27 17:59:47.870471 I [2716/2724] TVRecEvent v4lchannel.cpp:661
> > (SetInputAndFormat) - V4LChannel(/dev/video0): SetInputAndFormat(1,
> > NTSC) (v4l v2) input_switch: 0 mode_switch: 0
> > 2012-05-27 17:59:48.033973 N [2716/2725] Scheduler autoexpire.cpp:263
> > (CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 2.0 GB
> > w/freq: 15 min
> > 2012-05-27 17:59:48.043975 I [2716/2724] TVRecEvent tv_rec.cpp:3950
> > (TuningNewRecorder) - TVRec(1): rec->GetPathname():
> > '/data/recordings/1003_20120527180000.mpg'
> > 2012-05-27 17:59:48.070399 I [2716/2725] Scheduler scheduler.cpp:2460
> > (HandleRecordingStatusChange) - Started recording: "KEY News at 6":
> > channel 1003 on cardid 1, sourceid 1
> > 2012-05-27 17:59:50.991443 E [2716/7354] DeviceReadBuffer
> > DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
> > 2012-05-27 17:59:50.991528 E [2716/7353] RecThread mpegrecorder.cpp:1010
> > (run) - MPEGRec(/dev/video0): Device error detected
> > 2012-05-27 17:59:55.941410 E [2716/7355] DeviceReadBuffer
> > DeviceReadBuffer.cpp:513 (Poll) - DevRdB(/dev/video0): Poll giving up 2
>
> This indicates that the capture device isn't responding to MythTV's
> requests for data. Therefore, MythTV attempts to stop the card, then
> restart it (which, also, seems to fail).
>
> > Occasionally, the show records, but in triplicate: I see three vertical
> > stripes of the same scene on one screen shot.
>
> I've seen this type of failure in the STB, not the PVR-x50. I actually
> had to reboot my DISH network STB at least once/month to prevent
> similar, "it's outputting garbage," issues.
>
> > I don't think this is a hardware problem because I can make all three of
> > my PVRs fail eventually (and on two different machines: a master backend
> > and a slave backend). I'm worried it has some connection with the
> > database because of the database errors that I see.
>
> The only part of the database that has information that could cause a
> recording failure is the part that you completely cleared and
> reconfigured with "Delete all capture cards" (not "Delete all capture
> cards on <hostname>"). So, assuming you actually configured things
> correctly, it's not a problem.
>
> The database errors you're getting are due to the fact that your capture
> card is failing to work properly--MythTV hasn't had a lot of testing for
> (let alone wasn't designed for) use with broken/failing capture devices.
>
> > Also, there may be
> > some link with how long the tuner has been unused. There is a higher
> > likelihood of a successful follow-on recording (even with error
> > messages) if the tuner was used recently. The longer the pause
> > (overnight), then the higher likelihood that the next recording will
> > fail
> >
> > Any help or suggestions would be very much appreciated.
>
> FWIW, it sounds to me like an issue well below MythTV--such as with the
> capture card hardware/drivers/configuration and/or OS-/kernel-level issues.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users


Hi Mike,

You could be right. But my problems started immediately after upgrading to 0.25 (from 0.24). I am planning on down-grading to 0.24 this week to see if everything works again. If not, then you will be right. If it does work, then its 0.25. (Luckily I saved my database from before the 0.25 upgrade!!).

BTW, I'm not the only one with this problem:

http://code.mythtv.org/trac/ticket/10732#

I was about to report a bug myself when I found the ticket. I'm now collecting some debug information that I will also post to the ticket.

I also wonder if this is related to the LiveTV problem with PVRs... apparently there is a fix for it now so I will try it out when its available.

If it is a "capture card hardware/drivers/configuration and/or OS-/kernel-level issue" then it affects PVR-150 & -250 & -350, and both 32-bit and 64-bit versions of Fedora 16. My slave backend is my original mythtv box and is a 32-bit system. Whatever it is, it makes MythTV unreliable for my setup, which is admittedly relatively old (all analog), but I refuse to pay more monthly fees for the digital one. I know its inevitible, but I can delay as long as possible ;-)

-Kenan
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


Larry.Finger at lwfinger

May 28, 2012, 12:40 PM

Post #13 of 14 (1810 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

On 05/28/2012 02:18 PM, Kenan Ezal wrote:
> You could be right. But my problems started immediately after upgrading to 0.25 (from 0.24). I am planning on down-grading to 0.24 this week to see if everything works again. If not, then you will be right. If it does work, then its 0.25. (Luckily I saved my database from before the 0.25 upgrade!!).
>
> BTW, I'm not the only one with this problem:
>
> http://code.mythtv.org/trac/ticket/10732#
>
> I was about to report a bug myself when I found the ticket. I'm now collecting some debug information that I will also post to the ticket.
>
> I also wonder if this is related to the LiveTV problem with PVRs... apparently there is a fix for it now so I will try it out when its available.
>
> If it is a "capture card hardware/drivers/configuration and/or OS-/kernel-level issue" then it affects PVR-150& -250& -350, and both 32-bit and 64-bit versions of Fedora 16. My slave backend is my original mythtv box and is a 32-bit system. Whatever it is, it makes MythTV unreliable for my setup, which is admittedly relatively old (all analog), but I refuse to pay more monthly fees for the digital one. I know its inevitible, but I can delay as long as possible ;-)

Whatever the problem, I doubt that it is a driver problem. I am still running
MythTV 0.21, but my kernel and drivers are 3.4-rc1. My PVR500 shows no problems.

Larry
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users


SBMythTV at cox

Jun 5, 2012, 11:43 PM

Post #14 of 14 (1765 views)
Permalink
Re: Post upgrade 0.24 to 0.25 PVR-150/250/350 fail to record at some point [In reply to]

-----Original Message-----
From: Larry Finger [mailto:larry.finger [at] gmail] On Behalf Of Larry Finger
Sent: Monday, May 28, 2012 12:41 PM
To: Discussion about MythTV
Cc: Kenan Ezal; Michael T. Dean
Subject: Re: [mythtv-users] Post upgrade 0.24 to 0.25 PVR-150/250/350 fail
to record at some point

<<
Whatever the problem, I doubt that it is a driver problem. I am still
running
MythTV 0.21, but my kernel and drivers are 3.4-rc1. My PVR500 shows no
problems.
>>

I've now been back on 0.24 for about a week with no problems. The only
change to my system was the removal of 0.25 and the re-install of 0.24. No
other changes took place.

It is still possible that one of my MythTV settings was causing problems in
0.25, but it is definitely not hardware, or drivers. It is something within
0.25 or a conflict within 0.25 with hardware and drivers. I gather that
there are other PVR-150/250/350 users that are able to operate within 0.25
and some like myself who cannot. So, maybe it is the later.

I'm curious if anyone has any ideas about which settings might potentially
cause the type of instability that I was experiencing in 0.25 [and Fedora 16
(64-bit and 32-bit)].

As an aside: Does anyone know how I might be able to manually add back the
programs that were recorded under 0.25 into my 0.24 mythconverg? I printed a
MythWeb output of all programs recorded under 0.25 after upgrading from
0.24. [.I also saved the last database before downgrading back to 0.24.]

-Kenan

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

MythTV users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.