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

Mailing List Archive: MythTV: Dev

Help testing #6719

 

 

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


jppoet at gmail

Apr 13, 2010, 6:54 PM

Post #1 of 24 (3294 views)
Permalink
Help testing #6719

Ticket #6719 (http://svn.mythtv.org/trac/ticket/6719) was created 9
months ago to make LiveTV more reliable and user friendly. Without
that patch, the HD-PVR is virtually unusable for LiveTV, and it is
HD-PVR users that benefit the most from the patch.

The patch is pretty invasive, however, so I am not comfortable
committing it without some wider testing. I have two HD-PVRs and a
couple of HDHomeRuns, and that patch has not caused me any problems
during the last 9 months. I would appreciate it if others with
different hardware would give it a try, to make sure there are not any
issues. Is there anyone using a rotor that could give it a try? DVB?
PVR-x50?

This is a pretty low priority request, but there are enough HD-PVR
users at this point, that it would be nice to get this in for 0.24.

Thanks,

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


brooks at whitefordsound

Apr 13, 2010, 8:56 PM

Post #2 of 24 (3197 views)
Permalink
Re: Help testing #6719 [In reply to]

SUu

On 4/13/10, John P Poet <jppoet [at] gmail> wrote:
> Ticket #6719 (http://svn.mythtv.org/trac/ticket/6719) was created 9
> months ago to make LiveTV more reliable and user friendly. Without
> that patch, the HD-PVR is virtually unusable for LiveTV, and it is
> HD-PVR users that benefit the most from the patch.
>
> The patch is pretty invasive, however, so I am not comfortable
> committing it without some wider testing. I have two HD-PVRs and a
> couple of HDHomeRuns, and that patch has not caused me any problems
> during the last 9 months. I would appreciate it if others with
> different hardware would give it a try, to make sure there are not any
> issues. Is there anyone using a rotor that could give it a try? DVB?
> PVR-x50?
>
> This is a pretty low priority request, but there are enough HD-PVR
> users at this point, that it would be nice to get this in for 0.24.
>
> Thanks,
>
> John
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


ylee at pobox

Apr 14, 2010, 9:38 AM

Post #3 of 24 (3185 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet <jppoet [at] gmail> says:
> The patch is pretty invasive, however, so I am not comfortable
> committing it without some wider testing.

I have seen good results on my 0.22-fixes setup over the past week
using v1.5 of your patch and a HDHomRun, two FireWire cable boxes, and
a HD-PVR.[1] The signal detection materially helps with FireWire
tuning too.

[1] Out of commission for the time being. What are the causes/symptoms
of the "bug that can under certain conditions cause the HD-PVR to
become inoperable"?

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


phil.linttell at rogers

Apr 15, 2010, 6:15 AM

Post #4 of 24 (3157 views)
Permalink
Re: Help testing #6719 [In reply to]

> Date: Tue, 13 Apr 2010 19:54:33 -0600
> From: John P Poet <jppoet [at] gmail>
> Subject: [mythtv] Help testing #6719
> To: Development of mythtv <mythtv-dev [at] mythtv>
>
> Ticket #6719 (http://svn.mythtv.org/trac/ticket/6719) was created 9
> months ago to make LiveTV more reliable and user friendly. Without
> that patch, the HD-PVR is virtually unusable for LiveTV, and it is
> HD-PVR users that benefit the most from the patch.
>
> The patch is pretty invasive, however, so I am not comfortable
> committing it without some wider testing. I have two HD-PVRs and a
> couple of HDHomeRuns, and that patch has not caused me any problems
> during the last 9 months. I would appreciate it if others with
> different hardware would give it a try, to make sure there are not any
> issues. Is there anyone using a rotor that could give it a try? DVB?
> PVR-x50?
>
> This is a pretty low priority request, but there are enough HD-PVR
> users at this point, that it would be nice to get this in for 0.24.
>
> Thanks,
>
> John
>
Hi John,

I run a single HD-PVR with firewire channel-changing and a six-second
delay at the end of the channel change script.

I ran with this patch in 0.22, and tried running without it when I first
upgraded to 0.23-fixes. Without the patch I had difficulty getting
livetv to work, but I also experienced problems with occasional backend
recording failures. I applied patch 1.6 and have not had problems with
backend recording failures since. (I only really use livetv to verify
that the HD-PVR is working.)

I don't have any other encoders, and although I stay current with
0.23-fixes, I haven't applied the patch update you uploaded 5 days ago.

From an HD-PVR functionality perspective, I consider this patch
essential. I can't attest to it not impacting other configurations,
however.

Phil


_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

Apr 18, 2010, 11:49 PM

Post #5 of 24 (3050 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet said:

>I would appreciate it if others with
>different hardware would give it a try, to make sure there are not any
>issues.

I've applied #6719, #6611 and #6602 to .23-fixes r24029 on a system with
two Kworld ATSC110/115 cards , a Kworld PlusTV HD PCI 120 card, a
pvrusb2 and an hdpvr and all seem to work OK. Live tv is improved on
all of them, with smoother transitions between shows, there are no crashes
yet. I'll report any problems I see.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

Apr 27, 2010, 8:30 PM

Post #6 of 24 (2869 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sun, Apr 18, 2010 at 11:49 PM, Mark Goldberg wrote:
> John P Poet said:
>
>>I would appreciate it if others with
>>different hardware would give it a try, to make sure there are not any
>>issues.
>
> I've applied #6719, #6611 and #6602 to .23-fixes r24029 on a system with
> two Kworld ATSC110/115 cards , a Kworld PlusTV HD PCI 120 card, a
> pvrusb2 and an hdpvr and all seem to work OK. Live tv is improved on
> all of them, with smoother transitions between shows, there are no crashes
> yet. I'll report any problems I see.

I had myth fail to record two shows on two different cards, once last night and
once tonight. The logs total about 3 meg. If you want them all, let me
know where
they can be uploaded to. A snippet of mythbackend.log around the time of the
failure follows if it is any help.


2010-04-27 19:18:23.681 RecBase(12:/dev/dvb/adapter2/frontend0):
GetKeyframePositions(34561,9223372036854775807,#13) out of 2318
2010-04-27 19:22:11.707 UPnpMedia: BuildMediaMap VIDEO scan starting
in :/archives/videos:
2010-04-27 19:22:11.818 UPnpMedia: BuildMediaMap Done. Found 197 objects
2010-04-27 19:26:55.150 AutoExpire: CalcParams(): Max required Free
Space: 12.0 GB w/freq: 14 min
2010-04-27 19:34:28.946 RecBase(12:/dev/dvb/adapter2/frontend0):
GetKeyframePositions(34756,9223372036854775807,#1929) out of 4247
2010-04-27 19:40:55.194 AutoExpire: CalcParams(): Max required Free
Space: 12.0 GB w/freq: 14 min
2010-04-27 19:45:28.886 RecBase(12:/dev/dvb/adapter2/frontend0):
GetKeyframePositions(63691,9223372036854775807,#1318) out of 5565
2010-04-27 19:52:18.824 UPnpMedia: BuildMediaMap VIDEO scan starting
in :/archives/videos:
2010-04-27 19:52:18.906 UPnpMedia: BuildMediaMap Done. Found 197 objects
2010-04-27 19:53:54.144 RecBase(12:/dev/dvb/adapter2/frontend0):
GetKeyframePositions(83461,9223372036854775807,#1010) out of 6575
2010-04-27 19:54:55.237 AutoExpire: CalcParams(): Max required Free
Space: 12.0 GB w/freq: 14 min
2010-04-27 19:58:00.893 Reschedule requested for id 0.
2010-04-27 19:58:02.131 Scheduled 123 items in 1.2 = 0.00 match + 1.22 place
2010-04-27 19:58:29.585 TVRec(15): ASK_RECORDING 15 29 0 0
2010-04-27 19:58:29.769 TVRec(16): ASK_RECORDING 16 29 0 0
2010-04-27 19:58:29.794 TVRec(13): ASK_RECORDING 13 29 0 0
2010-04-27 19:58:29.929 TVRec(14): ASK_RECORDING 14 29 0 0
2010-04-27 19:58:30.069 TVRec(12): ASK_RECORDING 12 29 0 0
2010-04-27 19:59:02.269 ProgramInfo(): Updated pathname '':'' ->
'7051_20100427195900.mpg'
2010-04-27 19:59:02.379 TVRec(13): Changing from None to RecordingOnly
2010-04-27 19:59:02.380 TVRec(13): HW Tuner: 13->13
2010-04-27 19:59:02.401 DVBChan(13:/dev/dvb/adapter2/frontend0) Error:
SetChannelByString(10_1): Multiplex is not available
2010-04-27 19:59:02.460 AutoExpire: CalcParams(): Max required Free
Space: 12.0 GB w/freq: 7 min
2010-04-27 19:59:02.460 Started recording: NCIS: Los Angeles "Fame":
channel 7051 on cardid 13, sourceid 7
2010-04-27 19:59:02.519 ProgramInfo(1101_20100426195900.mpg), Error:
GetPlaybackURL: '1101_20100426195900.mpg' should be local, but it can
not be found.
2010-04-27 19:59:02.552 ProgramInfo(7051_20100427195900.mpg), Error:
GetPlaybackURL: '7051_20100427195900.mpg' should be local, but it can
not be found.
2010-04-27 19:59:02.629 ProgramInfo(7051_20100427195900.mpg), Error:
GetPlaybackURL: '7051_20100427195900.mpg' should be local, but it can
not be found.
2010-04-27 20:01:00.213 TVRec(12): Changing from RecordingOnly to None
2010-04-27 20:01:00.214 ProgramInfo(): Updated pathname '':'' ->
'7051_20100427185900.mpg'
2010-04-27 20:01:00.214 Finished recording NCIS "Moonlighting": channel 7051
2010-04-27 20:01:00.236 ProgramInfo(7051_20100427185900.mpg):
Recording designated 1080i/p because width was 1920
2010-04-27 20:01:00.255 Reschedule requested for id 0.
2010-04-27 20:01:00.265 ProgramInfo(): Updated pathname '':'' ->
'7051_20100427185900.mpg'
2010-04-27 20:01:00.627 ProgramInfo(): Updated pathname '':'' ->
'7051_20100427185900.mpg'
2010-04-27 20:01:00.627 Finished recording NCIS "Moonlighting": channel 7051
2010-04-27 20:01:00.654 ProgramInfo(): Updated pathname '':'' ->
'7051_20100427185900.mpg'
2010-04-27 20:01:00.656 mythbackend version:
branches/release-0-23-fixes/mythtv/ [24030] www.mythtv.org
2010-04-27 20:01:00.656 Using runtime prefix = /usr
2010-04-27 20:01:00.656 Using configuration directory = /home/mythtv/.mythtv
2010-04-27 20:01:00.656 Empty LocalHostName.
2010-04-27 20:01:00.656 Using localhost value of mythpvr

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


robert.mcnamara at gmail

Apr 27, 2010, 8:36 PM

Post #7 of 24 (2871 views)
Permalink
Re: Help testing #6719 [In reply to]

On Tue, Apr 27, 2010 at 8:30 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> On Sun, Apr 18, 2010 at 11:49 PM, Mark Goldberg wrote:
>> John P Poet said:
>>
>>>I would appreciate it if others with
>>>different hardware would give it a try, to make sure there are not any
>>>issues.
>>
>> I've applied #6719, #6611 and #6602 to .23-fixes r24029 on a system with
>> two Kworld ATSC110/115 cards , a Kworld PlusTV HD PCI 120 card, a
>> pvrusb2 and an hdpvr and all seem to work OK. Live tv is improved on
>> all of them, with smoother transitions between shows, there are no crashes
>> yet. I'll report any problems I see.
>
> I had myth fail to record two shows on two different cards, once last night and
> once tonight. The logs total about 3 meg. If you want them all, let me
> know where
> they can be uploaded to. A snippet of mythbackend.log around the time of the
> failure follows if it is any help.
>

These logs seem to indicate that your channels have moved, don't see
anything obvious that would indicate a relationship with the patches
in question.

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

Apr 28, 2010, 6:21 AM

Post #8 of 24 (2835 views)
Permalink
Re: Help testing #6719 [In reply to]

Robert wrote:
>These logs seem to indicate that your channels have moved, don't see
>anything obvious that would indicate a relationship with the patches
>in question.

Any second overlapping recording using multirec fails. I set it to
record show A on
channel X from 5:30 to 6:01 and show B on channel X from 5:59 to 6:30 and the
second recording fails. It attempts to record both on the same tuner.

This seems to happen on all my ATSC tuners. I deleted all capture cards and set
them up again, with no improvement. I don't know if this is due to these changes
or just to the upgrade to .23-fixes done at the same time.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

Apr 28, 2010, 9:23 PM

Post #9 of 24 (2802 views)
Permalink
Re: Help testing #6719 [In reply to]

On Wed, Apr 28, 2010 Mark Goldberg wrote:
> Robert wrote:
>>These logs seem to indicate that your channels have moved, don't see
>>anything obvious that would indicate a relationship with the patches
>>in question.
>
> Any second overlapping recording using multirec fails. I set it to
> record show A on
> channel X from 5:30 to 6:01 and show B on channel X from 5:59 to 6:30 and the
> second recording fails. It attempts to record both on the same tuner.
>
> This seems to happen on all my ATSC tuners. I deleted all capture cards and set
> them up again, with no improvement. I don't know if this is due to these changes
> or just to the upgrade to .23-fixes done at the same time.

I updated to .23-fixes 24265 without #6719, #6611 and #6602 and the problem
went away. I'll try applying those patches to 24265 and see if it comes back.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

Apr 29, 2010, 11:17 AM

Post #10 of 24 (2774 views)
Permalink
Re: Help testing #6719 [In reply to]

On Wed, Apr 28, 2010 Mark Goldberg wrote:
> I updated to .23-fixes 24265 without #6719, #6611 and #6602 and the problem
> went away. I'll try applying those patches to 24265 and see if it comes back.

I can confirm that .23-fixes 24265 with #6719, #6611 and #6602 fails to
record overlapping shows using multirec. .23-fixes 24265 with #6602
only works OK.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

Apr 29, 2010, 12:29 PM

Post #11 of 24 (2775 views)
Permalink
Re: Help testing #6719 [In reply to]

On Thu, Apr 29, 2010 at 12:17 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> On Wed, Apr 28, 2010 Mark Goldberg wrote:
>> I updated to .23-fixes 24265 without #6719, #6611 and #6602 and the problem
>> went away. I'll try applying those patches to 24265 and see if it comes back.
>
> I can confirm that .23-fixes 24265 with #6719, #6611 and #6602 fails to
> record overlapping shows using multirec.  .23-fixes 24265 with #6602
> only works OK.

Thanks, Mark.

I will try to investigate the multirec issue.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

May 7, 2010, 4:49 PM

Post #12 of 24 (2604 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet said:

>Thanks, Mark.
>
>I will try to investigate the multirec issue.

Thanks,

If you have any suggestions as to where to look in the code, I could
try to help. I'm more of a tester than a coder, but I could take a look.
If I can help in some other way, let me know.

The fixes in RC3 did seem to stop the backend from crashing if the
HDPVR fails to start a recording.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

May 7, 2010, 7:26 PM

Post #13 of 24 (2597 views)
Permalink
Re: Help testing #6719 [In reply to]

On Fri, May 7, 2010 at 5:49 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> John P Poet said:
>
>>Thanks, Mark.
>>
>>I will try to investigate the multirec issue.
>
> Thanks,
>
> If you have any suggestions as to where to look in the code, I could
> try to help. I'm more of a tester than a coder, but I could take a look.
> If I can help in some other way, let me know.
>
> The fixes in RC3 did seem to stop the backend from crashing if the
> HDPVR fails to start a recording.


Honestly, I don't know. I wrote that patch 10+ months ago, and the
only changes I have made since then have been keep it updated against
trunk. It has been so long since I did the patch, that I don't
remember enough about the mechanics to give you much direction. I
have never tried to use multirec, but I do have a HDHomeRun so I
should be able to turn that on.

I also have been so swamped at work, that I have been exhausted when I
do get home, and have not been inclined to work on Myth -- and I don't
see that changing any time soon.. If you are interested in getting
your hands dirty, I would be happy to give you some direction, though.

In brief summary, that patch splits the tuning process into a new
thread. This allows the main thread to maintain interactive
communication with mythfrontend, while the new thread deals with
getting the channel tuned. During the tuning process, flags are set
which are then communicated to mythfrontend to give it the status of
the tuning operation. Meanwhile, the frontend can abort the tuning by
exiting LiveTV or switching to another channel -- that sets an abort
status, which results in the tuning thread exiting.

The main purpose of the patch is to keep interactive communication
between mythbackend and mythfrontend so the user can see what is going
on, *and* so mythfrontend does not time-out waiting for the backend to
finish tuning.

Are you an emacs user? If so, I would recommend starting out with two
source trees -- one with 6719 applied and one without. Then bring up
emacs, and use its (Tools->Compare (Ediff)->Two Files) function to
analyse the difference between a patched and unpatched version of a
file. Press the '|' (vertical bar) in the ediff subwindow to switch
to side-by-side view, and maximize the editor window. With the ediff
subwindow in focus, you can press 'n' to go to the next "difference",
and 'p' to go the previous difference. This makes it much easier to
see the changes than trying to decipher the patch itself.

I may have the time and inclination to bring that patch up on Sunday,
and refresh my memory about it's specifics.

It is nice to have someone else interested in improving the HD-PVR
functionality.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

May 8, 2010, 9:34 AM

Post #14 of 24 (2588 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet said:
>Are you an emacs user? If so, I would recommend starting out with two
>source trees -- one with 6719 applied and one without. Then bring up
>emacs, and use its (Tools->Compare (Ediff)->Two Files) function to
>analyse the difference between a patched and unpatched version of a
>file. Press the '|' (vertical bar) in the ediff subwindow to switch
>to side-by-side view, and maximize the editor window. With the ediff
>subwindow in focus, you can press 'n' to go to the next "difference",
>and 'p' to go the previous difference. This makes it much easier to
>see the changes than trying to decipher the patch itself.

I used to be a big emacs user maybe 15 years ago, not so much
recently. I like Kompare to look at file differences. I'm thinking that
the issue is in channelbase.cpp and that IsInputAvailable() returns
false to cause the error message, but I haven't gotten much farther.

>It is nice to have someone else interested in improving the HD-PVR
>functionality.

I think there are a growing number of people interested. The cable
companies are locking down the clear QAM channels and many
have to switch to some type of set top box. I'm just trying to get
the HDPVR to work as reliably as the ATSC tuners, and keep
up the WAF.

Unfortunately there are several issues. I have Dish and there are
sound sync issues that I'm trying to get a handle on. Sometimes it
is fine, sometimes the sound sync drifts off by several seconds by
the end of an hour show. That seems to be unrelated to this patch.
They "fixed" the windows driver but I'm unsure if the latest firmware
will help the linux driver or if something else is needed. Switching
the Dish STB to PCM out seems to help.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

May 8, 2010, 10:28 AM

Post #15 of 24 (2583 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sat, May 8, 2010 at 10:34 AM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> John P Poet said:
>>Are you an emacs user? If so, I would recommend starting out with two
>>source trees -- one with 6719 applied and one without. Then bring up
>>emacs, and use its (Tools->Compare (Ediff)->Two Files) function to
>>analyse the difference between a patched and unpatched version of a
>>file. Press the '|' (vertical bar) in the ediff subwindow to switch
>>to side-by-side view, and maximize the editor window. With the ediff
>>subwindow in focus, you can press 'n' to go to the next "difference",
>>and 'p' to go the previous difference. This makes it much easier to
>>see the changes than trying to decipher the patch itself.
>
> I used to be a big emacs user maybe 15 years ago, not so much
> recently. I like Kompare to look at file differences. I'm thinking that
> the issue is in channelbase.cpp and that  IsInputAvailable() returns
> false to cause the error message, but I haven't gotten much farther.


I still have not looked at the code again, but I am guessing it is a
mutex problem. To support the new thread, the mutexes needed tweaked,
and I bet one of them is preventing the second "record" from working.


>>It is nice to have someone else interested in improving the HD-PVR
>>functionality.
>
> I think there are a growing number of people interested. The cable
> companies are locking down the clear QAM channels and many
> have to switch to some type of set top box. I'm just trying to get
> the HDPVR to work as reliably as the ATSC tuners, and keep
> up the WAF.


I dumped Comcast three years ago, the day after they enabled 5C
protection on all the firewire channels.


> Unfortunately there are several issues. I have Dish and there are
> sound sync issues that I'm trying to get a handle on. Sometimes it
> is fine, sometimes the sound sync drifts off by several seconds by
> the end of an hour show. That seems to be unrelated to this patch.
> They "fixed" the windows driver but I'm unsure if the latest firmware
> will help the linux driver or if something else is needed. Switching
> the Dish STB to PCM out seems to help.


You are not the first person to complain about bad interactions with
Dish in that way. Sorry, but it makes me glad I choose Directv ;)


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv-dev at westbrook

May 8, 2010, 10:56 AM

Post #16 of 24 (2581 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sat, May 8, 2010 at 11:28 AM, John P Poet <jppoet [at] gmail> wrote:

> You are not the first person to complain about bad interactions with
> Dish in that way. Sorry, but it makes me glad I choose Directv ;)
>

I miss DirecTV dearly. I also enjoyed card tech back in the day that can't
be discussed here. Unfortunately, my current US apartment has only
north-facing exposure.

Good on you.

EW


jppoet at gmail

May 9, 2010, 12:06 PM

Post #17 of 24 (2554 views)
Permalink
Re: Help testing #6719 [In reply to]

On Wed, Apr 28, 2010 at 7:21 AM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> Robert wrote:
>>These logs seem to indicate that your channels have moved, don't see
>>anything obvious that would indicate a relationship with the patches
>>in question.
>
> Any second overlapping recording using multirec fails. I set it to
> record show A on
> channel X from 5:30 to 6:01 and show B on channel X from 5:59 to 6:30 and the
> second recording fails. It attempts to record both on the same tuner.


Consistently? I just tried to reproduce the problem and could not. I
will try again.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

May 9, 2010, 1:59 PM

Post #18 of 24 (2548 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sun, May 9, 2010 at 1:06 PM, John P Poet <jppoet [at] gmail> wrote:
> On Wed, Apr 28, 2010 at 7:21 AM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
>> Robert wrote:
>>>These logs seem to indicate that your channels have moved, don't see
>>>anything obvious that would indicate a relationship with the patches
>>>in question.
>>
>> Any second overlapping recording using multirec fails. I set it to
>> record show A on
>> channel X from 5:30 to 6:01 and show B on channel X from 5:59 to 6:30 and the
>> second recording fails. It attempts to record both on the same tuner.
>
>
> Consistently?  I just tried to reproduce the problem and could not.  I
> will try again.

With trunk, I was not able to reproduce the problem even after several
tries. While 0.23-fixes is essentially identical, I tried it a few
times and was finally able to make something bad happen.

I have attached new versions of the patch (one for trunk and one for
0.23-fixes) to the ticket, which hopefully fix your problem.


John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

May 9, 2010, 9:56 PM

Post #19 of 24 (2540 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet said:
>I have attached new versions of the patch (one for trunk and one for
>0.23-fixes) to the ticket, which hopefully fix your problem.

Sorry, it does the same thing with the same error message.
DVBChan(7:/dev/dvb/adapter2/frontend0) Error:
SetChannelByString(10_1): Multiplex is not available
The failure is 100% reliable.With #6719 it never records two things on
the same multiplex.
If you could not reproduce it reliably, it probably is not the same
error. Thanks for
trying though.

And, the sound sync problem is back, independent of this change. I
thought I had it working by
having the dish box output pcm and letting the hdpvr re-encode to ac3,
and it worked yesterday,
but not today, and I made no changes. Yesterday, fine, today, it
drifts seconds off after a few minutes.
I'll have to get that fixed again. I know the re-encoding is not the
best, but it is better than sound
way off from the picture.Just as an aside, if anyone has an hdpvr
working reliably with a dish
set top box, please let me know how you did it. Maybe I'll start
another discussion thread.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stichnot at gmail

May 9, 2010, 10:38 PM

Post #20 of 24 (2538 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sun, May 9, 2010 at 9:56 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> And, the sound sync problem is back, independent of this change. I
> thought I had it working by
> having the dish box output pcm and letting the hdpvr re-encode to ac3,
> and it worked yesterday,
> but not today, and I made no changes. Yesterday, fine, today, it
> drifts seconds off after a few minutes.
> I'll have to get that fixed again. I know the re-encoding is not the
> best, but it is better than sound
> way off from the picture.Just as an aside, if anyone has an hdpvr
> working reliably with a dish
> set top box, please let me know how you did it. Maybe I'll start
> another discussion thread.

I solved this by using an earlier version of the hdpvr firmware. This
is with the DISH vip211 receiver.

http://www.gossamer-threads.com/lists/mythtv/users/413652#413652

Jim
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

May 10, 2010, 7:43 AM

Post #21 of 24 (2526 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sun, May 9, 2010 at 10:56 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> John P Poet said:
>>I have attached new versions of the patch (one for trunk and one for
>>0.23-fixes) to the ticket, which hopefully fix your problem.
>
> Sorry, it does the same thing with the same error message.
> DVBChan(7:/dev/dvb/adapter2/frontend0) Error:
> SetChannelByString(10_1): Multiplex is not available
> The failure is 100% reliable.With #6719 it never records two things on
> the same multiplex.
> If you could not reproduce it reliably, it probably is not the same
> error. Thanks for
> trying though.

Odd. I wonder what is different between your system and mine? I
tried multirec with my HDHomeRun and don't seem to have the problem,
so it does not seem to be a problem with mulitrec itself. I am not
sure how to proceed.

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

May 10, 2010, 7:53 AM

Post #22 of 24 (2528 views)
Permalink
Re: Help testing #6719 [In reply to]

Jim said:

>I solved this by using an earlier version of the hdpvr firmware. This
>is with the DISH vip211 receiver.

The latest firmware and Windows driver is supposed to fix the problem, at least
according to Hauppauge. That leads me to believe that the Linux driver may have
fixed the problem, but only with "broken" firmware. With "fixed"
firmware, it does
not work correctly. Hopefully the older firmware works on my E1 version HDPVR.

It does seem that switching to 720p then back to 1080i on the output of the
VIP211k makes it work for the next day until the dish box updates
itself the next
night. I am going to verify this by running a cron job at 4 am after
the box updates
itself to go into the setup menus and do just that.

It sure would be nice to know what was "fixed" in the latest Hauppauge firmware
and driver so this could be sorted out.Software that works differently from day
to day is very disconcerting. I'm trying to set this up so the family can just
use it. I'd much rather have a bug that happens all of the time then one that
happens occasionally. At least you know what you have.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


jppoet at gmail

May 10, 2010, 9:37 AM

Post #23 of 24 (2514 views)
Permalink
Re: Help testing #6719 [In reply to]

On Sun, May 9, 2010 at 10:56 PM, Mark Goldberg <marklgoldberg [at] gmail> wrote:
> John P Poet said:
>>I have attached new versions of the patch (one for trunk and one for
>>0.23-fixes) to the ticket, which hopefully fix your problem.
>
> Sorry, it does the same thing with the same error message.
> DVBChan(7:/dev/dvb/adapter2/frontend0) Error:
> SetChannelByString(10_1): Multiplex is not available
> The failure is 100% reliable.With #6719 it never records two things on
> the same multiplex.
> If you could not reproduce it reliably, it probably is not the same
> error. Thanks for
> trying though.

What tuner card are you using that exhibits this issue?

I will work on create a version of the patch with a lot of extra
debugging messages in it.


> if anyone has an hdpvr
> working reliably with a dish
> set top box, please let me know how you did it. Maybe I'll start
> another discussion thread.

Please do. I would like to keep this thread on topic.


Thanks,

John
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


marklgoldberg at gmail

May 10, 2010, 11:41 AM

Post #24 of 24 (2508 views)
Permalink
Re: Help testing #6719 [In reply to]

John P Poet said:
>What tuner card are you using that exhibits this issue?

I listed them way up in the discussion,
two Kworld ATSC110/115 cards and a Kworld PlusTV HD PCI 120 card.
I believe saw postings saying the same issue happens with DVB cards
also, which affects lots of folks in the rest of the world.

>I will work on create a version of the patch with a lot of extra
>debugging messages in it.

If you do that it would be great. If you show me how, I could probably
add more messages after I see the output to drill down further in
the area where the problem is. It seems the code is different for
hdpvr, hdhomerun
and ATSC/DVB cards. Maybe this only shows up on ATSC/DVB cards.
I don't understand the code at all, but I don't see a case there to handle
when on the same multiplex you really don't have to do any tuning at all,
just capture more data from a tuner that you are already capturing
data from.

Mark
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

MythTV dev 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.