Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. MythTV>
  3. Users
HDPVR intermittent failure
dryheat122 at gmail
May 10, 2020, 7:37 PM
Post #1 of 67 (3506 views)
Permalink
Hi all. Hope you are surviving the apocalypse OK.

I have a HDPVR as one of my recorders. Recently, and with increasing
frequency, recordings on it fail. This is not the normal issue with the
wall-wart failing as I am powering it from USB these days (thanks to the
helpful advice of some people on this list).

Rebooting the system fixes the problem and the HDPVR records like a champ
for a x days, then develops the same problem and needs a reboot. As noted,
the mean of x seems to be decreasing.

An example log entry from when this happens is below. Any advice on how to
troubleshoot this?

May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E Scheduler
recordingprofile.cpp:162 (addSelection) SampleRate: Attempted to add a rate
32000 Hz, which is not in the x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I TVRecEvent
tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None to
RecordingOnly x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I TVRecEvent
mythdbcon.cpp:422 (PurgeIdleConnections) New DB connection, total: 11
x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I TVRecEvent
tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner: 1->1
x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I TVRecEvent
tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: C
CoreContext programinfo.cpp:351 (ProgramInfo) ProgramInfo(): Failed to find
recorded entry for 0. x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
scheduler.cpp:2819 (HandleRecordingStatusChange) Tuning recording: "PBS
NewsHour Weekend": channel 2008 onx
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
scheduler.cpp:2267 (HandleReschedule) Reschedule requested for PLACE
PrepareToRecord x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in 0.1 = 0.00
match + 0.00 check + 0.06 place x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
May 10 17:30:05 steve-EP45-UD3P mythbackend: mythbackend[889]: N Update
autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max required Free
Space: 3.0 GB w/freq: 15 min x
May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W TVRecEvent
tv_rec.cpp:4004 (TuningSignalCheck) TVRec[1]: TuningSignalCheck: taking
more than 15000 ms to get a lock.x
May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W TVRecEvent
tv_rec.cpp:4006 (TuningSignalCheck) TVRec[1]: See 'Tuning timeout' in
mythtv-setup for this input x
May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I
CoreContext scheduler.cpp:725 (UpdateRecStatus) Updating status for "PBS
NewsHour Weekend" on cardid 1 (Tuning => Fax
May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
scheduler.cpp:2267 (HandleReschedule) Reschedule requested for CHECK -14
208 0 UpdateRecStatus2 | PBS Newsx
May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in 0.1 = 0.00
match + 0.00 check + 0.06 place x
May 10 17:33:36 steve-EP45-UD3P mythbackend: mythbackend[889]: N Expire
autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max required Free
Space: 3.0 GB w/freq: 15 min x
May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
May 10 17:37:45 steve-EP45-UD3P mythbackend: mythbackend[889]: E
ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
PlaybackBoxHelper: CHECK_AVAILABILITY 'myth:/x
May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: I
PreviewGenerator mythcorecontext.cpp:1343 (SendReceiveStringList)
MythCoreContext::SendReceiveStringList(): x
May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
PreviewGenerator previewgenerator.cpp:387 (RemotePreviewRun) Preview:
Remote Preview failed due to communicax
Re: HDPVR intermittent failure [ In reply to ]
gregl at nycap
May 10, 2020, 7:58 PM
Post #2 of 67 (3506 views)
Permalink
On 5/10/20 10:37 PM, DryHeat122 . wrote:
> Hi all.  Hope you are surviving the apocalypse OK.
>
> I have a HDPVR as one of my recorders.  Recently, and with increasing
> frequency, recordings on it fail.  This is not the normal issue with
> the wall-wart failing as I am powering it from USB these days (thanks
> to the helpful advice of some people on this list).
>
> Rebooting the system fixes the problem and the HDPVR records like a
> champ for a x days, then develops the same problem and needs a
> reboot.  As noted, the mean of x seems to be decreasing.
>
> An example log entry from when this happens is below.  Any advice on
> how to troubleshoot this?
>
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> Scheduler recordingprofile.cpp:162 (addSelection) SampleRate:
> Attempted to add a rate 32000 Hz, which is not in the x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from
> None to RecordingOnly                        x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent mythdbcon.cpp:422 (PurgeIdleConnections) New DB connection,
> total: 11                            x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW
> Tuner: 1->1                                x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
>                              x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: C
> CoreContext programinfo.cpp:351 (ProgramInfo) ProgramInfo(): Failed to
> find recorded entry for 0.                   x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> Scheduler scheduler.cpp:2819 (HandleRecordingStatusChange) Tuning
> recording: "PBS NewsHour Weekend": channel 2008 onx
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> Scheduler scheduler.cpp:2267 (HandleReschedule) Reschedule requested
> for PLACE PrepareToRecord                      x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> Scheduler scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in
> 0.1 = 0.00 match + 0.00 check + 0.06 place   x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:30:05 steve-EP45-UD3P mythbackend: mythbackend[889]: N
> Update autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max
> required Free Space: 3.0 GB w/freq: 15 min     x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W
> TVRecEvent tv_rec.cpp:4004 (TuningSignalCheck) TVRec[1]:
> TuningSignalCheck: taking more than 15000 ms to get a lock.x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W
> TVRecEvent tv_rec.cpp:4006 (TuningSignalCheck) TVRec[1]: See 'Tuning
> timeout' in mythtv-setup for this input        x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> CoreContext scheduler.cpp:725 (UpdateRecStatus) Updating status for
> "PBS NewsHour Weekend" on cardid 1 (Tuning => Fax
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> Scheduler scheduler.cpp:2267 (HandleReschedule) Reschedule requested
> for CHECK -14 208 0 UpdateRecStatus2 | PBS Newsx
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> Scheduler scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in
> 0.1 = 0.00 match + 0.00 check + 0.06 place   x
> May 10 17:33:36 steve-EP45-UD3P mythbackend: mythbackend[889]: N
> Expire autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max
> required Free Space: 3.0 GB w/freq: 15 min     x
> May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:45 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'myth:/x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> I PreviewGenerator mythcorecontext.cpp:1343 (SendReceiveStringList)
> MythCoreContext::SendReceiveStringList(): x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]:
> E PreviewGenerator previewgenerator.cpp:387 (RemotePreviewRun)
> Preview: Remote Preview failed due to communicax
>
I looked up the amperage of a usb port and from what I see they only
provide 0.5 amps. The original HDPVR needed I think, 2.0 amps.. I really
think you should look there first. I put a moldex connector in my PC,
and run it off the main power supply.
https://www.mythtv.org/wiki/Mounting_the_HD-PVR_Internally I've run it
like this for well over 10 years..


> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
May 10, 2020, 8:20 PM
Post #3 of 67 (3506 views)
Permalink
On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:

>
> On 5/10/20 10:37 PM, DryHeat122 . wrote:
>
> Hi all. Hope you are surviving the apocalypse OK.
>
> I have a HDPVR as one of my recorders. Recently, and with increasing
> frequency, recordings on it fail. This is not the normal issue with the
> wall-wart failing as I am powering it from USB these days (thanks to the
> helpful advice of some people on this list).
>
> Rebooting the system fixes the problem and the HDPVR records like a champ
> for a x days, then develops the same problem and needs a reboot. As noted,
> the mean of x seems to be decreasing.
>
> An example log entry from when this happens is below. Any advice on how
> to troubleshoot this?
>
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:30:00 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E Scheduler
> recordingprofile.cpp:162 (addSelection) SampleRate: Attempted to add a rate
> 32000 Hz, which is not in the x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:1073 (HandleStateChange) TVRec[1]: Changing from None
> to RecordingOnly x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent mythdbcon.cpp:422 (PurgeIdleConnections) New DB connection,
> total: 11 x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:3563 (TuningCheckForHWChange) TVRec[1]: HW Tuner:
> 1->1 x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> TVRecEvent tv_rec.cpp:3685 (TuningFrequency) TVRec[1]: TuningFrequency
> x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: C
> CoreContext programinfo.cpp:351 (ProgramInfo) ProgramInfo(): Failed to find
> recorded entry for 0. x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
> scheduler.cpp:2819 (HandleRecordingStatusChange) Tuning recording: "PBS
> NewsHour Weekend": channel 2008 onx
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
> scheduler.cpp:2267 (HandleReschedule) Reschedule requested for PLACE
> PrepareToRecord x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
> scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in 0.1 = 0.00
> match + 0.00 check + 0.06 place x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:30:00 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:30:05 steve-EP45-UD3P mythbackend: mythbackend[889]: N Update
> autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max required Free
> Space: 3.0 GB w/freq: 15 min x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W
> TVRecEvent tv_rec.cpp:4004 (TuningSignalCheck) TVRec[1]: TuningSignalCheck:
> taking more than 15000 ms to get a lock.x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: W
> TVRecEvent tv_rec.cpp:4006 (TuningSignalCheck) TVRec[1]: See 'Tuning
> timeout' in mythtv-setup for this input x
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I
> CoreContext scheduler.cpp:725 (UpdateRecStatus) Updating status for "PBS
> NewsHour Weekend" on cardid 1 (Tuning => Fax
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
> scheduler.cpp:2267 (HandleReschedule) Reschedule requested for CHECK -14
> 208 0 UpdateRecStatus2 | PBS Newsx
> May 10 17:30:15 steve-EP45-UD3P mythbackend: mythbackend[889]: I Scheduler
> scheduler.cpp:2380 (HandleReschedule) Scheduled 176 items in 0.1 = 0.00
> match + 0.00 check + 0.06 place x
> May 10 17:33:36 steve-EP45-UD3P mythbackend: mythbackend[889]: N Expire
> autoexpire.cpp:264 (CalcParams) AutoExpire: CalcParams(): Max required Free
> Space: 3.0 GB w/freq: 15 min x
> May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:32 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:36 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL:x
> May 10 17:37:39 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'GetPlax
> May 10 17:37:45 steve-EP45-UD3P mythbackend: mythbackend[889]: E
> ProcessRequest programinfo.cpp:2594 (GetPlaybackURL)
> ProgramInfo(2008_20200511003000.ts): GetPlaybackURL: '2008_2020x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PlaybackBoxHelper playbackboxhelper.cpp:88 (CheckAvailability)
> PlaybackBoxHelper: CHECK_AVAILABILITY 'myth:/x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: I
> PreviewGenerator mythcorecontext.cpp:1343 (SendReceiveStringList)
> MythCoreContext::SendReceiveStringList(): x
> May 10 17:37:46 steve-EP45-UD3P mythfrontend.real: mythfrontend[2065]: E
> PreviewGenerator previewgenerator.cpp:387 (RemotePreviewRun) Preview:
> Remote Preview failed due to communicax
>
> I looked up the amperage of a usb port and from what I see they only
> provide 0.5 amps. The original HDPVR needed I think, 2.0 amps.. I really
> think you should look there first. I put a moldex connector in my PC, and
> run it off the main power supply.
> https://www.mythtv.org/wiki/Mounting_the_HD-PVR_Internally I've run it
> like this for well over 10 years..
>
>
> _______________________________________________
> mythtv-users mailing listmythtv-users@mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.or <https://forum.mythtv.org>
>
>
>
Ok thanks I will investigate that. But it's been working fine with the
current power source for like a year now, and others on this list use it
too. Is there anything else it could be?
Re: HDPVR intermittent failure [ In reply to ]
stephen_agent at jsw
May 11, 2020, 2:40 AM
Post #4 of 67 (3501 views)
Permalink
On Sun, 10 May 2020 20:20:30 -0700, you wrote:

>On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:

>Ok thanks I will investigate that. But it's been working fine with the
>current power source for like a year now, and others on this list use it
>too.

USB cables often fit badly into the sockets. If so, the connection
generally gets worse over time as you get dirt or oxidisation on the
contacts. So badly fitting cables will degrade with time. The result
is that the voltage drop across the cable will increase markedly. And
they can be too thin - the amount of copper in the wires is too little
and that causes high resistance and a big voltage drop across the
length of the cable. Some (most?) USB cables are designed only for
data transmission, or to run very low power devices. For a high power
device, you need a better (thicker) cable. The high power devices do
a negotiation with device supplying the power and request high power
mode. If the cable is not capable of high power, that negotiation is
not supposed to work and the device should either only work in low
power mode or it should turn itself off. But USB cable makers often
make cables not capable of high power transmission that will allow the
high power mode negotiation to succeed. So even though the device
supplying the power is sending high current, the voltage drop in the
cable means that at the other end, the voltage can be below the level
required for proper operation or to fully charge the device's battery.

I have had two notably bad experiences with USB cables. One was a USB
DVB-T tuner, and it was very like your experience - it would go for a
number of days just fine, then suddenly stop. If I unplugged it and
plugged it in again, it would usually work again. When I finally
investigated properly, I found the cable was just a little loose in
the PC's socket. I replaced the cable with one that fit more tightly
and the tuner was much more reliable. It still occasionally caused
trouble, but only when I had bumped the cables (or in one case, after
we had a small earthquake). So because of that and because I needed
more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
tuner PCIe card.

The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
USB charging cable was supplied with it by Samsung, so I assumed it
was a good one. But right from the start, the tablet took a long time
to charge, and the time gradually got longer and longer and the
battery life on one charge was getting less and less. And then I
started to have to jiggle the cable in the socket to get it to charge
at all. I actually called the Samsung help line about this, and they
said it sounds like a bad cable. So I bought a expensive (NZ$30)
Pudney & Lee charging cable, which was a fair bit longer than the old
Samsung cable, but fit very tightly at both ends and was significantly
thicker - it has more copper in the wires in the cable. Then suddenly
the battery charging times were what was specified for the tablet,
rather than three times as long. And over a number of charging
cycles, the battery life came back again. So the original Samsung
supplied cable was clearly bad from the start - it is probably less
than the specification required to charge the tablet properly as it is
too thin and has too much voltage drop even when the plugs fit
properly. So definitely NZ$30 well spent. But I am surprised that a
reputable company like Samsung would supply a bad cable with an
expensive top-of-the-line product like my tablet. But they did - so
now I always suspect any USB cable I get and keep an eye on how well
it is working.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
May 11, 2020, 12:59 PM
Post #5 of 67 (3498 views)
Permalink
On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
stephen_agent@jsw.gen.nz> wrote:

> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>
> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
>
> >Ok thanks I will investigate that. But it's been working fine with the
> >current power source for like a year now, and others on this list use it
> >too.
>
> USB cables often fit badly into the sockets. If so, the connection
> generally gets worse over time as you get dirt or oxidisation on the
> contacts. So badly fitting cables will degrade with time. The result
> is that the voltage drop across the cable will increase markedly. And
> they can be too thin - the amount of copper in the wires is too little
> and that causes high resistance and a big voltage drop across the
> length of the cable. Some (most?) USB cables are designed only for
> data transmission, or to run very low power devices. For a high power
> device, you need a better (thicker) cable. The high power devices do
> a negotiation with device supplying the power and request high power
> mode. If the cable is not capable of high power, that negotiation is
> not supposed to work and the device should either only work in low
> power mode or it should turn itself off. But USB cable makers often
> make cables not capable of high power transmission that will allow the
> high power mode negotiation to succeed. So even though the device
> supplying the power is sending high current, the voltage drop in the
> cable means that at the other end, the voltage can be below the level
> required for proper operation or to fully charge the device's battery.
>
> I have had two notably bad experiences with USB cables. One was a USB
> DVB-T tuner, and it was very like your experience - it would go for a
> number of days just fine, then suddenly stop. If I unplugged it and
> plugged it in again, it would usually work again. When I finally
> investigated properly, I found the cable was just a little loose in
> the PC's socket. I replaced the cable with one that fit more tightly
> and the tuner was much more reliable. It still occasionally caused
> trouble, but only when I had bumped the cables (or in one case, after
> we had a small earthquake). So because of that and because I needed
> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
> tuner PCIe card.
>
> The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
> USB charging cable was supplied with it by Samsung, so I assumed it
> was a good one. But right from the start, the tablet took a long time
> to charge, and the time gradually got longer and longer and the
> battery life on one charge was getting less and less. And then I
> started to have to jiggle the cable in the socket to get it to charge
> at all. I actually called the Samsung help line about this, and they
> said it sounds like a bad cable. So I bought a expensive (NZ$30)
> Pudney & Lee charging cable, which was a fair bit longer than the old
> Samsung cable, but fit very tightly at both ends and was significantly
> thicker - it has more copper in the wires in the cable. Then suddenly
> the battery charging times were what was specified for the tablet,
> rather than three times as long. And over a number of charging
> cycles, the battery life came back again. So the original Samsung
> supplied cable was clearly bad from the start - it is probably less
> than the specification required to charge the tablet properly as it is
> too thin and has too much voltage drop even when the plugs fit
> properly. So definitely NZ$30 well spent. But I am surprised that a
> reputable company like Samsung would supply a bad cable with an
> expensive top-of-the-line product like my tablet. But they did - so
> now I always suspect any USB cable I get and keep an eye on how well
> it is working.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org


Thanks for all the suggestions. I will investigate all of them. Something
I do not see in here is an opinion that some software problem could have
evolved. I was kind of thinking of that as a possibility given that it
worked fine for so long then seems to be degrading. OTOH I never thought
of the possibility that the USB connection could be degrading. I'm going
to try Greg's connector, assuming I can get parts during the Apocalypse.
Also, his link specifies Radio Shack parts. What's Radio Shack?!? ;-)
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jun 27, 2020, 6:46 PM
Post #6 of 67 (3435 views)
Permalink
On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com> wrote:

> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
>
>> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>
>> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
>>
>> >Ok thanks I will investigate that. But it's been working fine with the
>> >current power source for like a year now, and others on this list use it
>> >too.
>>
>> USB cables often fit badly into the sockets. If so, the connection
>> generally gets worse over time as you get dirt or oxidisation on the
>> contacts. So badly fitting cables will degrade with time. The result
>> is that the voltage drop across the cable will increase markedly. And
>> they can be too thin - the amount of copper in the wires is too little
>> and that causes high resistance and a big voltage drop across the
>> length of the cable. Some (most?) USB cables are designed only for
>> data transmission, or to run very low power devices. For a high power
>> device, you need a better (thicker) cable. The high power devices do
>> a negotiation with device supplying the power and request high power
>> mode. If the cable is not capable of high power, that negotiation is
>> not supposed to work and the device should either only work in low
>> power mode or it should turn itself off. But USB cable makers often
>> make cables not capable of high power transmission that will allow the
>> high power mode negotiation to succeed. So even though the device
>> supplying the power is sending high current, the voltage drop in the
>> cable means that at the other end, the voltage can be below the level
>> required for proper operation or to fully charge the device's battery.
>>
>> I have had two notably bad experiences with USB cables. One was a USB
>> DVB-T tuner, and it was very like your experience - it would go for a
>> number of days just fine, then suddenly stop. If I unplugged it and
>> plugged it in again, it would usually work again. When I finally
>> investigated properly, I found the cable was just a little loose in
>> the PC's socket. I replaced the cable with one that fit more tightly
>> and the tuner was much more reliable. It still occasionally caused
>> trouble, but only when I had bumped the cables (or in one case, after
>> we had a small earthquake). So because of that and because I needed
>> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
>> tuner PCIe card.
>>
>> The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
>> USB charging cable was supplied with it by Samsung, so I assumed it
>> was a good one. But right from the start, the tablet took a long time
>> to charge, and the time gradually got longer and longer and the
>> battery life on one charge was getting less and less. And then I
>> started to have to jiggle the cable in the socket to get it to charge
>> at all. I actually called the Samsung help line about this, and they
>> said it sounds like a bad cable. So I bought a expensive (NZ$30)
>> Pudney & Lee charging cable, which was a fair bit longer than the old
>> Samsung cable, but fit very tightly at both ends and was significantly
>> thicker - it has more copper in the wires in the cable. Then suddenly
>> the battery charging times were what was specified for the tablet,
>> rather than three times as long. And over a number of charging
>> cycles, the battery life came back again. So the original Samsung
>> supplied cable was clearly bad from the start - it is probably less
>> than the specification required to charge the tablet properly as it is
>> too thin and has too much voltage drop even when the plugs fit
>> properly. So definitely NZ$30 well spent. But I am surprised that a
>> reputable company like Samsung would supply a bad cable with an
>> expensive top-of-the-line product like my tablet. But they did - so
>> now I always suspect any USB cable I get and keep an eye on how well
>> it is working.
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
>
> Thanks for all the suggestions. I will investigate all of them.
> Something I do not see in here is an opinion that some software problem
> could have evolved. I was kind of thinking of that as a possibility given
> that it worked fine for so long then seems to be degrading. OTOH I never
> thought of the possibility that the USB connection could be degrading. I'm
> going to try Greg's connector, assuming I can get parts during the
> Apocalypse. Also, his link specifies Radio Shack parts. What's Radio
> Shack?!? ;-)
>

Well folks this is getting frustrating. I addressed a possible ventilation
issue. I also unplugged the power cord I had from the Myth box USB and
connected it to an old iPad charger rated at 5V/2A. No help. It wouldn't
record anything, no matter how much rebooting and power-cycling. So I
concluded the HDPVR was hosed and got a new one (more accurately, a
replacement circuit board for it). Powered it with the same wall wart.
Recorded great for a day. Just turned it on and I have failed recordings
and it won't respond when I try to manually play a channel. Reboot, and it
works fine, same pattern as before.

I finally got a molex connector and am still going to try what Greg
suggested, but I really don't think it's a power issue. Apply makes good
electronics and that wart has the same specs as the power supply that comes
with the HDPVR. The HDPCR isn't overheating. It's not the HDPVR itself.
That only leaves the software on the myth box. Anyone have ideas how to
troubleshoot that?
Re: HDPVR intermittent failure [ In reply to ]
glenb at glenb
Jun 27, 2020, 7:50 PM
Post #7 of 67 (3435 views)
Permalink
On Sat, 2020-06-27 at 18:46 -0700, DryHeat122 . wrote:
> On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com>
> wrote:
> > On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
> > stephen_agent@jsw.gen.nz> wrote:
> > > On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> > >
> > >
> > >
> > > >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
> > >
> > >
> > >
> > > >Ok thanks I will investigate that. But it's been working fine
> > > with the
> > >
> > > >current power source for like a year now, and others on this
> > > list use it
> > >
> > > >too.
> > >
> > >
> > >
> > > USB cables often fit badly into the sockets. If so, the
> > > connection
> > >
> > > generally gets worse over time as you get dirt or oxidisation on
> > > the
> > >
> > > contacts. So badly fitting cables will degrade with time. The
> > > result
> > >
> > > is that the voltage drop across the cable will increase
> > > markedly. And
> > >
> > > they can be too thin - the amount of copper in the wires is too
> > > little
> > >
> > > and that causes high resistance and a big voltage drop across the
> > >
> > > length of the cable. Some (most?) USB cables are designed only
> > > for
> > >
> > > data transmission, or to run very low power devices. For a high
> > > power
> > >
> > > device, you need a better (thicker) cable. The high power
> > > devices do
> > >
> > > a negotiation with device supplying the power and request high
> > > power
> > >
> > > mode. If the cable is not capable of high power, that
> > > negotiation is
> > >
> > > not supposed to work and the device should either only work in
> > > low
> > >
> > > power mode or it should turn itself off. But USB cable makers
> > > often
> > >
> > > make cables not capable of high power transmission that will
> > > allow the
> > >
> > > high power mode negotiation to succeed. So even though the
> > > device
> > >
> > > supplying the power is sending high current, the voltage drop in
> > > the
> > >
> > > cable means that at the other end, the voltage can be below the
> > > level
> > >
> > > required for proper operation or to fully charge the device's
> > > battery.
> > >
> > >
> > >
> > > I have had two notably bad experiences with USB cables. One was
> > > a USB
> > >
> > > DVB-T tuner, and it was very like your experience - it would go
> > > for a
> > >
> > > number of days just fine, then suddenly stop. If I unplugged it
> > > and
> > >
> > > plugged it in again, it would usually work again. When I finally
> > >
> > > investigated properly, I found the cable was just a little loose
> > > in
> > >
> > > the PC's socket. I replaced the cable with one that fit more
> > > tightly
> > >
> > > and the tuner was much more reliable. It still occasionally
> > > caused
> > >
> > > trouble, but only when I had bumped the cables (or in one case,
> > > after
> > >
> > > we had a small earthquake). So because of that and because I
> > > needed
> > >
> > > more DVB-T tuners, I finally replaced all my DVB-T tuners with an
> > > 8
> > >
> > > tuner PCIe card.
> > >
> > >
> > >
> > > The second bad experience was my Samsung Galaxy Tab S2 tablet.
> > > Its
> > >
> > > USB charging cable was supplied with it by Samsung, so I assumed
> > > it
> > >
> > > was a good one. But right from the start, the tablet took a long
> > > time
> > >
> > > to charge, and the time gradually got longer and longer and the
> > >
> > > battery life on one charge was getting less and less. And then I
> > >
> > > started to have to jiggle the cable in the socket to get it to
> > > charge
> > >
> > > at all. I actually called the Samsung help line about this, and
> > > they
> > >
> > > said it sounds like a bad cable. So I bought a expensive (NZ$30)
> > >
> > > Pudney & Lee charging cable, which was a fair bit longer than the
> > > old
> > >
> > > Samsung cable, but fit very tightly at both ends and was
> > > significantly
> > >
> > > thicker - it has more copper in the wires in the cable. Then
> > > suddenly
> > >
> > > the battery charging times were what was specified for the
> > > tablet,
> > >
> > > rather than three times as long. And over a number of charging
> > >
> > > cycles, the battery life came back again. So the original
> > > Samsung
> > >
> > > supplied cable was clearly bad from the start - it is probably
> > > less
> > >
> > > than the specification required to charge the tablet properly as
> > > it is
> > >
> > > too thin and has too much voltage drop even when the plugs fit
> > >
> > > properly. So definitely NZ$30 well spent. But I am surprised
> > > that a
> > >
> > > reputable company like Samsung would supply a bad cable with an
> > >
> > > expensive top-of-the-line product like my tablet. But they did -
> > > so
> > >
> > > now I always suspect any USB cable I get and keep an eye on how
> > > well
> > >
> > > it is working.
> > >
> > > _______________________________________________
> > >
> > > mythtv-users mailing list
> > >
> > > mythtv-users@mythtv.org
> > >
> > > http://email.mg.glenb.net/c/eJxNTksKwyAUPE3cVUz8xYWLbnoP9fkSQW2JttDb15ZCC8PA_GDABnQgBUkW_BwAdHCDvDcoEA3AEkAtqJjUUQkZGTIaXIl5EmzLsXpaYye7ZU4aBdzgvJqVz2vEgCYGoYFr7g0j2e693yZ-npbLQE6tN1qefe8Pej22YRWXcnH1G6aK17f5aZzuLR6NHPZfjge__QuyVkHw
> > >
> > > http://email.mg.glenb.net/c/eJxFjTsOwjAQRE8Td1h2_AkpXNBQwRki27tOLJwAyQbE7bFEgTR6xeiNBlxMHoxm2UGQEaCLviKEPumUeoA2gm2TFaZDqw2KJHj0M5ZGi7HgEviCxCZnlfe9DTrFVKVOGZQymADyCMIogay4iejRqFPTnmve-Zb5_KGJXvy-jrW5-lzyMg6XvNGAlJ87EiFb3c867BuuW339j77f2j4X
> > >
> > > MythTV Forums: http://email.mg.glenb.net/c/eJxFjMsKwyAUBb8m7ipGrzFZuOim_6H3kRTyKMYU-vcVuigMB4YDQxElkQf1jJR7JAqY2uQ8CYhMRBZpsDIYH3gAz0aMxrTx2oGZV96z3rmqJbKMoycnCMxICV2eOEBolm0PTtQal1pfZ-funX005CjXprdPXepbH2VWJf7kdp1czpb_f1_9hDZF
> >
> > Thanks for all the suggestions. I will investigate all of them.
> > Something I do not see in here is an opinion that some software
> > problem could have evolved. I was kind of thinking of that as a
> > possibility given that it worked fine for so long then seems to be
> > degrading. OTOH I never thought of the possibility that the USB
> > connection could be degrading. I'm going to try Greg's connector,
> > assuming I can get parts during the Apocalypse. Also, his link
> > specifies Radio Shack parts. What's Radio Shack?!? ;-)
>
> Well folks this is getting frustrating. I addressed a possible
> ventilation issue. I also unplugged the power cord I had from the
> Myth box USB and connected it to an old iPad charger rated at 5V/2A.
> No help. It wouldn't record anything, no matter how much rebooting
> and power-cycling. So I concluded the HDPVR was hosed and got a new
> one (more accurately, a replacement circuit board for it). Powered
> it with the same wall wart. Recorded great for a day. Just turned
> it on and I have failed recordings and it won't respond when I try to
> manually play a channel. Reboot, and it works fine, same pattern as
> before.
>
> I finally got a molex connector and am still going to try what Greg
> suggested, but I really don't think it's a power issue. Apply makes
> good electronics and that wart has the same specs as the power supply
> that comes with the HDPVR. The HDPCR isn't overheating. It's not
> the HDPVR itself. That only leaves the software on the myth box.
> Anyone have ideas how to troubleshoot that?
>
>
> _______________________________________________mythtv-users mailing
> listmythtv-users@mythtv.org
> http://email.mg.glenb.net/c/eJxNTksKwyAUPE3cVUz8xYWLbnoP9fkSQW2JttDb15ZCC8PA_GDABnQgBUkW_BwAdHCDvDcoEA3AEkAtqJjUUQkZGTIaXIl5EmzLsXpaYye7ZU4aBdzgvJqVz2vEgCYGoYFr7g0j2e693yZ-npbLQE6tN1qefe8Pej22YRWXcnH1G6aK17f5aZzuLR6NHPZfjge__QuyVkHw
> http://email.mg.glenb.net/c/eJxFjTsOwjAQRE8Td1h2_AkpXNBQwRki27tOLJwAyQbE7bFEgTR6xeiNBlxMHoxm2UGQEaCLviKEPumUeoA2gm2TFaZDqw2KJHj0M5ZGi7HgEviCxCZnlfe9DTrFVKVOGZQymADyCMIogay4iejRqFPTnmve-Zb5_KGJXvy-jrW5-lzyMg6XvNGAlJ87EiFb3c867BuuW339j77f2j4X
> MythTV Forums: http://email.mg.glenb.net/c/eJxFjMsKwyAUBb8m7ipGrzFZuOim_6H3kRTyKMYU-vcVuigMB4YDQxElkQf1jJR7JAqY2uQ8CYhMRBZpsDIYH3gAz0aMxrTx2oGZV96z3rmqJbKMoycnCMxICV2eOEBolm0PTtQal1pfZ-funX005CjXprdPXepbH2VWJf7kdp1czpb_f1_9hDZF

have you tried a conf file in /etc/modprobe.d setting this option:
options ir-kbd-i2c enable_hdpvr=1
Re: HDPVR intermittent failure [ In reply to ]
gregl at nycap
Jun 28, 2020, 9:31 AM
Post #8 of 67 (3428 views)
Permalink
On 6/27/20 9:46 PM, DryHeat122 . wrote:
> On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com
> <mailto:dryheat122@gmail.com>> wrote:
>
> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
> <stephen_agent@jsw.gen.nz <mailto:stephen_agent@jsw.gen.nz>> wrote:
>
> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>
> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>> wrote:
>
> >Ok thanks I will investigate that.  But it's been working
> fine with the
> >current power source for like a year now, and others on this
> list use it
> >too.
>
> USB cables often fit badly into the sockets.  If so, the
> connection
> generally gets worse over time as you get dirt or oxidisation
> on the
> contacts.  So badly fitting cables will degrade with time. 
> The result
> is that the voltage drop across the cable will increase
> markedly.  And
> they can be too thin - the amount of copper in the wires is
> too little
> and that causes high resistance and a big voltage drop across the
> length of the cable.  Some (most?) USB cables are designed
> only for
> data transmission, or to run very low power devices. For a
> high power
> device, you need a better (thicker) cable.  The high power
> devices do
> a negotiation with device supplying the power and request high
> power
> mode.  If the cable is not capable of high power, that
> negotiation is
> not supposed to work and the device should either only work in low
> power mode or it should turn itself off.  But USB cable makers
> often
> make cables not capable of high power transmission that will
> allow the
> high power mode negotiation to succeed.  So even though the device
> supplying the power is sending high current, the voltage drop
> in the
> cable means that at the other end, the voltage can be below
> the level
> required for proper operation or to fully charge the device's
> battery.
>
> I have had two notably bad experiences with USB cables.  One
> was a USB
> DVB-T tuner, and it was very like your experience - it would
> go for a
> number of days just fine, then suddenly stop.  If I unplugged
> it and
> plugged it in again, it would usually work again. When I finally
> investigated properly, I found the cable was just a little
> loose in
> the PC's socket.  I replaced the cable with one that fit more
> tightly
> and the tuner was much more reliable.  It still occasionally
> caused
> trouble, but only when I had bumped the cables (or in one
> case, after
> we had a small earthquake).  So because of that and because I
> needed
> more DVB-T tuners, I finally replaced all my DVB-T tuners with
> an 8
> tuner PCIe card.
>
> The second bad experience was my Samsung Galaxy Tab S2
> tablet.  Its
> USB charging cable was supplied with it by Samsung, so I
> assumed it
> was a good one.  But right from the start, the tablet took a
> long time
> to charge, and the time gradually got longer and longer and the
> battery life on one charge was getting less and less. And then I
> started to have to jiggle the cable in the socket to get it to
> charge
> at all.  I actually called the Samsung help line about this,
> and they
> said it sounds like a bad cable.  So I bought a expensive (NZ$30)
> Pudney & Lee charging cable, which was a fair bit longer than
> the old
> Samsung cable, but fit very tightly at both ends and was
> significantly
> thicker - it has more copper in the wires in the cable.  Then
> suddenly
> the battery charging times were what was specified for the tablet,
> rather than three times as long.  And over a number of charging
> cycles, the battery life came back again.  So the original Samsung
> supplied cable was clearly bad from the start - it is probably
> less
> than the specification required to charge the tablet properly
> as it is
> too thin and has too much voltage drop even when the plugs fit
> properly.  So definitely NZ$30 well spent.  But I am surprised
> that a
> reputable company like Samsung would supply a bad cable with an
> expensive top-of-the-line product like my tablet.  But they
> did - so
> now I always suspect any USB cable I get and keep an eye on
> how well
> it is working.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org <mailto:mythtv-users@mythtv.org>
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
>
> Thanks for all the suggestions.  I will investigate all of them. 
> Something I do not see in here is an opinion that some software
> problem could have evolved.  I was kind of thinking of that as a
> possibility given that it worked fine for so long then seems to be
> degrading.  OTOH I never thought of the possibility that the USB
> connection could be degrading.  I'm going to try Greg's connector,
> assuming I can get parts during the Apocalypse.  Also, his link
> specifies Radio Shack parts.  What's Radio Shack?!? ;-)
>
>
> Well folks this is getting frustrating.  I addressed a possible
> ventilation issue.  I also unplugged the power cord I had from the
> Myth box USB and connected it to an old iPad charger rated at 5V/2A. 
> No help.  It wouldn't record anything, no matter how much rebooting
> and power-cycling. So I concluded the HDPVR was hosed and got a new
> one (more accurately, a replacement circuit board for it).  Powered it
> with the same wall wart.  Recorded great for a day.  Just turned it on
> and I have failed recordings and it won't respond when I try to
> manually play a channel.  Reboot, and it works fine, same pattern as
> before.
>
> I finally got a molex connector and am still going to try what Greg
> suggested, but I really don't think it's a power issue.  Apply makes
> good electronics and that wart has the same specs as the power supply
> that comes with the HDPVR. The HDPCR isn't overheating.  It's not the
> HDPVR itself. That only leaves the software on the myth box.  Anyone
> have ideas how to troubleshoot that?
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

 The next time it won't record,try to cat it and see if it responds. 
This is the command I use,  cat /dev/video0 > test .. dmesg for the
proper port it's connected to. This may help too see if it is the
software or not..

I am curious were you got the motherboard? There used to be a place in
Ohio (I believe) ,but they have gone out of business.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jun 28, 2020, 9:45 AM
Post #9 of 67 (3428 views)
Permalink
On Sat, Jun 27, 2020 at 7:51 PM glen <glenb@glenb.net> wrote:

> On Sat, 2020-06-27 at 18:46 -0700, DryHeat122 . wrote:
>
> On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com>
> wrote:
>
> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
> stephen_agent@jsw.gen.nz> wrote:
>
> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>
> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
>
> >Ok thanks I will investigate that. But it's been working fine with the
> >current power source for like a year now, and others on this list use it
> >too.
>
> USB cables often fit badly into the sockets. If so, the connection
> generally gets worse over time as you get dirt or oxidisation on the
> contacts. So badly fitting cables will degrade with time. The result
> is that the voltage drop across the cable will increase markedly. And
> they can be too thin - the amount of copper in the wires is too little
> and that causes high resistance and a big voltage drop across the
> length of the cable. Some (most?) USB cables are designed only for
> data transmission, or to run very low power devices. For a high power
> device, you need a better (thicker) cable. The high power devices do
> a negotiation with device supplying the power and request high power
> mode. If the cable is not capable of high power, that negotiation is
> not supposed to work and the device should either only work in low
> power mode or it should turn itself off. But USB cable makers often
> make cables not capable of high power transmission that will allow the
> high power mode negotiation to succeed. So even though the device
> supplying the power is sending high current, the voltage drop in the
> cable means that at the other end, the voltage can be below the level
> required for proper operation or to fully charge the device's battery.
>
> I have had two notably bad experiences with USB cables. One was a USB
> DVB-T tuner, and it was very like your experience - it would go for a
> number of days just fine, then suddenly stop. If I unplugged it and
> plugged it in again, it would usually work again. When I finally
> investigated properly, I found the cable was just a little loose in
> the PC's socket. I replaced the cable with one that fit more tightly
> and the tuner was much more reliable. It still occasionally caused
> trouble, but only when I had bumped the cables (or in one case, after
> we had a small earthquake). So because of that and because I needed
> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
> tuner PCIe card.
>
> The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
> USB charging cable was supplied with it by Samsung, so I assumed it
> was a good one. But right from the start, the tablet took a long time
> to charge, and the time gradually got longer and longer and the
> battery life on one charge was getting less and less. And then I
> started to have to jiggle the cable in the socket to get it to charge
> at all. I actually called the Samsung help line about this, and they
> said it sounds like a bad cable. So I bought a expensive (NZ$30)
> Pudney & Lee charging cable, which was a fair bit longer than the old
> Samsung cable, but fit very tightly at both ends and was significantly
> thicker - it has more copper in the wires in the cable. Then suddenly
> the battery charging times were what was specified for the tablet,
> rather than three times as long. And over a number of charging
> cycles, the battery life came back again. So the original Samsung
> supplied cable was clearly bad from the start - it is probably less
> than the specification required to charge the tablet properly as it is
> too thin and has too much voltage drop even when the plugs fit
> properly. So definitely NZ$30 well spent. But I am surprised that a
> reputable company like Samsung would supply a bad cable with an
> expensive top-of-the-line product like my tablet. But they did - so
> now I always suspect any USB cable I get and keep an eye on how well
> it is working.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> <http://email.mg.glenb.net/c/eJxNTksKwyAUPE3cVUz8xYWLbnoP9fkSQW2JttDb15ZCC8PA_GDABnQgBUkW_BwAdHCDvDcoEA3AEkAtqJjUUQkZGTIaXIl5EmzLsXpaYye7ZU4aBdzgvJqVz2vEgCYGoYFr7g0j2e693yZ-npbLQE6tN1qefe8Pej22YRWXcnH1G6aK17f5aZzuLR6NHPZfjge__QuyVkHw>
> http://wiki.mythtv.org/Mailing_List_etiquette
> <http://email.mg.glenb.net/c/eJxFjTsOwjAQRE8Td1h2_AkpXNBQwRki27tOLJwAyQbE7bFEgTR6xeiNBlxMHoxm2UGQEaCLviKEPumUeoA2gm2TFaZDqw2KJHj0M5ZGi7HgEviCxCZnlfe9DTrFVKVOGZQymADyCMIogay4iejRqFPTnmve-Zb5_KGJXvy-jrW5-lzyMg6XvNGAlJ87EiFb3c867BuuW339j77f2j4X>
> MythTV Forums: https://forum.mythtv.org
> <http://email.mg.glenb.net/c/eJxFjMsKwyAUBb8m7ipGrzFZuOim_6H3kRTyKMYU-vcVuigMB4YDQxElkQf1jJR7JAqY2uQ8CYhMRBZpsDIYH3gAz0aMxrTx2oGZV96z3rmqJbKMoycnCMxICV2eOEBolm0PTtQal1pfZ-funX005CjXprdPXepbH2VWJf7kdp1czpb_f1_9hDZF>
>
>
> Thanks for all the suggestions. I will investigate all of them.
> Something I do not see in here is an opinion that some software problem
> could have evolved. I was kind of thinking of that as a possibility given
> that it worked fine for so long then seems to be degrading. OTOH I never
> thought of the possibility that the USB connection could be degrading. I'm
> going to try Greg's connector, assuming I can get parts during the
> Apocalypse. Also, his link specifies Radio Shack parts. What's Radio
> Shack?!? ;-)
>
>
> Well folks this is getting frustrating. I addressed a possible
> ventilation issue. I also unplugged the power cord I had from the Myth box
> USB and connected it to an old iPad charger rated at 5V/2A. No help. It
> wouldn't record anything, no matter how much rebooting and power-cycling.
> So I concluded the HDPVR was hosed and got a new one (more accurately, a
> replacement circuit board for it). Powered it with the same wall wart.
> Recorded great for a day. Just turned it on and I have failed recordings
> and it won't respond when I try to manually play a channel. Reboot, and it
> works fine, same pattern as before.
>
> I finally got a molex connector and am still going to try what Greg
> suggested, but I really don't think it's a power issue. Apply makes good
> electronics and that wart has the same specs as the power supply that comes
> with the HDPVR. The HDPCR isn't overheating. It's not the HDPVR itself.
> That only leaves the software on the myth box. Anyone have ideas how to
> troubleshoot that?
>
> _______________________________________________
>
> mythtv-users mailing list
>
> mythtv-users@mythtv.org
>
>
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>
>
> <http://email.mg.glenb.net/c/eJxNTksKwyAUPE3cVUz8xYWLbnoP9fkSQW2JttDb15ZCC8PA_GDABnQgBUkW_BwAdHCDvDcoEA3AEkAtqJjUUQkZGTIaXIl5EmzLsXpaYye7ZU4aBdzgvJqVz2vEgCYGoYFr7g0j2e693yZ-npbLQE6tN1qefe8Pej22YRWXcnH1G6aK17f5aZzuLR6NHPZfjge__QuyVkHw>
>
>
> http://wiki.mythtv.org/Mailing_List_etiquette
>
>
> <http://email.mg.glenb.net/c/eJxFjTsOwjAQRE8Td1h2_AkpXNBQwRki27tOLJwAyQbE7bFEgTR6xeiNBlxMHoxm2UGQEaCLviKEPumUeoA2gm2TFaZDqw2KJHj0M5ZGi7HgEviCxCZnlfe9DTrFVKVOGZQymADyCMIogay4iejRqFPTnmve-Zb5_KGJXvy-jrW5-lzyMg6XvNGAlJ87EiFb3c867BuuW339j77f2j4X>
>
>
> MythTV Forums:
>
> https://forum.mythtv.org
>
>
> <http://email.mg.glenb.net/c/eJxFjMsKwyAUBb8m7ipGrzFZuOim_6H3kRTyKMYU-vcVuigMB4YDQxElkQf1jJR7JAqY2uQ8CYhMRBZpsDIYH3gAz0aMxrTx2oGZV96z3rmqJbKMoycnCMxICV2eOEBolm0PTtQal1pfZ-funX005CjXprdPXepbH2VWJf7kdp1czpb_f1_9hDZF>
>
>
> have you tried a conf file in /etc/modprobe.d setting this option:
>
>
> options ir-kbd-i2c enable_hdpvr=1
>
>
> No. does ir-kbd stand for infrared keyboard? I don't have one of those.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jun 28, 2020, 9:46 AM
Post #10 of 67 (3428 views)
Permalink
On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com> wrote:

>
> On 6/27/20 9:46 PM, DryHeat122 . wrote:
>
> On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com>
> wrote:
>
>> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>>
>>> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>
>>> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
>>>
>>> >Ok thanks I will investigate that. But it's been working fine with the
>>> >current power source for like a year now, and others on this list use it
>>> >too.
>>>
>>> USB cables often fit badly into the sockets. If so, the connection
>>> generally gets worse over time as you get dirt or oxidisation on the
>>> contacts. So badly fitting cables will degrade with time. The result
>>> is that the voltage drop across the cable will increase markedly. And
>>> they can be too thin - the amount of copper in the wires is too little
>>> and that causes high resistance and a big voltage drop across the
>>> length of the cable. Some (most?) USB cables are designed only for
>>> data transmission, or to run very low power devices. For a high power
>>> device, you need a better (thicker) cable. The high power devices do
>>> a negotiation with device supplying the power and request high power
>>> mode. If the cable is not capable of high power, that negotiation is
>>> not supposed to work and the device should either only work in low
>>> power mode or it should turn itself off. But USB cable makers often
>>> make cables not capable of high power transmission that will allow the
>>> high power mode negotiation to succeed. So even though the device
>>> supplying the power is sending high current, the voltage drop in the
>>> cable means that at the other end, the voltage can be below the level
>>> required for proper operation or to fully charge the device's battery.
>>>
>>> I have had two notably bad experiences with USB cables. One was a USB
>>> DVB-T tuner, and it was very like your experience - it would go for a
>>> number of days just fine, then suddenly stop. If I unplugged it and
>>> plugged it in again, it would usually work again. When I finally
>>> investigated properly, I found the cable was just a little loose in
>>> the PC's socket. I replaced the cable with one that fit more tightly
>>> and the tuner was much more reliable. It still occasionally caused
>>> trouble, but only when I had bumped the cables (or in one case, after
>>> we had a small earthquake). So because of that and because I needed
>>> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
>>> tuner PCIe card.
>>>
>>> The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
>>> USB charging cable was supplied with it by Samsung, so I assumed it
>>> was a good one. But right from the start, the tablet took a long time
>>> to charge, and the time gradually got longer and longer and the
>>> battery life on one charge was getting less and less. And then I
>>> started to have to jiggle the cable in the socket to get it to charge
>>> at all. I actually called the Samsung help line about this, and they
>>> said it sounds like a bad cable. So I bought a expensive (NZ$30)
>>> Pudney & Lee charging cable, which was a fair bit longer than the old
>>> Samsung cable, but fit very tightly at both ends and was significantly
>>> thicker - it has more copper in the wires in the cable. Then suddenly
>>> the battery charging times were what was specified for the tablet,
>>> rather than three times as long. And over a number of charging
>>> cycles, the battery life came back again. So the original Samsung
>>> supplied cable was clearly bad from the start - it is probably less
>>> than the specification required to charge the tablet properly as it is
>>> too thin and has too much voltage drop even when the plugs fit
>>> properly. So definitely NZ$30 well spent. But I am surprised that a
>>> reputable company like Samsung would supply a bad cable with an
>>> expensive top-of-the-line product like my tablet. But they did - so
>>> now I always suspect any USB cable I get and keep an eye on how well
>>> it is working.
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users@mythtv.org
>>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>>> http://wiki.mythtv.org/Mailing_List_etiquette
>>> MythTV Forums: https://forum.mythtv.org
>>
>>
>> Thanks for all the suggestions. I will investigate all of them.
>> Something I do not see in here is an opinion that some software problem
>> could have evolved. I was kind of thinking of that as a possibility given
>> that it worked fine for so long then seems to be degrading. OTOH I never
>> thought of the possibility that the USB connection could be degrading. I'm
>> going to try Greg's connector, assuming I can get parts during the
>> Apocalypse. Also, his link specifies Radio Shack parts. What's Radio
>> Shack?!? ;-)
>>
>
> Well folks this is getting frustrating. I addressed a possible
> ventilation issue. I also unplugged the power cord I had from the Myth box
> USB and connected it to an old iPad charger rated at 5V/2A. No help. It
> wouldn't record anything, no matter how much rebooting and power-cycling.
> So I concluded the HDPVR was hosed and got a new one (more accurately, a
> replacement circuit board for it). Powered it with the same wall wart.
> Recorded great for a day. Just turned it on and I have failed recordings
> and it won't respond when I try to manually play a channel. Reboot, and it
> works fine, same pattern as before.
>
> I finally got a molex connector and am still going to try what Greg
> suggested, but I really don't think it's a power issue. Apply makes good
> electronics and that wart has the same specs as the power supply that comes
> with the HDPVR. The HDPCR isn't overheating. It's not the HDPVR itself.
> That only leaves the software on the myth box. Anyone have ideas how to
> troubleshoot that?
>
> _______________________________________________
> mythtv-users mailing listmythtv-users@mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
> The next time it won't record,try to cat it and see if it responds. This
> is the command I use, cat /dev/video0 > test .. dmesg for the proper port
> it's connected to. This may help too see if it is the software or not..
>
> I am curious were you got the motherboard? There used to be a place in
> Ohio (I believe) ,but they have gone out of business.
>
I will give that a try. The circuit board I got some time ago and I think
it was on ebay.
Re: HDPVR intermittent failure [ In reply to ]
glenb at glenb
Jun 28, 2020, 9:49 AM
Post #11 of 67 (3428 views)
Permalink
On Sun, 2020-06-28 at 09:45 -0700, DryHeat122 . wrote:
> On Sat, Jun 27, 2020 at 7:51 PM glen <glenb@glenb.net> wrote:
> > On Sat, 2020-06-27 at 18:46 -0700, DryHeat122 . wrote:
> > > On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <
> > > dryheat122@gmail.com> wrote:
> > > > On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
> > > > stephen_agent@jsw.gen.nz> wrote:
> > > > > On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> > > > >
> > > > >
> > > > >
> > > > > >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > >Ok thanks I will investigate that. But it's been working
> > > > > fine with the
> > > > >
> > > > > >current power source for like a year now, and others on this
> > > > > list use it
> > > > >
> > > > > >too.
> > > > >
> > > > >
> > > > >
> > > > > USB cables often fit badly into the sockets. If so, the
> > > > > connection
> > > > >
> > > > > generally gets worse over time as you get dirt or oxidisation
> > > > > on the
> > > > >
> > > > > contacts. So badly fitting cables will degrade with time.
> > > > > The result
> > > > >
> > > > > is that the voltage drop across the cable will increase
> > > > > markedly. And
> > > > >
> > > > > they can be too thin - the amount of copper in the wires is
> > > > > too little
> > > > >
> > > > > and that causes high resistance and a big voltage drop across
> > > > > the
> > > > >
> > > > > length of the cable. Some (most?) USB cables are designed
> > > > > only for
> > > > >
> > > > > data transmission, or to run very low power devices. For a
> > > > > high power
> > > > >
> > > > > device, you need a better (thicker) cable. The high power
> > > > > devices do
> > > > >
> > > > > a negotiation with device supplying the power and request
> > > > > high power
> > > > >
> > > > > mode. If the cable is not capable of high power, that
> > > > > negotiation is
> > > > >
> > > > > not supposed to work and the device should either only work
> > > > > in low
> > > > >
> > > > > power mode or it should turn itself off. But USB cable
> > > > > makers often
> > > > >
> > > > > make cables not capable of high power transmission that will
> > > > > allow the
> > > > >
> > > > > high power mode negotiation to succeed. So even though the
> > > > > device
> > > > >
> > > > > supplying the power is sending high current, the voltage drop
> > > > > in the
> > > > >
> > > > > cable means that at the other end, the voltage can be below
> > > > > the level
> > > > >
> > > > > required for proper operation or to fully charge the device's
> > > > > battery.
> > > > >
> > > > >
> > > > >
> > > > > I have had two notably bad experiences with USB cables. One
> > > > > was a USB
> > > > >
> > > > > DVB-T tuner, and it was very like your experience - it would
> > > > > go for a
> > > > >
> > > > > number of days just fine, then suddenly stop. If I unplugged
> > > > > it and
> > > > >
> > > > > plugged it in again, it would usually work again. When I
> > > > > finally
> > > > >
> > > > > investigated properly, I found the cable was just a little
> > > > > loose in
> > > > >
> > > > > the PC's socket. I replaced the cable with one that fit more
> > > > > tightly
> > > > >
> > > > > and the tuner was much more reliable. It still occasionally
> > > > > caused
> > > > >
> > > > > trouble, but only when I had bumped the cables (or in one
> > > > > case, after
> > > > >
> > > > > we had a small earthquake). So because of that and because I
> > > > > needed
> > > > >
> > > > > more DVB-T tuners, I finally replaced all my DVB-T tuners
> > > > > with an 8
> > > > >
> > > > > tuner PCIe card.
> > > > >
> > > > >
> > > > >
> > > > > The second bad experience was my Samsung Galaxy Tab S2
> > > > > tablet. Its
> > > > >
> > > > > USB charging cable was supplied with it by Samsung, so I
> > > > > assumed it
> > > > >
> > > > > was a good one. But right from the start, the tablet took a
> > > > > long time
> > > > >
> > > > > to charge, and the time gradually got longer and longer and
> > > > > the
> > > > >
> > > > > battery life on one charge was getting less and less. And
> > > > > then I
> > > > >
> > > > > started to have to jiggle the cable in the socket to get it
> > > > > to charge
> > > > >
> > > > > at all. I actually called the Samsung help line about this,
> > > > > and they
> > > > >
> > > > > said it sounds like a bad cable. So I bought a expensive
> > > > > (NZ$30)
> > > > >
> > > > > Pudney & Lee charging cable, which was a fair bit longer than
> > > > > the old
> > > > >
> > > > > Samsung cable, but fit very tightly at both ends and was
> > > > > significantly
> > > > >
> > > > > thicker - it has more copper in the wires in the cable. Then
> > > > > suddenly
> > > > >
> > > > > the battery charging times were what was specified for the
> > > > > tablet,
> > > > >
> > > > > rather than three times as long. And over a number of
> > > > > charging
> > > > >
> > > > > cycles, the battery life came back again. So the original
> > > > > Samsung
> > > > >
> > > > > supplied cable was clearly bad from the start - it is
> > > > > probably less
> > > > >
> > > > > than the specification required to charge the tablet properly
> > > > > as it is
> > > > >
> > > > > too thin and has too much voltage drop even when the plugs
> > > > > fit
> > > > >
> > > > > properly. So definitely NZ$30 well spent. But I am
> > > > > surprised that a
> > > > >
> > > > > reputable company like Samsung would supply a bad cable with
> > > > > an
> > > > >
> > > > > expensive top-of-the-line product like my tablet. But they
> > > > > did - so
> > > > >
> > > > > now I always suspect any USB cable I get and keep an eye on
> > > > > how well
> > > > >
> > > > > it is working.
> > > > >
> > > > > _______________________________________________
> > > > >
> > > > > mythtv-users mailing list
> > > > >
> > > > > mythtv-users@mythtv.org
> > > > >
> > > > > http://email.mg.glenb.net/c/eJxNjkEOwiAURE9TdhL-LxRZsHDjPT4FWhKgpqCJt7caE01mM29mkvF2juSVZMniqAAwOq2CjmDOTiNMQjo1ChkBlQaBIhrNZyohD1IsOVTHa-hstQjehAkhSEXGqzkQSQQhKOIkndAs27X32zBeBrweyqn1xsuzr_3Bt305UKGUC9VvmGrc3vDTON1b2Bvb7b89Hvz2L-CbPz8
> > > > >
> > > > > http://email.mg.glenb.net/c/eJxFjcsOgjAQRb-G7mw605csunDjSr-BUJhCY0GFQePfS-LC5K5OzsntQ5fa3hqRA2oLgCl6Sz5BfYwewSkTrVYmAVoPClWqvezaiUpl1FBojnImFmNwYNErU8cumnRE5zTolsgBJddjR6KEkflR6VOF533vfMty-vDIL3lfhp1c21zyPDSXvHJDnJ8bMZNYws86bCst6_76j74P1DtC
> > > > >
> > > > > MythTV Forums: http://email.mg.glenb.net/c/eJxFjDEKwzAMRU8TbzWyItX24KFL72ElVlJI0uI4hd6-gQ6FP7zHgz-mQfPIZB4Je3YOVTwXry4G8eiuQMI9kDpk7wBBo7dDXsvSEUxL2cRupZk5CUTCnIFFmVwIKBTDSCcPnkouZklza6-9628d3s_psx6rXT9tbm_7rJOp6SeXYy91P-__7QsiqTJl
> > > >
> > > > Thanks for all the suggestions. I will investigate all of
> > > > them. Something I do not see in here is an opinion that some
> > > > software problem could have evolved. I was kind of thinking of
> > > > that as a possibility given that it worked fine for so long
> > > > then seems to be degrading. OTOH I never thought of the
> > > > possibility that the USB connection could be degrading. I'm
> > > > going to try Greg's connector, assuming I can get parts during
> > > > the Apocalypse. Also, his link specifies Radio Shack parts.
> > > > What's Radio Shack?!? ;-)
> > >
> > > Well folks this is getting frustrating. I addressed a possible
> > > ventilation issue. I also unplugged the power cord I had from
> > > the Myth box USB and connected it to an old iPad charger rated at
> > > 5V/2A. No help. It wouldn't record anything, no matter how much
> > > rebooting and power-cycling. So I concluded the HDPVR was hosed
> > > and got a new one (more accurately, a replacement circuit board
> > > for it). Powered it with the same wall wart. Recorded great for
> > > a day. Just turned it on and I have failed recordings and it
> > > won't respond when I try to manually play a channel. Reboot, and
> > > it works fine, same pattern as before.
> > >
> > > I finally got a molex connector and am still going to try what
> > > Greg suggested, but I really don't think it's a power issue.
> > > Apply makes good electronics and that wart has the same specs as
> > > the power supply that comes with the HDPVR. The HDPCR isn't
> > > overheating. It's not the HDPVR itself. That only leaves the
> > > software on the myth box. Anyone have ideas how to troubleshoot
> > > that?
> > >
> > >
> > > _______________________________________________mythtv-users
> > > mailing listmythtv-users@mythtv.org
> > > http://email.mg.glenb.net/c/eJxNjkEOwiAURE9TdhL-LxRZsHDjPT4FWhKgpqCJt7caE01mM29mkvF2juSVZMniqAAwOq2CjmDOTiNMQjo1ChkBlQaBIhrNZyohD1IsOVTHa-hstQjehAkhSEXGqzkQSQQhKOIkndAs27X32zBeBrweyqn1xsuzr_3Bt305UKGUC9VvmGrc3vDTON1b2Bvb7b89Hvz2L-CbPz8
> > > http://email.mg.glenb.net/c/eJxFjcsOgjAQRb-G7mw605csunDjSr-BUJhCY0GFQePfS-LC5K5OzsntQ5fa3hqRA2oLgCl6Sz5BfYwewSkTrVYmAVoPClWqvezaiUpl1FBojnImFmNwYNErU8cumnRE5zTolsgBJddjR6KEkflR6VOF533vfMty-vDIL3lfhp1c21zyPDSXvHJDnJ8bMZNYws86bCst6_76j74P1DtC
> > > MythTV Forums: http://email.mg.glenb.net/c/eJxFjDEKwzAMRU8TbzWyItX24KFL72ElVlJI0uI4hd6-gQ6FP7zHgz-mQfPIZB4Je3YOVTwXry4G8eiuQMI9kDpk7wBBo7dDXsvSEUxL2cRupZk5CUTCnIFFmVwIKBTDSCcPnkouZklza6-9628d3s_psx6rXT9tbm_7rJOp6SeXYy91P-__7QsiqTJl
> >
> > have you tried a conf file in /etc/modprobe.d setting this option:
> > options ir-kbd-i2c enable_hdpvr=1
> >
> No. does ir-kbd stand for infrared keyboard? I don't have one of
> those.

if you are using nvidia, recently, the drm driver for nvidia brought in
different dependent modules and this was one whether or not you have
hardware using it. check your loaded modules (lsmod) to see if it is
loading. i had this issue with no ir hardware and had hdpvr issues
until i changed that option. simple enough to add a conf file and see
if you get a difference or not.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 1, 2020, 6:23 PM
Post #12 of 67 (3405 views)
Permalink
On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com> wrote:

>
> On 6/27/20 9:46 PM, DryHeat122 . wrote:
>
> On Mon, May 11, 2020 at 12:59 PM DryHeat122 . <dryheat122@gmail.com>
> wrote:
>
>> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington <
>> stephen_agent@jsw.gen.nz> wrote:
>>
>>> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>
>>> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com> wrote:
>>>
>>> >Ok thanks I will investigate that. But it's been working fine with the
>>> >current power source for like a year now, and others on this list use it
>>> >too.
>>>
>>> USB cables often fit badly into the sockets. If so, the connection
>>> generally gets worse over time as you get dirt or oxidisation on the
>>> contacts. So badly fitting cables will degrade with time. The result
>>> is that the voltage drop across the cable will increase markedly. And
>>> they can be too thin - the amount of copper in the wires is too little
>>> and that causes high resistance and a big voltage drop across the
>>> length of the cable. Some (most?) USB cables are designed only for
>>> data transmission, or to run very low power devices. For a high power
>>> device, you need a better (thicker) cable. The high power devices do
>>> a negotiation with device supplying the power and request high power
>>> mode. If the cable is not capable of high power, that negotiation is
>>> not supposed to work and the device should either only work in low
>>> power mode or it should turn itself off. But USB cable makers often
>>> make cables not capable of high power transmission that will allow the
>>> high power mode negotiation to succeed. So even though the device
>>> supplying the power is sending high current, the voltage drop in the
>>> cable means that at the other end, the voltage can be below the level
>>> required for proper operation or to fully charge the device's battery.
>>>
>>> I have had two notably bad experiences with USB cables. One was a USB
>>> DVB-T tuner, and it was very like your experience - it would go for a
>>> number of days just fine, then suddenly stop. If I unplugged it and
>>> plugged it in again, it would usually work again. When I finally
>>> investigated properly, I found the cable was just a little loose in
>>> the PC's socket. I replaced the cable with one that fit more tightly
>>> and the tuner was much more reliable. It still occasionally caused
>>> trouble, but only when I had bumped the cables (or in one case, after
>>> we had a small earthquake). So because of that and because I needed
>>> more DVB-T tuners, I finally replaced all my DVB-T tuners with an 8
>>> tuner PCIe card.
>>>
>>> The second bad experience was my Samsung Galaxy Tab S2 tablet. Its
>>> USB charging cable was supplied with it by Samsung, so I assumed it
>>> was a good one. But right from the start, the tablet took a long time
>>> to charge, and the time gradually got longer and longer and the
>>> battery life on one charge was getting less and less. And then I
>>> started to have to jiggle the cable in the socket to get it to charge
>>> at all. I actually called the Samsung help line about this, and they
>>> said it sounds like a bad cable. So I bought a expensive (NZ$30)
>>> Pudney & Lee charging cable, which was a fair bit longer than the old
>>> Samsung cable, but fit very tightly at both ends and was significantly
>>> thicker - it has more copper in the wires in the cable. Then suddenly
>>> the battery charging times were what was specified for the tablet,
>>> rather than three times as long. And over a number of charging
>>> cycles, the battery life came back again. So the original Samsung
>>> supplied cable was clearly bad from the start - it is probably less
>>> than the specification required to charge the tablet properly as it is
>>> too thin and has too much voltage drop even when the plugs fit
>>> properly. So definitely NZ$30 well spent. But I am surprised that a
>>> reputable company like Samsung would supply a bad cable with an
>>> expensive top-of-the-line product like my tablet. But they did - so
>>> now I always suspect any USB cable I get and keep an eye on how well
>>> it is working.
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users@mythtv.org
>>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>>> http://wiki.mythtv.org/Mailing_List_etiquette
>>> MythTV Forums: https://forum.mythtv.org
>>
>>
>> Thanks for all the suggestions. I will investigate all of them.
>> Something I do not see in here is an opinion that some software problem
>> could have evolved. I was kind of thinking of that as a possibility given
>> that it worked fine for so long then seems to be degrading. OTOH I never
>> thought of the possibility that the USB connection could be degrading. I'm
>> going to try Greg's connector, assuming I can get parts during the
>> Apocalypse. Also, his link specifies Radio Shack parts. What's Radio
>> Shack?!? ;-)
>>
>
> Well folks this is getting frustrating. I addressed a possible
> ventilation issue. I also unplugged the power cord I had from the Myth box
> USB and connected it to an old iPad charger rated at 5V/2A. No help. It
> wouldn't record anything, no matter how much rebooting and power-cycling.
> So I concluded the HDPVR was hosed and got a new one (more accurately, a
> replacement circuit board for it). Powered it with the same wall wart.
> Recorded great for a day. Just turned it on and I have failed recordings
> and it won't respond when I try to manually play a channel. Reboot, and it
> works fine, same pattern as before.
>
> I finally got a molex connector and am still going to try what Greg
> suggested, but I really don't think it's a power issue. Apply makes good
> electronics and that wart has the same specs as the power supply that comes
> with the HDPVR. The HDPCR isn't overheating. It's not the HDPVR itself.
> That only leaves the software on the myth box. Anyone have ideas how to
> troubleshoot that?
>
> _______________________________________________
> mythtv-users mailing listmythtv-users@mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
> The next time it won't record,try to cat it and see if it responds. This
> is the command I use, cat /dev/video0 > test .. dmesg for the proper port
> it's connected to. This may help too see if it is the software or not..
>
> I am curious were you got the motherboard? There used to be a place in
> Ohio (I believe) ,but they have gone out of business.
>
It failed again (despite putting the conf file in place). Here's the
result:

steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
cat: /dev/video0: Input/output error

I don't know how to "dmesg for the proper port it's connected to." I think
it's just connected to a USB port, but I don't know how to find out which
one. Can you be more specific?
Re: HDPVR intermittent failure [ In reply to ]
lists at morton
Jul 2, 2020, 5:07 AM
Post #13 of 67 (3401 views)
Permalink
On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>
> On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>> wrote:
>
>
> On 6/27/20 9:46 PM, DryHeat122 . wrote:
>> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>> wrote:
>>
>> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>> <stephen_agent@jsw.gen.nz <mailto:stephen_agent@jsw.gen.nz>>
>> wrote:
>>
>> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>
>> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com
>> <mailto:gregl@nycap.rr.com>> wrote:
>>
>> >Ok thanks I will investigate that.  But it's been
>> working fine with the
>> >current power source for like a year now, and others on
>> this list use it
>> >too.
>>
>> <snip><https://forum.mythtv.org>
>>
>>
>> Thanks for all the suggestions.  I will investigate all of
>> them.  Something I do not see in here is an opinion that some
>> software problem could have evolved.  I was kind of thinking
>> of that as a possibility given that it worked fine for so
>> long then seems to be degrading.  OTOH I never thought of the
>> possibility that the USB connection could be degrading.  I'm
>> going to try Greg's connector, assuming I can get parts
>> during the Apocalypse.  Also, his link specifies Radio Shack
>> parts.  What's Radio Shack?!? ;-)
>>
>>
>> Well folks this is getting frustrating.  I addressed a possible
>> ventilation issue.  I also unplugged the power cord I had from
>> the Myth box USB and connected it to an old iPad charger rated at
>> 5V/2A.  No help.  It wouldn't record anything, no matter how much
>> rebooting and power-cycling. So I concluded the HDPVR was hosed
>> and got a new one (more accurately, a replacement circuit board
>> for it).  Powered it with the same wall wart. Recorded great for
>> a day.  Just turned it on and I have failed recordings and it
>> won't respond when I try to manually play a channel.  Reboot, and
>> it works fine, same pattern as before.
>>
>> I finally got a molex connector and am still going to try what
>> Greg suggested, but I really don't think it's a power issue. 
>> Apply makes good electronics and that wart has the same specs as
>> the power supply that comes with the HDPVR.  The HDPCR isn't
>> overheating.  It's not the HDPVR itself.  That only leaves the
>> software on the myth box.  Anyone have ideas how to troubleshoot
>> that?
>>
>>
>  The next time it won't record,try to cat it and see if it
> responds.  This is the command I use,  cat /dev/video0 > test ..
> dmesg for the proper port it's connected to. This may help too see
> if it is the software or not..
>
> I am curious were you got the motherboard? There used to be a
> place in Ohio (I believe) ,but they have gone out of business.
>
> It failed again (despite putting the conf file in place).  Here's the
> result:
>
> steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
> cat: /dev/video0: Input/output error
>
> I don't know how to "dmesg for the proper port it's connected to."  I
> think it's just connected to a USB port, but I don't know how to find
> out which one. Can you be more specific?
>
>
This works on my system

dmesg | grep pvr
[    6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17 2010
09:26:53
[    6.452748] hdpvr 2-2:1.0: device now attached to video0
[    6.452844] usbcore: registered new interface driver hdpvr
docbuntu:~$


Jim
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 2, 2020, 6:35 AM
Post #14 of 67 (3401 views)
Permalink
On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com> wrote:

> On 7/1/2020 9:23 PM, DryHeat122 . wrote:
> >
> > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
> > <mailto:gregl@nycap.rr.com>> wrote:
> >
> >
> > On 6/27/20 9:46 PM, DryHeat122 . wrote:
> >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
> >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>> wrote:
> >>
> >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
> >> <stephen_agent@jsw.gen.nz <mailto:stephen_agent@jsw.gen.nz>>
> >> wrote:
> >>
> >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> >>
> >> >On Sun, May 10, 2020, 7:58 PM Greg <gregl@nycap.rr.com
> >> <mailto:gregl@nycap.rr.com>> wrote:
> >>
> >> >Ok thanks I will investigate that. But it's been
> >> working fine with the
> >> >current power source for like a year now, and others on
> >> this list use it
> >> >too.
> >>
> >> <snip><https://forum.mythtv.org>
> >>
> >>
> >> Thanks for all the suggestions. I will investigate all of
> >> them. Something I do not see in here is an opinion that some
> >> software problem could have evolved. I was kind of thinking
> >> of that as a possibility given that it worked fine for so
> >> long then seems to be degrading. OTOH I never thought of the
> >> possibility that the USB connection could be degrading. I'm
> >> going to try Greg's connector, assuming I can get parts
> >> during the Apocalypse. Also, his link specifies Radio Shack
> >> parts. What's Radio Shack?!? ;-)
> >>
> >>
> >> Well folks this is getting frustrating. I addressed a possible
> >> ventilation issue. I also unplugged the power cord I had from
> >> the Myth box USB and connected it to an old iPad charger rated at
> >> 5V/2A. No help. It wouldn't record anything, no matter how much
> >> rebooting and power-cycling. So I concluded the HDPVR was hosed
> >> and got a new one (more accurately, a replacement circuit board
> >> for it). Powered it with the same wall wart. Recorded great for
> >> a day. Just turned it on and I have failed recordings and it
> >> won't respond when I try to manually play a channel. Reboot, and
> >> it works fine, same pattern as before.
> >>
> >> I finally got a molex connector and am still going to try what
> >> Greg suggested, but I really don't think it's a power issue.
> >> Apply makes good electronics and that wart has the same specs as
> >> the power supply that comes with the HDPVR. The HDPCR isn't
> >> overheating. It's not the HDPVR itself. That only leaves the
> >> software on the myth box. Anyone have ideas how to troubleshoot
> >> that?
> >>
> >>
> > The next time it won't record,try to cat it and see if it
> > responds. This is the command I use, cat /dev/video0 > test ..
> > dmesg for the proper port it's connected to. This may help too see
> > if it is the software or not..
> >
> > I am curious were you got the motherboard? There used to be a
> > place in Ohio (I believe) ,but they have gone out of business.
> >
> > It failed again (despite putting the conf file in place). Here's the
> > result:
> >
> > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
> > cat: /dev/video0: Input/output error
> >
> > I don't know how to "dmesg for the proper port it's connected to." I
> > think it's just connected to a USB port, but I don't know how to find
> > out which one. Can you be more specific?
> >
> >
> This works on my system
>
> dmesg | grep pvr
> [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17 2010
> 09:26:53
> [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
> [ 6.452844] usbcore: registered new interface driver hdpvr
> docbuntu:~$
>

Ok next time it crashes I will try that.

>
Re: HDPVR intermittent failure [ In reply to ]
lists at morton
Jul 2, 2020, 6:47 AM
Post #15 of 67 (3401 views)
Permalink
On 7/2/2020 9:35 AM, DryHeat122 . wrote:
>
>
> On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
> <mailto:lists@morton.hrcoxmail.com>> wrote:
>
> On 7/1/2020 9:23 PM, DryHeat122 . wrote:
> >
> > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>
> > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>> wrote:
> >
> >
> >     On 6/27/20 9:46 PM, DryHeat122 . wrote:
> >>     On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
> >>     <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
> <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>> wrote:
> >>
> >>         On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
> >>         <stephen_agent@jsw.gen.nz
> <mailto:stephen_agent@jsw.gen.nz> <mailto:stephen_agent@jsw.gen.nz
> <mailto:stephen_agent@jsw.gen.nz>>>
> >>         wrote:
> >>
> >>             On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> >>
> >>             >On Sun, May 10, 2020, 7:58 PM Greg
> <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
> >>             <mailto:gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>>> wrote:
> >>
> >>             >Ok thanks I will investigate that.  But it's been
> >>             working fine with the
> >>             >current power source for like a year now, and
> others on
> >>             this list use it
> >>             >too.
> >>
> >>             <snip><https://forum.mythtv.org>
> >>
> >>
> >>         Thanks for all the suggestions.  I will investigate all of
> >>         them.  Something I do not see in here is an opinion
> that some
> >>         software problem could have evolved.  I was kind of
> thinking
> >>         of that as a possibility given that it worked fine for so
> >>         long then seems to be degrading.  OTOH I never thought
> of the
> >>         possibility that the USB connection could be
> degrading.  I'm
> >>         going to try Greg's connector, assuming I can get parts
> >>         during the Apocalypse.  Also, his link specifies Radio
> Shack
> >>         parts.  What's Radio Shack?!? ;-)
> >>
> >>
> >>     Well folks this is getting frustrating.  I addressed a possible
> >>     ventilation issue.  I also unplugged the power cord I had from
> >>     the Myth box USB and connected it to an old iPad charger
> rated at
> >>     5V/2A.  No help.  It wouldn't record anything, no matter
> how much
> >>     rebooting and power-cycling. So I concluded the HDPVR was hosed
> >>     and got a new one (more accurately, a replacement circuit board
> >>     for it).  Powered it with the same wall wart. Recorded
> great for
> >>     a day.  Just turned it on and I have failed recordings and it
> >>     won't respond when I try to manually play a channel. 
> Reboot, and
> >>     it works fine, same pattern as before.
> >>
> >>     I finally got a molex connector and am still going to try what
> >>     Greg suggested, but I really don't think it's a power issue.
> >>     Apply makes good electronics and that wart has the same
> specs as
> >>     the power supply that comes with the HDPVR. The HDPCR isn't
> >>     overheating.  It's not the HDPVR itself. That only leaves the
> >>     software on the myth box.  Anyone have ideas how to
> troubleshoot
> >>     that?
> >>
> >>
> >      The next time it won't record,try to cat it and see if it
> >     responds.  This is the command I use,  cat /dev/video0 > test ..
> >     dmesg for the proper port it's connected to. This may help
> too see
> >     if it is the software or not..
> >
> >     I am curious were you got the motherboard? There used to be a
> >     place in Ohio (I believe) ,but they have gone out of business.
> >
> > It failed again (despite putting the conf file in place). 
> Here's the
> > result:
> >
> > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
> > cat: /dev/video0: Input/output error
> >
> > I don't know how to "dmesg for the proper port it's connected
> to."  I
> > think it's just connected to a USB port, but I don't know how to
> find
> > out which one. Can you be more specific?
> >
> >
> This works on my system
>
> dmesg | grep pvr
> [    6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17 2010
> 09:26:53
> [    6.452748] hdpvr 2-2:1.0: device now attached to video0
> [    6.452844] usbcore: registered new interface driver hdpvr
> docbuntu:~$
>
>
> Ok next time it crashes I will try that.
>
>
Just to be clear - this is to confirm which device your hdpvr is
attached to
such as  /dev/video0 so that you can formulate the proper cat command.

Jim
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
rick at laity
Jul 2, 2020, 6:53 AM
Post #16 of 67 (3401 views)
Permalink
On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>
>
> On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
> <mailto:lists@morton.hrcoxmail.com>> wrote:
>
> On 7/1/2020 9:23 PM, DryHeat122 . wrote:
> >
> > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>
> > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>> wrote:
> >
> >
> >     On 6/27/20 9:46 PM, DryHeat122 . wrote:
> >>     On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
> >>     <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
> <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>> wrote:
> >>
> >>         On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
> >>         <stephen_agent@jsw.gen.nz
> <mailto:stephen_agent@jsw.gen.nz> <mailto:stephen_agent@jsw.gen.nz
> <mailto:stephen_agent@jsw.gen.nz>>>
> >>         wrote:
> >>
> >>             On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> >>
> >>             >On Sun, May 10, 2020, 7:58 PM Greg
> <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
> >>             <mailto:gregl@nycap.rr.com
> <mailto:gregl@nycap.rr.com>>> wrote:
> >>
> >>             >Ok thanks I will investigate that.  But it's been
> >>             working fine with the
> >>             >current power source for like a year now, and others on
> >>             this list use it
> >>             >too.
> >>
> >>             <snip><https://forum.mythtv.org>
> >>
> >>
> >>         Thanks for all the suggestions.  I will investigate all of
> >>         them.  Something I do not see in here is an opinion that
> some
> >>         software problem could have evolved.  I was kind of thinking
> >>         of that as a possibility given that it worked fine for so
> >>         long then seems to be degrading.  OTOH I never thought
> of the
> >>         possibility that the USB connection could be degrading.  I'm
> >>         going to try Greg's connector, assuming I can get parts
> >>         during the Apocalypse.  Also, his link specifies Radio Shack
> >>         parts.  What's Radio Shack?!? ;-)
> >>
> >>
> >>     Well folks this is getting frustrating.  I addressed a possible
> >>     ventilation issue.  I also unplugged the power cord I had from
> >>     the Myth box USB and connected it to an old iPad charger
> rated at
> >>     5V/2A.  No help.  It wouldn't record anything, no matter how
> much
> >>     rebooting and power-cycling. So I concluded the HDPVR was hosed
> >>     and got a new one (more accurately, a replacement circuit board
> >>     for it).  Powered it with the same wall wart. Recorded great for
> >>     a day.  Just turned it on and I have failed recordings and it
> >>     won't respond when I try to manually play a channel.
> Reboot, and
> >>     it works fine, same pattern as before.
> >>
> >>     I finally got a molex connector and am still going to try what
> >>     Greg suggested, but I really don't think it's a power issue.
> >>     Apply makes good electronics and that wart has the same specs as
> >>     the power supply that comes with the HDPVR.  The HDPCR isn't
> >>     overheating.  It's not the HDPVR itself.  That only leaves the
> >>     software on the myth box.  Anyone have ideas how to troubleshoot
> >>     that?
> >>
> >>
> >      The next time it won't record,try to cat it and see if it
> >     responds.  This is the command I use,  cat /dev/video0 > test ..
> >     dmesg for the proper port it's connected to. This may help
> too see
> >     if it is the software or not..
> >
> >     I am curious were you got the motherboard? There used to be a
> >     place in Ohio (I believe) ,but they have gone out of business.
> >
> > It failed again (despite putting the conf file in place).  Here's
> the
> > result:
> >
> > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
> > cat: /dev/video0: Input/output error
> >
> > I don't know how to "dmesg for the proper port it's connected
> to."  I
> > think it's just connected to a USB port, but I don't know how to
> find
> > out which one. Can you be more specific?
> >
> >
> This works on my system
>
> dmesg | grep pvr
> [    6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17 2010
> 09:26:53
> [    6.452748] hdpvr 2-2:1.0: device now attached to video0
> [    6.452844] usbcore: registered new interface driver hdpvr
> docbuntu:~$
>
>
> Ok next time it crashes I will try that.
>
>

I think the latest firmware is 0x1e from 2012. Probably won't make a
difference though but you never know.

Rick
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 2, 2020, 6:00 PM
Post #17 of 67 (3378 views)
Permalink
On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:

> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
> >
> >
> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
> > <mailto:lists@morton.hrcoxmail.com>> wrote:
> >
> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
> > >
> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
> > <mailto:gregl@nycap.rr.com>
> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>> wrote:
> > >
> > >
> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>> wrote:
> > >>
> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
> > >> <stephen_agent@jsw.gen.nz
> > <mailto:stephen_agent@jsw.gen.nz> <mailto:stephen_agent@jsw.gen.nz
> > <mailto:stephen_agent@jsw.gen.nz>>>
> > >> wrote:
> > >>
> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
> > >>
> > >> >On Sun, May 10, 2020, 7:58 PM Greg
> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
> > >> <mailto:gregl@nycap.rr.com
> > <mailto:gregl@nycap.rr.com>>> wrote:
> > >>
> > >> >Ok thanks I will investigate that. But it's been
> > >> working fine with the
> > >> >current power source for like a year now, and
> others on
> > >> this list use it
> > >> >too.
> > >>
> > >> <snip><https://forum.mythtv.org>
> > >>
> > >>
> > >> Thanks for all the suggestions. I will investigate all
> of
> > >> them. Something I do not see in here is an opinion that
> > some
> > >> software problem could have evolved. I was kind of
> thinking
> > >> of that as a possibility given that it worked fine for so
> > >> long then seems to be degrading. OTOH I never thought
> > of the
> > >> possibility that the USB connection could be degrading.
> I'm
> > >> going to try Greg's connector, assuming I can get parts
> > >> during the Apocalypse. Also, his link specifies Radio
> Shack
> > >> parts. What's Radio Shack?!? ;-)
> > >>
> > >>
> > >> Well folks this is getting frustrating. I addressed a
> possible
> > >> ventilation issue. I also unplugged the power cord I had
> from
> > >> the Myth box USB and connected it to an old iPad charger
> > rated at
> > >> 5V/2A. No help. It wouldn't record anything, no matter how
> > much
> > >> rebooting and power-cycling. So I concluded the HDPVR was
> hosed
> > >> and got a new one (more accurately, a replacement circuit
> board
> > >> for it). Powered it with the same wall wart. Recorded great
> for
> > >> a day. Just turned it on and I have failed recordings and it
> > >> won't respond when I try to manually play a channel.
> > Reboot, and
> > >> it works fine, same pattern as before.
> > >>
> > >> I finally got a molex connector and am still going to try
> what
> > >> Greg suggested, but I really don't think it's a power issue.
> > >> Apply makes good electronics and that wart has the same
> specs as
> > >> the power supply that comes with the HDPVR. The HDPCR isn't
> > >> overheating. It's not the HDPVR itself. That only leaves
> the
> > >> software on the myth box. Anyone have ideas how to
> troubleshoot
> > >> that?
> > >>
> > >>
> > > The next time it won't record,try to cat it and see if it
> > > responds. This is the command I use, cat /dev/video0 > test
> ..
> > > dmesg for the proper port it's connected to. This may help
> > too see
> > > if it is the software or not..
> > >
> > > I am curious were you got the motherboard? There used to be a
> > > place in Ohio (I believe) ,but they have gone out of business.
> > >
> > > It failed again (despite putting the conf file in place). Here's
> > the
> > > result:
> > >
> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
> > > cat: /dev/video0: Input/output error
> > >
> > > I don't know how to "dmesg for the proper port it's connected
> > to." I
> > > think it's just connected to a USB port, but I don't know how to
> > find
> > > out which one. Can you be more specific?
> > >
> > >
> > This works on my system
> >
> > dmesg | grep pvr
> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17 2010
> > 09:26:53
> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
> > [ 6.452844] usbcore: registered new interface driver hdpvr
> > docbuntu:~$
> >
> >
> > Ok next time it crashes I will try that.
> >
> >
>
> I think the latest firmware is 0x1e from 2012. Probably won't make a
> difference though but you never know.
>
> It crashed again. Same result when I try to cat /dev/video0:
input/output error

Here is what dmesg says:

steve@steve-EP45-UD3P:~$ dmesg | grep pvr
[ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
10:29:31
[ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not work.
[ 13.152225] hdpvr 2-6:1.0: device now attached to video0
[ 13.152252] usbcore: registered new interface driver hdpvr

So it seems I do not have the latest device driver. I doubt this is the
problem as it was working fine for years with the existing device driver
and I've not updated anything else. But can't hurt to try. How to install?
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 9, 2020, 6:10 PM
Post #18 of 67 (3352 views)
Permalink
On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com> wrote:

>
>
> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>
>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>> >
>> >
>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>> >
>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>> > >
>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>> > <mailto:gregl@nycap.rr.com>
>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>> wrote:
>> > >
>> > >
>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>> wrote:
>> > >>
>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>> > >> <stephen_agent@jsw.gen.nz
>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:stephen_agent@jsw.gen.nz
>> > <mailto:stephen_agent@jsw.gen.nz>>>
>> > >> wrote:
>> > >>
>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>> > >>
>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>> > >> <mailto:gregl@nycap.rr.com
>> > <mailto:gregl@nycap.rr.com>>> wrote:
>> > >>
>> > >> >Ok thanks I will investigate that. But it's been
>> > >> working fine with the
>> > >> >current power source for like a year now, and
>> others on
>> > >> this list use it
>> > >> >too.
>> > >>
>> > >> <snip><https://forum.mythtv.org>
>> > >>
>> > >>
>> > >> Thanks for all the suggestions. I will investigate all
>> of
>> > >> them. Something I do not see in here is an opinion that
>> > some
>> > >> software problem could have evolved. I was kind of
>> thinking
>> > >> of that as a possibility given that it worked fine for
>> so
>> > >> long then seems to be degrading. OTOH I never thought
>> > of the
>> > >> possibility that the USB connection could be
>> degrading. I'm
>> > >> going to try Greg's connector, assuming I can get parts
>> > >> during the Apocalypse. Also, his link specifies Radio
>> Shack
>> > >> parts. What's Radio Shack?!? ;-)
>> > >>
>> > >>
>> > >> Well folks this is getting frustrating. I addressed a
>> possible
>> > >> ventilation issue. I also unplugged the power cord I had
>> from
>> > >> the Myth box USB and connected it to an old iPad charger
>> > rated at
>> > >> 5V/2A. No help. It wouldn't record anything, no matter how
>> > much
>> > >> rebooting and power-cycling. So I concluded the HDPVR was
>> hosed
>> > >> and got a new one (more accurately, a replacement circuit
>> board
>> > >> for it). Powered it with the same wall wart. Recorded
>> great for
>> > >> a day. Just turned it on and I have failed recordings and
>> it
>> > >> won't respond when I try to manually play a channel.
>> > Reboot, and
>> > >> it works fine, same pattern as before.
>> > >>
>> > >> I finally got a molex connector and am still going to try
>> what
>> > >> Greg suggested, but I really don't think it's a power issue.
>> > >> Apply makes good electronics and that wart has the same
>> specs as
>> > >> the power supply that comes with the HDPVR. The HDPCR isn't
>> > >> overheating. It's not the HDPVR itself. That only leaves
>> the
>> > >> software on the myth box. Anyone have ideas how to
>> troubleshoot
>> > >> that?
>> > >>
>> > >>
>> > > The next time it won't record,try to cat it and see if it
>> > > responds. This is the command I use, cat /dev/video0 >
>> test ..
>> > > dmesg for the proper port it's connected to. This may help
>> > too see
>> > > if it is the software or not..
>> > >
>> > > I am curious were you got the motherboard? There used to be a
>> > > place in Ohio (I believe) ,but they have gone out of
>> business.
>> > >
>> > > It failed again (despite putting the conf file in place). Here's
>> > the
>> > > result:
>> > >
>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>> > > cat: /dev/video0: Input/output error
>> > >
>> > > I don't know how to "dmesg for the proper port it's connected
>> > to." I
>> > > think it's just connected to a USB port, but I don't know how to
>> > find
>> > > out which one. Can you be more specific?
>> > >
>> > >
>> > This works on my system
>> >
>> > dmesg | grep pvr
>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17
>> 2010
>> > 09:26:53
>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>> > docbuntu:~$
>> >
>> >
>> > Ok next time it crashes I will try that.
>> >
>> >
>>
>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>> difference though but you never know.
>>
>> It crashed again. Same result when I try to cat /dev/video0:
> input/output error
>
> Here is what dmesg says:
>
> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
> 10:29:31
> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not work.
> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
> [ 13.152252] usbcore: registered new interface driver hdpvr
>
> So it seems I do not have the latest device driver. I doubt this is the
> problem as it was working fine for years with the existing device driver
> and I've not updated anything else. But can't hurt to try. How to install?
>

I looked into this and realized it was about firmware, which apparently
can't be updated without hooking up to Windows. I don't think it's worth it
because like I said it worked with the firmware it's got for quite some
time.

I'm out of ideas. Can you guys think of anything? I'm thinking I will need
to just rebuild my machine with a fresh install of the lastest Ubuntu and
see if that helps. I've been getting this "system software problem
detected" popup a lot. Maybe that has something to do with it.

>
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 9, 2020, 6:18 PM
Post #19 of 67 (3352 views)
Permalink
On Thu, Jul 9, 2020 at 7:12 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>>
>>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>>> >
>>> >
>>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>>> >
>>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>>> > >
>>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>>> > <mailto:gregl@nycap.rr.com>
>>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>> wrote:
>>> > >
>>> > >
>>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>>
>>> wrote:
>>> > >>
>>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>>> > >> <stephen_agent@jsw.gen.nz
>>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:stephen_agent@jsw.gen.nz
>>> > <mailto:stephen_agent@jsw.gen.nz>>>
>>> > >> wrote:
>>> > >>
>>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>> > >>
>>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>>> > >> <mailto:gregl@nycap.rr.com
>>> > <mailto:gregl@nycap.rr.com>>> wrote:
>>> > >>
>>> > >> >Ok thanks I will investigate that. But it's been
>>> > >> working fine with the
>>> > >> >current power source for like a year now, and
>>> others on
>>> > >> this list use it
>>> > >> >too.
>>> > >>
>>> > >> <snip><https://forum.mythtv.org>
>>> > >>
>>> > >>
>>> > >> Thanks for all the suggestions. I will investigate
>>> all of
>>> > >> them. Something I do not see in here is an opinion
>>> that
>>> > some
>>> > >> software problem could have evolved. I was kind of
>>> thinking
>>> > >> of that as a possibility given that it worked fine for
>>> so
>>> > >> long then seems to be degrading. OTOH I never thought
>>> > of the
>>> > >> possibility that the USB connection could be
>>> degrading. I'm
>>> > >> going to try Greg's connector, assuming I can get parts
>>> > >> during the Apocalypse. Also, his link specifies Radio
>>> Shack
>>> > >> parts. What's Radio Shack?!? ;-)
>>> > >>
>>> > >>
>>> > >> Well folks this is getting frustrating. I addressed a
>>> possible
>>> > >> ventilation issue. I also unplugged the power cord I had
>>> from
>>> > >> the Myth box USB and connected it to an old iPad charger
>>> > rated at
>>> > >> 5V/2A. No help. It wouldn't record anything, no matter
>>> how
>>> > much
>>> > >> rebooting and power-cycling. So I concluded the HDPVR was
>>> hosed
>>> > >> and got a new one (more accurately, a replacement circuit
>>> board
>>> > >> for it). Powered it with the same wall wart. Recorded
>>> great for
>>> > >> a day. Just turned it on and I have failed recordings and
>>> it
>>> > >> won't respond when I try to manually play a channel.
>>> > Reboot, and
>>> > >> it works fine, same pattern as before.
>>> > >>
>>> > >> I finally got a molex connector and am still going to try
>>> what
>>> > >> Greg suggested, but I really don't think it's a power
>>> issue.
>>> > >> Apply makes good electronics and that wart has the same
>>> specs as
>>> > >> the power supply that comes with the HDPVR. The HDPCR
>>> isn't
>>> > >> overheating. It's not the HDPVR itself. That only leaves
>>> the
>>> > >> software on the myth box. Anyone have ideas how to
>>> troubleshoot
>>> > >> that?
>>> > >>
>>> > >>
>>> > > The next time it won't record,try to cat it and see if it
>>> > > responds. This is the command I use, cat /dev/video0 >
>>> test ..
>>> > > dmesg for the proper port it's connected to. This may help
>>> > too see
>>> > > if it is the software or not..
>>> > >
>>> > > I am curious were you got the motherboard? There used to be
>>> a
>>> > > place in Ohio (I believe) ,but they have gone out of
>>> business.
>>> > >
>>> > > It failed again (despite putting the conf file in place).
>>> Here's
>>> > the
>>> > > result:
>>> > >
>>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>>> > > cat: /dev/video0: Input/output error
>>> > >
>>> > > I don't know how to "dmesg for the proper port it's connected
>>> > to." I
>>> > > think it's just connected to a USB port, but I don't know how to
>>> > find
>>> > > out which one. Can you be more specific?
>>> > >
>>> > >
>>> > This works on my system
>>> >
>>> > dmesg | grep pvr
>>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17
>>> 2010
>>> > 09:26:53
>>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>>> > docbuntu:~$
>>> >
>>> >
>>> > Ok next time it crashes I will try that.
>>> >
>>> >
>>>
>>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>>> difference though but you never know.
>>>
>>> It crashed again. Same result when I try to cat /dev/video0:
>> input/output error
>>
>> Here is what dmesg says:
>>
>> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
>> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
>> 10:29:31
>> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not
>> work.
>> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
>> [ 13.152252] usbcore: registered new interface driver hdpvr
>>
>> So it seems I do not have the latest device driver. I doubt this is the
>> problem as it was working fine for years with the existing device driver
>> and I've not updated anything else. But can't hurt to try. How to install?
>>
>
> I looked into this and realized it was about firmware, which apparently
> can't be updated without hooking up to Windows. I don't think it's worth it
> because like I said it worked with the firmware it's got for quite some
> time.
>
> I'm out of ideas. Can you guys think of anything? I'm thinking I will
> need to just rebuild my machine with a fresh install of the lastest Ubuntu
> and see if that helps. I've been getting this "system software problem
> detected" popup a lot. Maybe that has something to do with it.
>
>>
The first generation HD-PVR was extremely sensitive to the USB port it was
plugged into. Basically did not work at all when plugged into USB3, and was
picky about the USB2 chipset as well. The only thing you have probably not
tried yet, is buying a USB2 add-on card to see if that helps. I don't think
it will, but if you are desperate to keep your HD-PVR working, then that is
the only thing I can think of.

Your experience pretty much mirrors mine from a few years ago. My first
generation HD-PVRs slowly got less and less reliable over time. That is
what gave me the motivation to get the second generation HD-PVR working
with Myth.

John
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 9, 2020, 6:24 PM
Post #20 of 67 (3352 views)
Permalink
On Thu, Jul 9, 2020, 6:18 PM John P Poet <jppoet@gmail.com> wrote:

> On Thu, Jul 9, 2020 at 7:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>>>
>>>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>>>> >
>>>> >
>>>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>>>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>>>> >
>>>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>>>> > >
>>>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>>>> > <mailto:gregl@nycap.rr.com>
>>>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>>
>>>> wrote:
>>>> > >
>>>> > >
>>>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>>>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>>>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>>>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>>
>>>> wrote:
>>>> > >>
>>>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>>>> > >> <stephen_agent@jsw.gen.nz
>>>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:
>>>> stephen_agent@jsw.gen.nz
>>>> > <mailto:stephen_agent@jsw.gen.nz>>>
>>>> > >> wrote:
>>>> > >>
>>>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>> > >>
>>>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>>>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>>>> > >> <mailto:gregl@nycap.rr.com
>>>> > <mailto:gregl@nycap.rr.com>>> wrote:
>>>> > >>
>>>> > >> >Ok thanks I will investigate that. But it's been
>>>> > >> working fine with the
>>>> > >> >current power source for like a year now, and
>>>> others on
>>>> > >> this list use it
>>>> > >> >too.
>>>> > >>
>>>> > >> <snip><https://forum.mythtv.org>
>>>> > >>
>>>> > >>
>>>> > >> Thanks for all the suggestions. I will investigate
>>>> all of
>>>> > >> them. Something I do not see in here is an opinion
>>>> that
>>>> > some
>>>> > >> software problem could have evolved. I was kind of
>>>> thinking
>>>> > >> of that as a possibility given that it worked fine
>>>> for so
>>>> > >> long then seems to be degrading. OTOH I never thought
>>>> > of the
>>>> > >> possibility that the USB connection could be
>>>> degrading. I'm
>>>> > >> going to try Greg's connector, assuming I can get
>>>> parts
>>>> > >> during the Apocalypse. Also, his link specifies
>>>> Radio Shack
>>>> > >> parts. What's Radio Shack?!? ;-)
>>>> > >>
>>>> > >>
>>>> > >> Well folks this is getting frustrating. I addressed a
>>>> possible
>>>> > >> ventilation issue. I also unplugged the power cord I had
>>>> from
>>>> > >> the Myth box USB and connected it to an old iPad charger
>>>> > rated at
>>>> > >> 5V/2A. No help. It wouldn't record anything, no matter
>>>> how
>>>> > much
>>>> > >> rebooting and power-cycling. So I concluded the HDPVR was
>>>> hosed
>>>> > >> and got a new one (more accurately, a replacement circuit
>>>> board
>>>> > >> for it). Powered it with the same wall wart. Recorded
>>>> great for
>>>> > >> a day. Just turned it on and I have failed recordings
>>>> and it
>>>> > >> won't respond when I try to manually play a channel.
>>>> > Reboot, and
>>>> > >> it works fine, same pattern as before.
>>>> > >>
>>>> > >> I finally got a molex connector and am still going to try
>>>> what
>>>> > >> Greg suggested, but I really don't think it's a power
>>>> issue.
>>>> > >> Apply makes good electronics and that wart has the same
>>>> specs as
>>>> > >> the power supply that comes with the HDPVR. The HDPCR
>>>> isn't
>>>> > >> overheating. It's not the HDPVR itself. That only
>>>> leaves the
>>>> > >> software on the myth box. Anyone have ideas how to
>>>> troubleshoot
>>>> > >> that?
>>>> > >>
>>>> > >>
>>>> > > The next time it won't record,try to cat it and see if it
>>>> > > responds. This is the command I use, cat /dev/video0 >
>>>> test ..
>>>> > > dmesg for the proper port it's connected to. This may help
>>>> > too see
>>>> > > if it is the software or not..
>>>> > >
>>>> > > I am curious were you got the motherboard? There used to
>>>> be a
>>>> > > place in Ohio (I believe) ,but they have gone out of
>>>> business.
>>>> > >
>>>> > > It failed again (despite putting the conf file in place).
>>>> Here's
>>>> > the
>>>> > > result:
>>>> > >
>>>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>>>> > > cat: /dev/video0: Input/output error
>>>> > >
>>>> > > I don't know how to "dmesg for the proper port it's connected
>>>> > to." I
>>>> > > think it's just connected to a USB port, but I don't know how
>>>> to
>>>> > find
>>>> > > out which one. Can you be more specific?
>>>> > >
>>>> > >
>>>> > This works on my system
>>>> >
>>>> > dmesg | grep pvr
>>>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17
>>>> 2010
>>>> > 09:26:53
>>>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>>>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>>>> > docbuntu:~$
>>>> >
>>>> >
>>>> > Ok next time it crashes I will try that.
>>>> >
>>>> >
>>>>
>>>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>>>> difference though but you never know.
>>>>
>>>> It crashed again. Same result when I try to cat /dev/video0:
>>> input/output error
>>>
>>> Here is what dmesg says:
>>>
>>> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
>>> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
>>> 10:29:31
>>> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not
>>> work.
>>> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
>>> [ 13.152252] usbcore: registered new interface driver hdpvr
>>>
>>> So it seems I do not have the latest device driver. I doubt this is the
>>> problem as it was working fine for years with the existing device driver
>>> and I've not updated anything else. But can't hurt to try. How to install?
>>>
>>
>> I looked into this and realized it was about firmware, which apparently
>> can't be updated without hooking up to Windows. I don't think it's worth it
>> because like I said it worked with the firmware it's got for quite some
>> time.
>>
>> I'm out of ideas. Can you guys think of anything? I'm thinking I will
>> need to just rebuild my machine with a fresh install of the lastest Ubuntu
>> and see if that helps. I've been getting this "system software problem
>> detected" popup a lot. Maybe that has something to do with it.
>>
>>>
> The first generation HD-PVR was extremely sensitive to the USB port it was
> plugged into. Basically did not work at all when plugged into USB3, and was
> picky about the USB2 chipset as well. The only thing you have probably not
> tried yet, is buying a USB2 add-on card to see if that helps. I don't think
> it will, but if you are desperate to keep your HD-PVR working, then that is
> the only thing I can think of.
>
> Your experience pretty much mirrors mine from a few years ago. My first
> generation HD-PVRs slowly got less and less reliable over time. That is
> what gave me the motivation to get the second generation HD-PVR working
> with Myth.
>
> John
>
I thought the HDPVR2 was not Myth compatible. Has that changed?

>
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 9, 2020, 6:35 PM
Post #21 of 67 (3352 views)
Permalink
On Thu, Jul 9, 2020 at 7:26 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Thu, Jul 9, 2020, 6:18 PM John P Poet <jppoet@gmail.com> wrote:
>
>> On Thu, Jul 9, 2020 at 7:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>>>>
>>>>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>>>>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>>>>> >
>>>>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>>>>> > >
>>>>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>>>>> > <mailto:gregl@nycap.rr.com>
>>>>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>>
>>>>> wrote:
>>>>> > >
>>>>> > >
>>>>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>>>>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>>>>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>>>>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>>
>>>>> wrote:
>>>>> > >>
>>>>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>>>>> > >> <stephen_agent@jsw.gen.nz
>>>>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:
>>>>> stephen_agent@jsw.gen.nz
>>>>> > <mailto:stephen_agent@jsw.gen.nz>>>
>>>>> > >> wrote:
>>>>> > >>
>>>>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>>> > >>
>>>>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>>>>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>>>>> > >> <mailto:gregl@nycap.rr.com
>>>>> > <mailto:gregl@nycap.rr.com>>> wrote:
>>>>> > >>
>>>>> > >> >Ok thanks I will investigate that. But it's
>>>>> been
>>>>> > >> working fine with the
>>>>> > >> >current power source for like a year now, and
>>>>> others on
>>>>> > >> this list use it
>>>>> > >> >too.
>>>>> > >>
>>>>> > >> <snip><https://forum.mythtv.org>
>>>>> > >>
>>>>> > >>
>>>>> > >> Thanks for all the suggestions. I will investigate
>>>>> all of
>>>>> > >> them. Something I do not see in here is an opinion
>>>>> that
>>>>> > some
>>>>> > >> software problem could have evolved. I was kind of
>>>>> thinking
>>>>> > >> of that as a possibility given that it worked fine
>>>>> for so
>>>>> > >> long then seems to be degrading. OTOH I never
>>>>> thought
>>>>> > of the
>>>>> > >> possibility that the USB connection could be
>>>>> degrading. I'm
>>>>> > >> going to try Greg's connector, assuming I can get
>>>>> parts
>>>>> > >> during the Apocalypse. Also, his link specifies
>>>>> Radio Shack
>>>>> > >> parts. What's Radio Shack?!? ;-)
>>>>> > >>
>>>>> > >>
>>>>> > >> Well folks this is getting frustrating. I addressed a
>>>>> possible
>>>>> > >> ventilation issue. I also unplugged the power cord I
>>>>> had from
>>>>> > >> the Myth box USB and connected it to an old iPad charger
>>>>> > rated at
>>>>> > >> 5V/2A. No help. It wouldn't record anything, no matter
>>>>> how
>>>>> > much
>>>>> > >> rebooting and power-cycling. So I concluded the HDPVR
>>>>> was hosed
>>>>> > >> and got a new one (more accurately, a replacement
>>>>> circuit board
>>>>> > >> for it). Powered it with the same wall wart. Recorded
>>>>> great for
>>>>> > >> a day. Just turned it on and I have failed recordings
>>>>> and it
>>>>> > >> won't respond when I try to manually play a channel.
>>>>> > Reboot, and
>>>>> > >> it works fine, same pattern as before.
>>>>> > >>
>>>>> > >> I finally got a molex connector and am still going to
>>>>> try what
>>>>> > >> Greg suggested, but I really don't think it's a power
>>>>> issue.
>>>>> > >> Apply makes good electronics and that wart has the same
>>>>> specs as
>>>>> > >> the power supply that comes with the HDPVR. The HDPCR
>>>>> isn't
>>>>> > >> overheating. It's not the HDPVR itself. That only
>>>>> leaves the
>>>>> > >> software on the myth box. Anyone have ideas how to
>>>>> troubleshoot
>>>>> > >> that?
>>>>> > >>
>>>>> > >>
>>>>> > > The next time it won't record,try to cat it and see if it
>>>>> > > responds. This is the command I use, cat /dev/video0 >
>>>>> test ..
>>>>> > > dmesg for the proper port it's connected to. This may help
>>>>> > too see
>>>>> > > if it is the software or not..
>>>>> > >
>>>>> > > I am curious were you got the motherboard? There used to
>>>>> be a
>>>>> > > place in Ohio (I believe) ,but they have gone out of
>>>>> business.
>>>>> > >
>>>>> > > It failed again (despite putting the conf file in place).
>>>>> Here's
>>>>> > the
>>>>> > > result:
>>>>> > >
>>>>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>>>>> > > cat: /dev/video0: Input/output error
>>>>> > >
>>>>> > > I don't know how to "dmesg for the proper port it's connected
>>>>> > to." I
>>>>> > > think it's just connected to a USB port, but I don't know how
>>>>> to
>>>>> > find
>>>>> > > out which one. Can you be more specific?
>>>>> > >
>>>>> > >
>>>>> > This works on my system
>>>>> >
>>>>> > dmesg | grep pvr
>>>>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun 17
>>>>> 2010
>>>>> > 09:26:53
>>>>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>>>>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>>>>> > docbuntu:~$
>>>>> >
>>>>> >
>>>>> > Ok next time it crashes I will try that.
>>>>> >
>>>>> >
>>>>>
>>>>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>>>>> difference though but you never know.
>>>>>
>>>>> It crashed again. Same result when I try to cat /dev/video0:
>>>> input/output error
>>>>
>>>> Here is what dmesg says:
>>>>
>>>> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
>>>> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
>>>> 10:29:31
>>>> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not
>>>> work.
>>>> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
>>>> [ 13.152252] usbcore: registered new interface driver hdpvr
>>>>
>>>> So it seems I do not have the latest device driver. I doubt this is
>>>> the problem as it was working fine for years with the existing device
>>>> driver and I've not updated anything else. But can't hurt to try. How to
>>>> install?
>>>>
>>>
>>> I looked into this and realized it was about firmware, which apparently
>>> can't be updated without hooking up to Windows. I don't think it's worth it
>>> because like I said it worked with the firmware it's got for quite some
>>> time.
>>>
>>> I'm out of ideas. Can you guys think of anything? I'm thinking I will
>>> need to just rebuild my machine with a fresh install of the lastest Ubuntu
>>> and see if that helps. I've been getting this "system software problem
>>> detected" popup a lot. Maybe that has something to do with it.
>>>
>>>>
>> The first generation HD-PVR was extremely sensitive to the USB port it
>> was plugged into. Basically did not work at all when plugged into USB3, and
>> was picky about the USB2 chipset as well. The only thing you have probably
>> not tried yet, is buying a USB2 add-on card to see if that helps. I don't
>> think it will, but if you are desperate to keep your HD-PVR working, then
>> that is the only thing I can think of.
>>
>> Your experience pretty much mirrors mine from a few years ago. My first
>> generation HD-PVRs slowly got less and less reliable over time. That is
>> what gave me the motivation to get the second generation HD-PVR working
>> with Myth.
>>
>> John
>>
> I thought the HDPVR2 was not Myth compatible. Has that changed?
>
>>
https://github.com/jpoet/HauppaugeUSB
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 9, 2020, 6:44 PM
Post #22 of 67 (3352 views)
Permalink
On Thu, Jul 9, 2020, 6:35 PM John P Poet <jppoet@gmail.com> wrote:

> On Thu, Jul 9, 2020 at 7:26 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Thu, Jul 9, 2020, 6:18 PM John P Poet <jppoet@gmail.com> wrote:
>>
>>> On Thu, Jul 9, 2020 at 7:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>>>>>
>>>>>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>>>>>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>>>>>> >
>>>>>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>>>>>> > >
>>>>>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>>>>>> > <mailto:gregl@nycap.rr.com>
>>>>>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>>
>>>>>> wrote:
>>>>>> > >
>>>>>> > >
>>>>>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>>>>>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>>>>>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>>>>>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>>
>>>>>> wrote:
>>>>>> > >>
>>>>>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>>>>>> > >> <stephen_agent@jsw.gen.nz
>>>>>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:
>>>>>> stephen_agent@jsw.gen.nz
>>>>>> > <mailto:stephen_agent@jsw.gen.nz>>>
>>>>>> > >> wrote:
>>>>>> > >>
>>>>>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>>>> > >>
>>>>>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>>>>>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>>>>>> > >> <mailto:gregl@nycap.rr.com
>>>>>> > <mailto:gregl@nycap.rr.com>>> wrote:
>>>>>> > >>
>>>>>> > >> >Ok thanks I will investigate that. But it's
>>>>>> been
>>>>>> > >> working fine with the
>>>>>> > >> >current power source for like a year now, and
>>>>>> others on
>>>>>> > >> this list use it
>>>>>> > >> >too.
>>>>>> > >>
>>>>>> > >> <snip><https://forum.mythtv.org>
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> Thanks for all the suggestions. I will investigate
>>>>>> all of
>>>>>> > >> them. Something I do not see in here is an opinion
>>>>>> that
>>>>>> > some
>>>>>> > >> software problem could have evolved. I was kind of
>>>>>> thinking
>>>>>> > >> of that as a possibility given that it worked fine
>>>>>> for so
>>>>>> > >> long then seems to be degrading. OTOH I never
>>>>>> thought
>>>>>> > of the
>>>>>> > >> possibility that the USB connection could be
>>>>>> degrading. I'm
>>>>>> > >> going to try Greg's connector, assuming I can get
>>>>>> parts
>>>>>> > >> during the Apocalypse. Also, his link specifies
>>>>>> Radio Shack
>>>>>> > >> parts. What's Radio Shack?!? ;-)
>>>>>> > >>
>>>>>> > >>
>>>>>> > >> Well folks this is getting frustrating. I addressed a
>>>>>> possible
>>>>>> > >> ventilation issue. I also unplugged the power cord I
>>>>>> had from
>>>>>> > >> the Myth box USB and connected it to an old iPad charger
>>>>>> > rated at
>>>>>> > >> 5V/2A. No help. It wouldn't record anything, no
>>>>>> matter how
>>>>>> > much
>>>>>> > >> rebooting and power-cycling. So I concluded the HDPVR
>>>>>> was hosed
>>>>>> > >> and got a new one (more accurately, a replacement
>>>>>> circuit board
>>>>>> > >> for it). Powered it with the same wall wart. Recorded
>>>>>> great for
>>>>>> > >> a day. Just turned it on and I have failed recordings
>>>>>> and it
>>>>>> > >> won't respond when I try to manually play a channel.
>>>>>> > Reboot, and
>>>>>> > >> it works fine, same pattern as before.
>>>>>> > >>
>>>>>> > >> I finally got a molex connector and am still going to
>>>>>> try what
>>>>>> > >> Greg suggested, but I really don't think it's a power
>>>>>> issue.
>>>>>> > >> Apply makes good electronics and that wart has the same
>>>>>> specs as
>>>>>> > >> the power supply that comes with the HDPVR. The HDPCR
>>>>>> isn't
>>>>>> > >> overheating. It's not the HDPVR itself. That only
>>>>>> leaves the
>>>>>> > >> software on the myth box. Anyone have ideas how to
>>>>>> troubleshoot
>>>>>> > >> that?
>>>>>> > >>
>>>>>> > >>
>>>>>> > > The next time it won't record,try to cat it and see if
>>>>>> it
>>>>>> > > responds. This is the command I use, cat /dev/video0 >
>>>>>> test ..
>>>>>> > > dmesg for the proper port it's connected to. This may
>>>>>> help
>>>>>> > too see
>>>>>> > > if it is the software or not..
>>>>>> > >
>>>>>> > > I am curious were you got the motherboard? There used to
>>>>>> be a
>>>>>> > > place in Ohio (I believe) ,but they have gone out of
>>>>>> business.
>>>>>> > >
>>>>>> > > It failed again (despite putting the conf file in place).
>>>>>> Here's
>>>>>> > the
>>>>>> > > result:
>>>>>> > >
>>>>>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>>>>>> > > cat: /dev/video0: Input/output error
>>>>>> > >
>>>>>> > > I don't know how to "dmesg for the proper port it's connected
>>>>>> > to." I
>>>>>> > > think it's just connected to a USB port, but I don't know
>>>>>> how to
>>>>>> > find
>>>>>> > > out which one. Can you be more specific?
>>>>>> > >
>>>>>> > >
>>>>>> > This works on my system
>>>>>> >
>>>>>> > dmesg | grep pvr
>>>>>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun
>>>>>> 17 2010
>>>>>> > 09:26:53
>>>>>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>>>>>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>>>>>> > docbuntu:~$
>>>>>> >
>>>>>> >
>>>>>> > Ok next time it crashes I will try that.
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>>>>>> difference though but you never know.
>>>>>>
>>>>>> It crashed again. Same result when I try to cat /dev/video0:
>>>>> input/output error
>>>>>
>>>>> Here is what dmesg says:
>>>>>
>>>>> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
>>>>> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
>>>>> 10:29:31
>>>>> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not
>>>>> work.
>>>>> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
>>>>> [ 13.152252] usbcore: registered new interface driver hdpvr
>>>>>
>>>>> So it seems I do not have the latest device driver. I doubt this is
>>>>> the problem as it was working fine for years with the existing device
>>>>> driver and I've not updated anything else. But can't hurt to try. How to
>>>>> install?
>>>>>
>>>>
>>>> I looked into this and realized it was about firmware, which apparently
>>>> can't be updated without hooking up to Windows. I don't think it's worth it
>>>> because like I said it worked with the firmware it's got for quite some
>>>> time.
>>>>
>>>> I'm out of ideas. Can you guys think of anything? I'm thinking I will
>>>> need to just rebuild my machine with a fresh install of the lastest Ubuntu
>>>> and see if that helps. I've been getting this "system software problem
>>>> detected" popup a lot. Maybe that has something to do with it.
>>>>
>>>>>
>>> The first generation HD-PVR was extremely sensitive to the USB port it
>>> was plugged into. Basically did not work at all when plugged into USB3, and
>>> was picky about the USB2 chipset as well. The only thing you have probably
>>> not tried yet, is buying a USB2 add-on card to see if that helps. I don't
>>> think it will, but if you are desperate to keep your HD-PVR working, then
>>> that is the only thing I can think of.
>>>
>>> Your experience pretty much mirrors mine from a few years ago. My first
>>> generation HD-PVRs slowly got less and less reliable over time. That is
>>> what gave me the motivation to get the second generation HD-PVR working
>>> with Myth.
>>>
>>> John
>>>
>> I thought the HDPVR2 was not Myth compatible. Has that changed?
>>
>>>
> https://github.com/jpoet/HauppaugeUSB
>

Thanks!

>
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 9, 2020, 6:50 PM
Post #23 of 67 (3352 views)
Permalink
On Thu, Jul 9, 2020, 6:44 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Thu, Jul 9, 2020, 6:35 PM John P Poet <jppoet@gmail.com> wrote:
>
>> On Thu, Jul 9, 2020 at 7:26 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Jul 9, 2020, 6:18 PM John P Poet <jppoet@gmail.com> wrote:
>>>
>>>> On Thu, Jul 9, 2020 at 7:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 2, 2020, 6:00 PM DryHeat122 . <dryheat122@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 2, 2020 at 6:53 AM Rick <rick@laity.ca> wrote:
>>>>>>
>>>>>>> On 7/2/2020 10:35 AM, DryHeat122 . wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On Thu, Jul 2, 2020, 5:08 AM Jim <lists@morton.hrcoxmail.com
>>>>>>> > <mailto:lists@morton.hrcoxmail.com>> wrote:
>>>>>>> >
>>>>>>> > On 7/1/2020 9:23 PM, DryHeat122 . wrote:
>>>>>>> > >
>>>>>>> > > On Sun, Jun 28, 2020 at 9:32 AM Greg <gregl@nycap.rr.com
>>>>>>> > <mailto:gregl@nycap.rr.com>
>>>>>>> > > <mailto:gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>>>
>>>>>>> wrote:
>>>>>>> > >
>>>>>>> > >
>>>>>>> > > On 6/27/20 9:46 PM, DryHeat122 . wrote:
>>>>>>> > >> On Mon, May 11, 2020 at 12:59 PM DryHeat122 .
>>>>>>> > >> <dryheat122@gmail.com <mailto:dryheat122@gmail.com>
>>>>>>> > <mailto:dryheat122@gmail.com <mailto:dryheat122@gmail.com>>>
>>>>>>> wrote:
>>>>>>> > >>
>>>>>>> > >> On Mon, May 11, 2020 at 2:41 AM Stephen Worthington
>>>>>>> > >> <stephen_agent@jsw.gen.nz
>>>>>>> > <mailto:stephen_agent@jsw.gen.nz> <mailto:
>>>>>>> stephen_agent@jsw.gen.nz
>>>>>>> > <mailto:stephen_agent@jsw.gen.nz>>>
>>>>>>> > >> wrote:
>>>>>>> > >>
>>>>>>> > >> On Sun, 10 May 2020 20:20:30 -0700, you wrote:
>>>>>>> > >>
>>>>>>> > >> >On Sun, May 10, 2020, 7:58 PM Greg
>>>>>>> > <gregl@nycap.rr.com <mailto:gregl@nycap.rr.com>
>>>>>>> > >> <mailto:gregl@nycap.rr.com
>>>>>>> > <mailto:gregl@nycap.rr.com>>> wrote:
>>>>>>> > >>
>>>>>>> > >> >Ok thanks I will investigate that. But it's
>>>>>>> been
>>>>>>> > >> working fine with the
>>>>>>> > >> >current power source for like a year now, and
>>>>>>> others on
>>>>>>> > >> this list use it
>>>>>>> > >> >too.
>>>>>>> > >>
>>>>>>> > >> <snip><https://forum.mythtv.org>
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> Thanks for all the suggestions. I will
>>>>>>> investigate all of
>>>>>>> > >> them. Something I do not see in here is an
>>>>>>> opinion that
>>>>>>> > some
>>>>>>> > >> software problem could have evolved. I was kind
>>>>>>> of thinking
>>>>>>> > >> of that as a possibility given that it worked fine
>>>>>>> for so
>>>>>>> > >> long then seems to be degrading. OTOH I never
>>>>>>> thought
>>>>>>> > of the
>>>>>>> > >> possibility that the USB connection could be
>>>>>>> degrading. I'm
>>>>>>> > >> going to try Greg's connector, assuming I can get
>>>>>>> parts
>>>>>>> > >> during the Apocalypse. Also, his link specifies
>>>>>>> Radio Shack
>>>>>>> > >> parts. What's Radio Shack?!? ;-)
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > >> Well folks this is getting frustrating. I addressed a
>>>>>>> possible
>>>>>>> > >> ventilation issue. I also unplugged the power cord I
>>>>>>> had from
>>>>>>> > >> the Myth box USB and connected it to an old iPad
>>>>>>> charger
>>>>>>> > rated at
>>>>>>> > >> 5V/2A. No help. It wouldn't record anything, no
>>>>>>> matter how
>>>>>>> > much
>>>>>>> > >> rebooting and power-cycling. So I concluded the HDPVR
>>>>>>> was hosed
>>>>>>> > >> and got a new one (more accurately, a replacement
>>>>>>> circuit board
>>>>>>> > >> for it). Powered it with the same wall wart. Recorded
>>>>>>> great for
>>>>>>> > >> a day. Just turned it on and I have failed recordings
>>>>>>> and it
>>>>>>> > >> won't respond when I try to manually play a channel.
>>>>>>> > Reboot, and
>>>>>>> > >> it works fine, same pattern as before.
>>>>>>> > >>
>>>>>>> > >> I finally got a molex connector and am still going to
>>>>>>> try what
>>>>>>> > >> Greg suggested, but I really don't think it's a power
>>>>>>> issue.
>>>>>>> > >> Apply makes good electronics and that wart has the
>>>>>>> same specs as
>>>>>>> > >> the power supply that comes with the HDPVR. The HDPCR
>>>>>>> isn't
>>>>>>> > >> overheating. It's not the HDPVR itself. That only
>>>>>>> leaves the
>>>>>>> > >> software on the myth box. Anyone have ideas how to
>>>>>>> troubleshoot
>>>>>>> > >> that?
>>>>>>> > >>
>>>>>>> > >>
>>>>>>> > > The next time it won't record,try to cat it and see if
>>>>>>> it
>>>>>>> > > responds. This is the command I use, cat /dev/video0
>>>>>>> > test ..
>>>>>>> > > dmesg for the proper port it's connected to. This may
>>>>>>> help
>>>>>>> > too see
>>>>>>> > > if it is the software or not..
>>>>>>> > >
>>>>>>> > > I am curious were you got the motherboard? There used
>>>>>>> to be a
>>>>>>> > > place in Ohio (I believe) ,but they have gone out of
>>>>>>> business.
>>>>>>> > >
>>>>>>> > > It failed again (despite putting the conf file in place).
>>>>>>> Here's
>>>>>>> > the
>>>>>>> > > result:
>>>>>>> > >
>>>>>>> > > steve@steve-EP45-UD3P:~$ cat /dev/video0 > test.ts
>>>>>>> > > cat: /dev/video0: Input/output error
>>>>>>> > >
>>>>>>> > > I don't know how to "dmesg for the proper port it's
>>>>>>> connected
>>>>>>> > to." I
>>>>>>> > > think it's just connected to a USB port, but I don't know
>>>>>>> how to
>>>>>>> > find
>>>>>>> > > out which one. Can you be more specific?
>>>>>>> > >
>>>>>>> > >
>>>>>>> > This works on my system
>>>>>>> >
>>>>>>> > dmesg | grep pvr
>>>>>>> > [ 6.231302] hdpvr 2-2:1.0: firmware version 0x15 dated Jun
>>>>>>> 17 2010
>>>>>>> > 09:26:53
>>>>>>> > [ 6.452748] hdpvr 2-2:1.0: device now attached to video0
>>>>>>> > [ 6.452844] usbcore: registered new interface driver hdpvr
>>>>>>> > docbuntu:~$
>>>>>>> >
>>>>>>> >
>>>>>>> > Ok next time it crashes I will try that.
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> I think the latest firmware is 0x1e from 2012. Probably won't make a
>>>>>>> difference though but you never know.
>>>>>>>
>>>>>>> It crashed again. Same result when I try to cat /dev/video0:
>>>>>> input/output error
>>>>>>
>>>>>> Here is what dmesg says:
>>>>>>
>>>>>> steve@steve-EP45-UD3P:~$ dmesg | grep pvr
>>>>>> [ 12.937541] hdpvr 2-6:1.0: firmware version 0x14 dated May 12 2010
>>>>>> 10:29:31
>>>>>> [ 12.937544] hdpvr 2-6:1.0: untested firmware, the driver might not
>>>>>> work.
>>>>>> [ 13.152225] hdpvr 2-6:1.0: device now attached to video0
>>>>>> [ 13.152252] usbcore: registered new interface driver hdpvr
>>>>>>
>>>>>> So it seems I do not have the latest device driver. I doubt this is
>>>>>> the problem as it was working fine for years with the existing device
>>>>>> driver and I've not updated anything else. But can't hurt to try. How to
>>>>>> install?
>>>>>>
>>>>>
>>>>> I looked into this and realized it was about firmware, which
>>>>> apparently can't be updated without hooking up to Windows. I don't think
>>>>> it's worth it because like I said it worked with the firmware it's got for
>>>>> quite some time.
>>>>>
>>>>> I'm out of ideas. Can you guys think of anything? I'm thinking I will
>>>>> need to just rebuild my machine with a fresh install of the lastest Ubuntu
>>>>> and see if that helps. I've been getting this "system software problem
>>>>> detected" popup a lot. Maybe that has something to do with it.
>>>>>
>>>>>>
>>>> The first generation HD-PVR was extremely sensitive to the USB port it
>>>> was plugged into. Basically did not work at all when plugged into USB3, and
>>>> was picky about the USB2 chipset as well. The only thing you have probably
>>>> not tried yet, is buying a USB2 add-on card to see if that helps. I don't
>>>> think it will, but if you are desperate to keep your HD-PVR working, then
>>>> that is the only thing I can think of.
>>>>
>>>> Your experience pretty much mirrors mine from a few years ago. My first
>>>> generation HD-PVRs slowly got less and less reliable over time. That is
>>>> what gave me the motivation to get the second generation HD-PVR working
>>>> with Myth.
>>>>
>>>> John
>>>>
>>> I thought the HDPVR2 was not Myth compatible. Has that changed?
>>>
>>>>
>> https://github.com/jpoet/HauppaugeUSB
>>
>
> Thanks!
>

Are you jpoet? Wow. That is not for the inexperienced or faint of heart
to install and configure. It scares me a little :-) I can't imagine what it
was like to develop it!

>
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 10, 2020, 4:11 AM
Post #24 of 67 (3344 views)
Permalink
>
> That is not for the inexperienced or faint of heart to install and
> configure. It scares me a little :-) I can't imagine what it was like to
> develop it!
>

Configuration is actually not as scary as it looks at first. Also, it was
quite worth it as I've found my colossus to work with higher reliability
and better quality than my HDPVR ever did.

If you're running Ubuntu - you can use the compiled binary on my Launchpad
ppa to skip the compile steps -
https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
Re: HDPVR intermittent failure [ In reply to ]
lists at qucae
Jul 11, 2020, 11:05 PM
Post #25 of 67 (3306 views)
Permalink
On 7/9/20 6:35 PM, John P Poet wrote:

>
> I thought the HDPVR2 was not Myth compatible.  Has that changed?
>
>
> https://github.com/jpoet/HauppaugeUSB
>

Do you know if the HDPVR2 is working with 1080P over component? My
cable box has recently decided to keep resetting to 1080P from 1080i
which creates failed recordings with the HDPVR.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
stephen.p.villano at gmail
Jul 11, 2020, 11:16 PM
Post #26 of 67 (1890 views)
Permalink
On 7/12/20 2:05 AM, BP wrote:
> On 7/9/20 6:35 PM, John P Poet wrote:
>
>>
>>     I thought the HDPVR2 was not Myth compatible.  Has that changed?
>>
>>
>> https://github.com/jpoet/HauppaugeUSB
>>
>
> Do you know if the HDPVR2 is working with 1080P over component? My
> cable box has recently decided to keep resetting to 1080P from 1080i
> which creates failed recordings with the HDPVR.
>
My box literally stinks to high heaven, due to a refrigerator failure.
Hint: please do describe your box and environment, otherwise, one could
be mislead in terminology from a spouse or partner with a yeast or
bacterial genital infection to a big box store central computing matrix.

And Myth and anything else is *never* complete, not even Windows,
OSX-whatever, it's always advancing.

Describe the problem more fully, include failure logs, your general
environment (your specific IP isn't good, a network described without an
IP is good), then you can get help.
Currently, your plea for help is like a global plea for help in a house
fire, entirely omitting the continent, let alone the country that you
live in.

>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 15, 2020, 9:13 PM
Post #27 of 67 (1884 views)
Permalink
On Sat, Jul 11, 2020 at 11:05 PM BP <lists@qucae.com> wrote:

> On 7/9/20 6:35 PM, John P Poet wrote:
>
> >
> > I thought the HDPVR2 was not Myth compatible. Has that changed?
> >
> >
> > https://github.com/jpoet/HauppaugeUSB
> >
>
> Do you know if the HDPVR2 is working with 1080P over component? My
> cable box has recently decided to keep resetting to 1080P from 1080i
> which creates failed recordings with the HDPVR.
>

The one I just got has no component video inputs, just HDMI.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 15, 2020, 9:20 PM
Post #28 of 67 (1884 views)
Permalink
On Wed, Jul 15, 2020 at 9:13 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Sat, Jul 11, 2020 at 11:05 PM BP <lists@qucae.com> wrote:
>
>> On 7/9/20 6:35 PM, John P Poet wrote:
>>
>> >
>> > I thought the HDPVR2 was not Myth compatible. Has that changed?
>> >
>> >
>> > https://github.com/jpoet/HauppaugeUSB
>> >
>>
>> Do you know if the HDPVR2 is working with 1080P over component? My
>> cable box has recently decided to keep resetting to 1080P from 1080i
>> which creates failed recordings with the HDPVR.
>>
>
> The one I just got has no component video inputs, just HDMI.
>
But wait! The one I just got is bare bones. The docs say "Note: HD PVR 2
will not record video from HDMI with HDCP copy protection. If you are
recording from a cable or satellite TV box, we have included a set of
Component video cables to connect to your box." So I withdraw my previous
reply, and great now I'm going to have to hunt down this cable.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 22, 2020, 9:44 AM
Post #29 of 67 (1868 views)
Permalink
On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:

> That is not for the inexperienced or faint of heart to install and
>> configure. It scares me a little :-) I can't imagine what it was like to
>> develop it!
>>
>
> Configuration is actually not as scary as it looks at first. Also, it was
> quite worth it as I've found my colossus to work with higher reliability
> and better quality than my HDPVR ever did.
>
> If you're running Ubuntu - you can use the compiled binary on my
> Launchpad ppa to skip the compile steps -
> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>

I decided to try this with my current Myth setup, and it looks like you
don't have a version for Ubuntu 16.04. So I did the compile myself.
Everything was going great until the very end of the make and I got:

g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
-pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
`pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
-I./Wrappers/linux -I./Hauppauge/Common/FX2API
-I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
-I./Hauppauge/Common/Rx/ADV7842/RX/LIB
-I./Hauppauge/Common/Rx/ADV7842/RX/HAL
-I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
-I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
-I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
-I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
-I./Hauppauge/Common/EncoderDev/HAPIHost
-I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
size_t)’:
./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
declared in this scope
memcpy(sendbuff + 1, data, len);
^
Makefile:61: recipe for target 'audio_CS8416.o' failed
make: *** [audio_CS8416.o] Error 1

What to do?
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 22, 2020, 1:07 PM
Post #30 of 67 (1868 views)
Permalink
On Wed, Jul 22, 2020 at 9:44 AM DryHeat122 <dryheat122@gmail.com> wrote:

> On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:
>
>> That is not for the inexperienced or faint of heart to install and
>>> configure. It scares me a little :-) I can't imagine what it was like to
>>> develop it!
>>>
>>
>> Configuration is actually not as scary as it looks at first. Also, it
>> was quite worth it as I've found my colossus to work with higher
>> reliability and better quality than my HDPVR ever did.
>>
>> If you're running Ubuntu - you can use the compiled binary on my
>> Launchpad ppa to skip the compile steps -
>> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>>
>
> I decided to try this with my current Myth setup, and it looks like you
> don't have a version for Ubuntu 16.04. So I did the compile myself.
> Everything was going great until the very end of the make and I got:
>
> g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
> -pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
> `pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
> -I./Wrappers/linux -I./Hauppauge/Common/FX2API
> -I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
> -I./Hauppauge/Common/Rx/ADV7842/RX/LIB
> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL
> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
> -I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
> -I./Hauppauge/Common/EncoderDev/HAPIHost
> -I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
> libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
> ./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
> audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
> size_t)’:
> ./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
> declared in this scope
> memcpy(sendbuff + 1, data, len);
> ^
> Makefile:61: recipe for target 'audio_CS8416.o' failed
> make: *** [audio_CS8416.o] Error 1
>
> What to do?
>

I know next to nothing about cpp but I looked up the error, and it seems to
be caused by failure to declare #include <cstring> I added that to the top
of audio_CS8416.cpp and the build completed without errors.
Perhaps @JohnPoet would like to add this to the patches?

Bottom line is that I now have it working. Here are a couple of notes for
others trying this:

When I first connected the HDPVR2 the light was rapid flashing blue which
according to docs means the machine can't "see" it. When I tried to record
I got a repeated error:

2020-07-22T12:15:53.632520 ERRR <main> USBif.cpp:485 (controlMessage)
cannot send control message: No such device (it may have been disconnected)

But after exiting the commsn the light was solid blue. So I tried again
and got

2020-07-22T12:16:42.638981 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
Changing loglevel to NOTC
2020-07-22T12:16:42.639124 CRIT <main> hauppauge2.cpp:347 (main) Starting up
2020-07-22T12:16:42.650486 CRIT <main> hauppauge2.cpp:360 (main)
Initializing [Bus: 2, Port: 6] E524-00-00ABAE4A
[long pause]
2020-07-22T12:17:05.061224 CRIT <main> HauppaugeDev.cpp:392
(init_component) Cannot determine video mode.
2020-07-22T12:17:05.362389 CRIT <main> hauppauge2.cpp:476 (main) Done.

I discovered that the second to last error means there is no video signal.
My cable box was off. After turning it on I got a recording.

For the devs, I did get one error:

2020-07-22T12:50:50.152620 ERRR <main> FX2Device.cpp:115 (I2CWriteRead)
I2C: Improper answer: status 07

I don't know what it means, but it didn't prevent the recording.

Thanks for all the help everyone!
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 22, 2020, 4:04 PM
Post #31 of 67 (1866 views)
Permalink
>
> I decided to try this with my current Myth setup, and it looks like you
> don't have a version for Ubuntu 16.04.
>

Correct - sorry about that. Unfortunately launchpad blocks the upload for
no longer supported versions of Ubuntu. I used to have a Xenial
build posted, but dropped it when I ran out of space in launchpad.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 22, 2020, 4:10 PM
Post #32 of 67 (1866 views)
Permalink
On Wed, Jul 22, 2020 at 1:07 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Wed, Jul 22, 2020 at 9:44 AM DryHeat122 <dryheat122@gmail.com> wrote:
>
>> On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:
>>
>>> That is not for the inexperienced or faint of heart to install and
>>>> configure. It scares me a little :-) I can't imagine what it was like to
>>>> develop it!
>>>>
>>>
>>> Configuration is actually not as scary as it looks at first. Also, it
>>> was quite worth it as I've found my colossus to work with higher
>>> reliability and better quality than my HDPVR ever did.
>>>
>>> If you're running Ubuntu - you can use the compiled binary on my
>>> Launchpad ppa to skip the compile steps -
>>> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>>>
>>
>> I decided to try this with my current Myth setup, and it looks like you
>> don't have a version for Ubuntu 16.04. So I did the compile myself.
>> Everything was going great until the very end of the make and I got:
>>
>> g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
>> -pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
>> `pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
>> -I./Wrappers/linux -I./Hauppauge/Common/FX2API
>> -I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
>> -I./Hauppauge/Common/Rx/ADV7842/RX/LIB
>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL
>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
>> -I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
>> -I./Hauppauge/Common/EncoderDev/HAPIHost
>> -I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
>> libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
>> ./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
>> audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
>> size_t)’:
>> ./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
>> declared in this scope
>> memcpy(sendbuff + 1, data, len);
>> ^
>> Makefile:61: recipe for target 'audio_CS8416.o' failed
>> make: *** [audio_CS8416.o] Error 1
>>
>> What to do?
>>
>
> I know next to nothing about cpp but I looked up the error, and it seems
> to be caused by failure to declare #include <cstring> I added that to the
> top of audio_CS8416.cpp and the build completed without errors.
> Perhaps @JohnPoet would like to add this to the patches?
>
> Bottom line is that I now have it working. Here are a couple of notes for
> others trying this:
>
> When I first connected the HDPVR2 the light was rapid flashing blue which
> according to docs means the machine can't "see" it. When I tried to record
> I got a repeated error:
>
> 2020-07-22T12:15:53.632520 ERRR <main> USBif.cpp:485 (controlMessage)
> cannot send control message: No such device (it may have been disconnected)
>
> But after exiting the commsn the light was solid blue. So I tried again
> and got
>
> 2020-07-22T12:16:42.638981 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
> Changing loglevel to NOTC
> 2020-07-22T12:16:42.639124 CRIT <main> hauppauge2.cpp:347 (main) Starting
> up
> 2020-07-22T12:16:42.650486 CRIT <main> hauppauge2.cpp:360 (main)
> Initializing [Bus: 2, Port: 6] E524-00-00ABAE4A
> [long pause]
> 2020-07-22T12:17:05.061224 CRIT <main> HauppaugeDev.cpp:392
> (init_component) Cannot determine video mode.
> 2020-07-22T12:17:05.362389 CRIT <main> hauppauge2.cpp:476 (main) Done.
>
> I discovered that the second to last error means there is no video
> signal. My cable box was off. After turning it on I got a recording.
>
> For the devs, I did get one error:
>
> 2020-07-22T12:50:50.152620 ERRR <main> FX2Device.cpp:115 (I2CWriteRead)
> I2C: Improper answer: status 07
>
> I don't know what it means, but it didn't prevent the recording.
>
> Thanks for all the help everyone!
>

Sooooo...having the HDPVR2 making test recordings, I set it up in Myth per
the instructions in the https://github.com/jpoet/HauppaugeUSB. When I try
to record anything, say from the program guide, it says "recorder offline"
and I can find nothing in the frontend or backend logs about it. However,
the recorder shows the half-green lite indicating it's ready and I can
still do test recordings. How to troubleshoot?
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 22, 2020, 5:31 PM
Post #33 of 67 (1862 views)
Permalink
On Wed, Jul 22, 2020 at 5:12 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Wed, Jul 22, 2020 at 1:07 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 22, 2020 at 9:44 AM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>> On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:
>>>
>>>> That is not for the inexperienced or faint of heart to install and
>>>>> configure. It scares me a little :-) I can't imagine what it was like to
>>>>> develop it!
>>>>>
>>>>
>>>> Configuration is actually not as scary as it looks at first. Also, it
>>>> was quite worth it as I've found my colossus to work with higher
>>>> reliability and better quality than my HDPVR ever did.
>>>>
>>>> If you're running Ubuntu - you can use the compiled binary on my
>>>> Launchpad ppa to skip the compile steps -
>>>> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>>>>
>>>
>>> I decided to try this with my current Myth setup, and it looks like you
>>> don't have a version for Ubuntu 16.04. So I did the compile myself.
>>> Everything was going great until the very end of the make and I got:
>>>
>>> g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
>>> -pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
>>> `pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
>>> -I./Wrappers/linux -I./Hauppauge/Common/FX2API
>>> -I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
>>> -I./Hauppauge/Common/Rx/ADV7842/RX/LIB
>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL
>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
>>> -I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
>>> -I./Hauppauge/Common/EncoderDev/HAPIHost
>>> -I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
>>> libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
>>> audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
>>> size_t)’:
>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
>>> declared in this scope
>>> memcpy(sendbuff + 1, data, len);
>>> ^
>>> Makefile:61: recipe for target 'audio_CS8416.o' failed
>>> make: *** [audio_CS8416.o] Error 1
>>>
>>> What to do?
>>>
>>
>> I know next to nothing about cpp but I looked up the error, and it seems
>> to be caused by failure to declare #include <cstring> I added that to the
>> top of audio_CS8416.cpp and the build completed without errors.
>> Perhaps @JohnPoet would like to add this to the patches?
>>
>> Bottom line is that I now have it working. Here are a couple of notes
>> for others trying this:
>>
>> When I first connected the HDPVR2 the light was rapid flashing blue which
>> according to docs means the machine can't "see" it. When I tried to record
>> I got a repeated error:
>>
>> 2020-07-22T12:15:53.632520 ERRR <main> USBif.cpp:485 (controlMessage)
>> cannot send control message: No such device (it may have been disconnected)
>>
>> But after exiting the commsn the light was solid blue. So I tried again
>> and got
>>
>> 2020-07-22T12:16:42.638981 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
>> Changing loglevel to NOTC
>> 2020-07-22T12:16:42.639124 CRIT <main> hauppauge2.cpp:347 (main) Starting
>> up
>> 2020-07-22T12:16:42.650486 CRIT <main> hauppauge2.cpp:360 (main)
>> Initializing [Bus: 2, Port: 6] E524-00-00ABAE4A
>> [long pause]
>> 2020-07-22T12:17:05.061224 CRIT <main> HauppaugeDev.cpp:392
>> (init_component) Cannot determine video mode.
>> 2020-07-22T12:17:05.362389 CRIT <main> hauppauge2.cpp:476 (main) Done.
>>
>> I discovered that the second to last error means there is no video
>> signal. My cable box was off. After turning it on I got a recording.
>>
>> For the devs, I did get one error:
>>
>> 2020-07-22T12:50:50.152620 ERRR <main> FX2Device.cpp:115 (I2CWriteRead)
>> I2C: Improper answer: status 07
>>
>> I don't know what it means, but it didn't prevent the recording.
>>
>> Thanks for all the help everyone!
>>
>
> Sooooo...having the HDPVR2 making test recordings, I set it up in Myth per
> the instructions in the https://github.com/jpoet/HauppaugeUSB. When I
> try to record anything, say from the program guide, it says "recorder
> offline" and I can find nothing in the frontend or backend logs about it.
> However, the recorder shows the half-green lite indicating it's ready and I
> can still do test recordings. How to troubleshoot?
>

My first guess would be a permission problem. The HD-PVR2 externalrecorder
process will run as the same user as mythbackend. If that user does not
have permission to write its log file, for example, it will fail.

Run mythbackend with "-v channel,record", if you are not already. The
mythbackend log should show the reason for the error.

John
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 22, 2020, 5:47 PM
Post #34 of 67 (1862 views)
Permalink
That was it...I had the wrong group in the config file. Now Myth no longer
says the recorder is offline, the recordings are merely failing. So that's
progress?

I think it might be failing because my channel changer is failing, and that
is because my FireWire seems to be hosed. plugreport returns nothing,
firewire_tester can't connect to any port.

This is bizarre because FireWire and the channel changer was working until
I started the recorder changeover this morning. Can you think of any reason
the HDPVR2 software would affect FireWire?

On Wed, Jul 22, 2020, 5:31 PM John P Poet <jppoet@gmail.com> wrote:

> On Wed, Jul 22, 2020 at 5:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 22, 2020 at 1:07 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 22, 2020 at 9:44 AM DryHeat122 <dryheat122@gmail.com> wrote:
>>>
>>>> On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:
>>>>
>>>>> That is not for the inexperienced or faint of heart to install and
>>>>>> configure. It scares me a little :-) I can't imagine what it was like to
>>>>>> develop it!
>>>>>>
>>>>>
>>>>> Configuration is actually not as scary as it looks at first. Also, it
>>>>> was quite worth it as I've found my colossus to work with higher
>>>>> reliability and better quality than my HDPVR ever did.
>>>>>
>>>>> If you're running Ubuntu - you can use the compiled binary on my
>>>>> Launchpad ppa to skip the compile steps -
>>>>> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>>>>>
>>>>
>>>> I decided to try this with my current Myth setup, and it looks like you
>>>> don't have a version for Ubuntu 16.04. So I did the compile myself.
>>>> Everything was going great until the very end of the make and I got:
>>>>
>>>> g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
>>>> -pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
>>>> `pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
>>>> -I./Wrappers/linux -I./Hauppauge/Common/FX2API
>>>> -I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/LIB
>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL
>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
>>>> -I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
>>>> -I./Hauppauge/Common/EncoderDev/HAPIHost
>>>> -I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
>>>> libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
>>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
>>>> audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
>>>> size_t)’:
>>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
>>>> declared in this scope
>>>> memcpy(sendbuff + 1, data, len);
>>>> ^
>>>> Makefile:61: recipe for target 'audio_CS8416.o' failed
>>>> make: *** [audio_CS8416.o] Error 1
>>>>
>>>> What to do?
>>>>
>>>
>>> I know next to nothing about cpp but I looked up the error, and it seems
>>> to be caused by failure to declare #include <cstring> I added that to the
>>> top of audio_CS8416.cpp and the build completed without errors.
>>> Perhaps @JohnPoet would like to add this to the patches?
>>>
>>> Bottom line is that I now have it working. Here are a couple of notes
>>> for others trying this:
>>>
>>> When I first connected the HDPVR2 the light was rapid flashing blue
>>> which according to docs means the machine can't "see" it. When I tried to
>>> record I got a repeated error:
>>>
>>> 2020-07-22T12:15:53.632520 ERRR <main> USBif.cpp:485 (controlMessage)
>>> cannot send control message: No such device (it may have been disconnected)
>>>
>>> But after exiting the commsn the light was solid blue. So I tried again
>>> and got
>>>
>>> 2020-07-22T12:16:42.638981 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
>>> Changing loglevel to NOTC
>>> 2020-07-22T12:16:42.639124 CRIT <main> hauppauge2.cpp:347 (main)
>>> Starting up
>>> 2020-07-22T12:16:42.650486 CRIT <main> hauppauge2.cpp:360 (main)
>>> Initializing [Bus: 2, Port: 6] E524-00-00ABAE4A
>>> [long pause]
>>> 2020-07-22T12:17:05.061224 CRIT <main> HauppaugeDev.cpp:392
>>> (init_component) Cannot determine video mode.
>>> 2020-07-22T12:17:05.362389 CRIT <main> hauppauge2.cpp:476 (main) Done.
>>>
>>> I discovered that the second to last error means there is no video
>>> signal. My cable box was off. After turning it on I got a recording.
>>>
>>> For the devs, I did get one error:
>>>
>>> 2020-07-22T12:50:50.152620 ERRR <main> FX2Device.cpp:115 (I2CWriteRead)
>>> I2C: Improper answer: status 07
>>>
>>> I don't know what it means, but it didn't prevent the recording.
>>>
>>> Thanks for all the help everyone!
>>>
>>
>> Sooooo...having the HDPVR2 making test recordings, I set it up in Myth
>> per the instructions in the https://github.com/jpoet/HauppaugeUSB. When
>> I try to record anything, say from the program guide, it says "recorder
>> offline" and I can find nothing in the frontend or backend logs about it.
>> However, the recorder shows the half-green lite indicating it's ready and I
>> can still do test recordings. How to troubleshoot?
>>
>
> My first guess would be a permission problem. The HD-PVR2 externalrecorder
> process will run as the same user as mythbackend. If that user does not
> have permission to write its log file, for example, it will fail.
>
> Run mythbackend with "-v channel,record", if you are not already. The
> mythbackend log should show the reason for the error.
>
> John
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 25, 2020, 8:44 AM
Post #35 of 67 (1853 views)
Permalink
After successfully building this on my Ubuntu 16.04 box, I tried building
it again on my new 20.04 box. This time I got the following errors when
running make:

../../Common/EncoderDev/encoderDev_DXT.cpp: In destructor 'virtual
encoderDev_DXT_t::~encoderDev_DXT_t()':
../../Common/EncoderDev/encoderDev_DXT.cpp:13:2: error: 'wrapLogInfo' was
not declared in this scope; did you mean 'wrapLogError'?
13 | wrapLogInfo("encoderDev_DXT_t::~encoderDev_DXT_t()");
| ^~~~~~~~~~~
| wrapLogError
../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
bool encoderDev_DXT_t::init()':
../../Common/EncoderDev/encoderDev_DXT.cpp:24:2: error: 'wrapLogInfo' was
not declared in this scope; did you mean 'wrapLogError'?
24 | wrapLogInfo("encoderDev_DXT_t::init()");
| ^~~~~~~~~~~
| wrapLogError
../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
bool encoderDev_DXT_t::startCapture()':
../../Common/EncoderDev/encoderDev_DXT.cpp:183:2: error: 'wrapLogInfo' was
not declared in this scope; did you mean 'wrapLogError'?
183 | wrapLogInfo("encoderDev_DXT_t::startCapture()");
| ^~~~~~~~~~~
| wrapLogError
../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
bool encoderDev_DXT_t::stopCapture()':
../../Common/EncoderDev/encoderDev_DXT.cpp:190:2: error: 'wrapLogInfo' was
not declared in this scope; did you mean 'wrapLogError'?
190 | wrapLogInfo("encoderDev_DXT_t::stopCapture()");
| ^~~~~~~~~~~
| wrapLogError
make[1]: *** [<builtin>: encoderDev_DXT.o] Error 1
make[1]: Leaving directory
'/home/steve/src/Hauppauge/hauppauge_hdpvr2_157321_patched_2016-09-26/TestApp/build-ADV7842'
make: *** [Makefile:2: all] Error 2

How to fix? Change wrapLogInfo to wrapLogError as suggested?

On Wed, Jul 22, 2020 at 5:47 PM DryHeat122 <dryheat122@gmail.com> wrote:

> That was it...I had the wrong group in the config file. Now Myth no
> longer says the recorder is offline, the recordings are merely failing. So
> that's progress?
>
> I think it might be failing because my channel changer is failing, and
> that is because my FireWire seems to be hosed. plugreport returns nothing,
> firewire_tester can't connect to any port.
>
> This is bizarre because FireWire and the channel changer was working until
> I started the recorder changeover this morning. Can you think of any reason
> the HDPVR2 software would affect FireWire?
>
> On Wed, Jul 22, 2020, 5:31 PM John P Poet <jppoet@gmail.com> wrote:
>
>> On Wed, Jul 22, 2020 at 5:12 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 22, 2020 at 1:07 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 22, 2020 at 9:44 AM DryHeat122 <dryheat122@gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, Jul 10, 2020 at 4:12 AM John Hoyt <john.hoyt@gmail.com> wrote:
>>>>>
>>>>>> That is not for the inexperienced or faint of heart to install and
>>>>>>> configure. It scares me a little :-) I can't imagine what it was like to
>>>>>>> develop it!
>>>>>>>
>>>>>>
>>>>>> Configuration is actually not as scary as it looks at first. Also,
>>>>>> it was quite worth it as I've found my colossus to work with higher
>>>>>> reliability and better quality than my HDPVR ever did.
>>>>>>
>>>>>> If you're running Ubuntu - you can use the compiled binary on my
>>>>>> Launchpad ppa to skip the compile steps -
>>>>>> https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb
>>>>>>
>>>>>
>>>>> I decided to try this with my current Myth setup, and it looks like
>>>>> you don't have a version for Ubuntu 16.04. So I did the compile myself.
>>>>> Everything was going great until the very end of the make and I got:
>>>>>
>>>>> g++ -g -c -Wall -std=c++11 -fdiagnostics-color -DBOOST_LOG_DYN_LINK
>>>>> -pthread -m64 -g -O3 -D_GNU_SOURCE -DDRIVER_BUILD -DHAUPPAUGE -DHCW_E5BDA
>>>>> `pkg-config --cflags libusb-1.0` -I.. -I./Hauppauge/Common
>>>>> -I./Wrappers/linux -I./Hauppauge/Common/FX2API
>>>>> -I./Hauppauge/Common/Rx/ADV7842 -I./Hauppauge/Common/Rx/ADV7842/RX
>>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/LIB
>>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL
>>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G
>>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/HAL
>>>>> -I./Hauppauge/Common/Rx/ADV7842/RX/HAL/4G/ADV7842/MACROS
>>>>> -I./Hauppauge/Common/Rx -I./Hauppauge/Common/EncoderDev
>>>>> -I./Hauppauge/Common/EncoderDev/HAPIHost
>>>>> -I./Hauppauge/Common/EncoderDev/HAPIHost/MChip `pkg-config --cflags
>>>>> libusb-1.0` ./Hauppauge/Common/Rx/audio_CS8416.cpp -o audio_CS8416.o
>>>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp: In member function ‘bool
>>>>> audio_CS8416::DeviceIO::write(audio_CS8416::DeviceIO::Reg, const uint8_t*,
>>>>> size_t)’:
>>>>> ./Hauppauge/Common/Rx/audio_CS8416.cpp:173:39: error: ‘memcpy’ was not
>>>>> declared in this scope
>>>>> memcpy(sendbuff + 1, data, len);
>>>>> ^
>>>>> Makefile:61: recipe for target 'audio_CS8416.o' failed
>>>>> make: *** [audio_CS8416.o] Error 1
>>>>>
>>>>> What to do?
>>>>>
>>>>
>>>> I know next to nothing about cpp but I looked up the error, and it
>>>> seems to be caused by failure to declare #include <cstring> I added that
>>>> to the top of audio_CS8416.cpp and the build completed without errors.
>>>> Perhaps @JohnPoet would like to add this to the patches?
>>>>
>>>> Bottom line is that I now have it working. Here are a couple of notes
>>>> for others trying this:
>>>>
>>>> When I first connected the HDPVR2 the light was rapid flashing blue
>>>> which according to docs means the machine can't "see" it. When I tried to
>>>> record I got a repeated error:
>>>>
>>>> 2020-07-22T12:15:53.632520 ERRR <main> USBif.cpp:485 (controlMessage)
>>>> cannot send control message: No such device (it may have been disconnected)
>>>>
>>>> But after exiting the commsn the light was solid blue. So I tried
>>>> again and got
>>>>
>>>> 2020-07-22T12:16:42.638981 CRIT <main> Logger.cpp:83
>>>> (setLogLevelFilter) Changing loglevel to NOTC
>>>> 2020-07-22T12:16:42.639124 CRIT <main> hauppauge2.cpp:347 (main)
>>>> Starting up
>>>> 2020-07-22T12:16:42.650486 CRIT <main> hauppauge2.cpp:360 (main)
>>>> Initializing [Bus: 2, Port: 6] E524-00-00ABAE4A
>>>> [long pause]
>>>> 2020-07-22T12:17:05.061224 CRIT <main> HauppaugeDev.cpp:392
>>>> (init_component) Cannot determine video mode.
>>>> 2020-07-22T12:17:05.362389 CRIT <main> hauppauge2.cpp:476 (main) Done.
>>>>
>>>> I discovered that the second to last error means there is no video
>>>> signal. My cable box was off. After turning it on I got a recording.
>>>>
>>>> For the devs, I did get one error:
>>>>
>>>> 2020-07-22T12:50:50.152620 ERRR <main> FX2Device.cpp:115 (I2CWriteRead)
>>>> I2C: Improper answer: status 07
>>>>
>>>> I don't know what it means, but it didn't prevent the recording.
>>>>
>>>> Thanks for all the help everyone!
>>>>
>>>
>>> Sooooo...having the HDPVR2 making test recordings, I set it up in Myth
>>> per the instructions in the https://github.com/jpoet/HauppaugeUSB.
>>> When I try to record anything, say from the program guide, it says
>>> "recorder offline" and I can find nothing in the frontend or backend logs
>>> about it. However, the recorder shows the half-green lite indicating it's
>>> ready and I can still do test recordings. How to troubleshoot?
>>>
>>
>> My first guess would be a permission problem. The HD-PVR2
>> externalrecorder process will run as the same user as mythbackend. If that
>> user does not have permission to write its log file, for example, it will
>> fail.
>>
>> Run mythbackend with "-v channel,record", if you are not already. The
>> mythbackend log should show the reason for the error.
>>
>> John
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 25, 2020, 10:47 AM
Post #36 of 67 (1851 views)
Permalink
On Sat, Jul 25, 2020 at 9:46 AM DryHeat122 <dryheat122@gmail.com> wrote:

> After successfully building this on my Ubuntu 16.04 box, I tried building
> it again on my new 20.04 box. This time I got the following errors when
> running make:
>
> ../../Common/EncoderDev/encoderDev_DXT.cpp: In destructor 'virtual
> encoderDev_DXT_t::~encoderDev_DXT_t()':
> ../../Common/EncoderDev/encoderDev_DXT.cpp:13:2: error: 'wrapLogInfo' was
> not declared in this scope; did you mean 'wrapLogError'?
> 13 | wrapLogInfo("encoderDev_DXT_t::~encoderDev_DXT_t()");
> | ^~~~~~~~~~~
> | wrapLogError
> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
> bool encoderDev_DXT_t::init()':
> ../../Common/EncoderDev/encoderDev_DXT.cpp:24:2: error: 'wrapLogInfo' was
> not declared in this scope; did you mean 'wrapLogError'?
> 24 | wrapLogInfo("encoderDev_DXT_t::init()");
> | ^~~~~~~~~~~
> | wrapLogError
> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
> bool encoderDev_DXT_t::startCapture()':
> ../../Common/EncoderDev/encoderDev_DXT.cpp:183:2: error: 'wrapLogInfo' was
> not declared in this scope; did you mean 'wrapLogError'?
> 183 | wrapLogInfo("encoderDev_DXT_t::startCapture()");
> | ^~~~~~~~~~~
> | wrapLogError
> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
> bool encoderDev_DXT_t::stopCapture()':
> ../../Common/EncoderDev/encoderDev_DXT.cpp:190:2: error: 'wrapLogInfo' was
> not declared in this scope; did you mean 'wrapLogError'?
> 190 | wrapLogInfo("encoderDev_DXT_t::stopCapture()");
> | ^~~~~~~~~~~
> | wrapLogError
> make[1]: *** [<builtin>: encoderDev_DXT.o] Error 1
> make[1]: Leaving directory
> '/home/steve/src/Hauppauge/hauppauge_hdpvr2_157321_patched_2016-09-26/TestApp/build-ADV7842'
> make: *** [Makefile:2: all] Error 2
>
> How to fix? Change wrapLogInfo to wrapLogError as suggested?
>

When you built it on 20.04, did you start from scratch? If not, I would
give that a try as it is possible the layers of patches are causing an
issue.
If you already did start from scratch, you may need to wait for another
ubuntu user to step up and help as it may be an issue with the base OS.

John
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 25, 2020, 10:50 AM
Post #37 of 67 (1851 views)
Permalink
If by "start from scratch" you mean follow the instructions on your git
page, yes I did that. Do you know if it works as-is on 18.04, because I am
not so far along in the process I couldn't bail out and install that
instead.

On Sat, Jul 25, 2020 at 10:47 AM John P Poet <jppoet@gmail.com> wrote:

> On Sat, Jul 25, 2020 at 9:46 AM DryHeat122 <dryheat122@gmail.com> wrote:
>
>> After successfully building this on my Ubuntu 16.04 box, I tried building
>> it again on my new 20.04 box. This time I got the following errors when
>> running make:
>>
>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In destructor 'virtual
>> encoderDev_DXT_t::~encoderDev_DXT_t()':
>> ../../Common/EncoderDev/encoderDev_DXT.cpp:13:2: error: 'wrapLogInfo' was
>> not declared in this scope; did you mean 'wrapLogError'?
>> 13 | wrapLogInfo("encoderDev_DXT_t::~encoderDev_DXT_t()");
>> | ^~~~~~~~~~~
>> | wrapLogError
>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>> bool encoderDev_DXT_t::init()':
>> ../../Common/EncoderDev/encoderDev_DXT.cpp:24:2: error: 'wrapLogInfo' was
>> not declared in this scope; did you mean 'wrapLogError'?
>> 24 | wrapLogInfo("encoderDev_DXT_t::init()");
>> | ^~~~~~~~~~~
>> | wrapLogError
>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>> bool encoderDev_DXT_t::startCapture()':
>> ../../Common/EncoderDev/encoderDev_DXT.cpp:183:2: error: 'wrapLogInfo'
>> was not declared in this scope; did you mean 'wrapLogError'?
>> 183 | wrapLogInfo("encoderDev_DXT_t::startCapture()");
>> | ^~~~~~~~~~~
>> | wrapLogError
>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>> bool encoderDev_DXT_t::stopCapture()':
>> ../../Common/EncoderDev/encoderDev_DXT.cpp:190:2: error: 'wrapLogInfo'
>> was not declared in this scope; did you mean 'wrapLogError'?
>> 190 | wrapLogInfo("encoderDev_DXT_t::stopCapture()");
>> | ^~~~~~~~~~~
>> | wrapLogError
>> make[1]: *** [<builtin>: encoderDev_DXT.o] Error 1
>> make[1]: Leaving directory
>> '/home/steve/src/Hauppauge/hauppauge_hdpvr2_157321_patched_2016-09-26/TestApp/build-ADV7842'
>> make: *** [Makefile:2: all] Error 2
>>
>> How to fix? Change wrapLogInfo to wrapLogError as suggested?
>>
>
> When you built it on 20.04, did you start from scratch? If not, I would
> give that a try as it is possible the layers of patches are causing an
> issue.
> If you already did start from scratch, you may need to wait for another
> ubuntu user to step up and help as it may be an issue with the base OS.
>
> John
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 25, 2020, 10:59 AM
Post #38 of 67 (1851 views)
Permalink
On Sat, Jul 25, 2020 at 11:52 AM DryHeat122 <dryheat122@gmail.com> wrote:

> If by "start from scratch" you mean follow the instructions on your git
> page, yes I did that. Do you know if it works as-is on 18.04, because I am
> not so far along in the process I couldn't bail out and install that
> instead.
>
> On Sat, Jul 25, 2020 at 10:47 AM John P Poet <jppoet@gmail.com> wrote:
>
>> On Sat, Jul 25, 2020 at 9:46 AM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>> After successfully building this on my Ubuntu 16.04 box, I tried
>>> building it again on my new 20.04 box. This time I got the following errors
>>> when running make:
>>>
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In destructor 'virtual
>>> encoderDev_DXT_t::~encoderDev_DXT_t()':
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp:13:2: error: 'wrapLogInfo'
>>> was not declared in this scope; did you mean 'wrapLogError'?
>>> 13 | wrapLogInfo("encoderDev_DXT_t::~encoderDev_DXT_t()");
>>> | ^~~~~~~~~~~
>>> | wrapLogError
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>>> bool encoderDev_DXT_t::init()':
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp:24:2: error: 'wrapLogInfo'
>>> was not declared in this scope; did you mean 'wrapLogError'?
>>> 24 | wrapLogInfo("encoderDev_DXT_t::init()");
>>> | ^~~~~~~~~~~
>>> | wrapLogError
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>>> bool encoderDev_DXT_t::startCapture()':
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp:183:2: error: 'wrapLogInfo'
>>> was not declared in this scope; did you mean 'wrapLogError'?
>>> 183 | wrapLogInfo("encoderDev_DXT_t::startCapture()");
>>> | ^~~~~~~~~~~
>>> | wrapLogError
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp: In member function 'virtual
>>> bool encoderDev_DXT_t::stopCapture()':
>>> ../../Common/EncoderDev/encoderDev_DXT.cpp:190:2: error: 'wrapLogInfo'
>>> was not declared in this scope; did you mean 'wrapLogError'?
>>> 190 | wrapLogInfo("encoderDev_DXT_t::stopCapture()");
>>> | ^~~~~~~~~~~
>>> | wrapLogError
>>> make[1]: *** [<builtin>: encoderDev_DXT.o] Error 1
>>> make[1]: Leaving directory
>>> '/home/steve/src/Hauppauge/hauppauge_hdpvr2_157321_patched_2016-09-26/TestApp/build-ADV7842'
>>> make: *** [Makefile:2: all] Error 2
>>>
>>> How to fix? Change wrapLogInfo to wrapLogError as suggested?
>>>
>>
>> When you built it on 20.04, did you start from scratch? If not, I would
>> give that a try as it is possible the layers of patches are causing an
>> issue.
>> If you already did start from scratch, you may need to wait for another
>> ubuntu user to step up and help as it may be an issue with the base OS.
>>
>> John
>>
>
Please do not top-post. Mailing list convention is to bottom post.

I am a Fedora user, but I know this package has been used by Ubuntu users.
I assume it works on 20.04 and 18.04, but I cannot guarantee it.

John
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 25, 2020, 11:17 AM
Post #39 of 67 (1851 views)
Permalink
>
> Please do not top-post. Mailing list convention is to bottom post.
>
> I am a Fedora user, but I know this package has been used by Ubuntu users.
> I assume it works on 20.04 and 18.04, but I cannot guarantee it.
>

It works and has been tested on Ubuntu 18.04, 18.10, 19.04, 19.10, and
20.04. I have built in manually and also have it building on launchpad for
all of versions listed.

I successfully compiled following the instructions on jpoet's github site
(literally just copying and pasting) and am able to get it to compile
without any issues.

Steve, unfortunately, I recognize "it works for me" is not what you're
looking for but I suspect it indicates you have either a setup issue
(missing dependencies or are modifying the instructions slightly).

Did you run "sudo apt-get install libboost-log-dev
libboost-program-options-dev libusb-1.0-0-dev build-essential'?
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 25, 2020, 11:31 AM
Post #40 of 67 (1851 views)
Permalink
On Sat, Jul 25, 2020 at 11:18 AM John Hoyt <john.hoyt@gmail.com> wrote:

> Please do not top-post. Mailing list convention is to bottom post.
>>
>> I am a Fedora user, but I know this package has been used by Ubuntu
>> users. I assume it works on 20.04 and 18.04, but I cannot guarantee it.
>>
>
> It works and has been tested on Ubuntu 18.04, 18.10, 19.04, 19.10, and
> 20.04. I have built in manually and also have it building on launchpad for
> all of versions listed.
>
> I successfully compiled following the instructions on jpoet's github site
> (literally just copying and pasting) and am able to get it to compile
> without any issues.
>
> Steve, unfortunately, I recognize "it works for me" is not what you're
> looking for but I suspect it indicates you have either a setup issue
> (missing dependencies or are modifying the instructions slightly).
>
> Did you run "sudo apt-get install libboost-log-dev
> libboost-program-options-dev libusb-1.0-0-dev build-essential'?
>

Thanks @JohnPoet and @JohnHoyt, sorry about the earlier top-post. I know
that's the norm but gmail works against it and I just forgot. I will go
through the build process again. Meanwhile @JohnHoyt I have not used
launchpad before. Can you point to instructions for getting your 20.04
build off of there?
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 25, 2020, 11:35 AM
Post #41 of 67 (1851 views)
Permalink
>
> Thanks @JohnPoet and @JohnHoyt, sorry about the earlier top-post. I know
> that's the norm but gmail works against it and I just forgot. I will go
> through the build process again. Meanwhile @JohnHoyt I have not used
> launchpad before. Can you point to instructions for getting your 20.04
> build off of there?
>

You need to add my repo with these commands:

sudo add-apt-repository ppa:john-hoyt/hauppaugeusb
sudo apt-get update

The can install the "drivers" with

sudo apt-get install hauppaugeusb
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 25, 2020, 4:38 PM
Post #42 of 67 (1850 views)
Permalink
>
>
> You need to add my repo with these commands:
>
> sudo add-apt-repository ppa:john-hoyt/hauppaugeusb
> sudo apt-get update
>
> The can install the "drivers" with
>
> sudo apt-get install hauppaugeusb
>

BTW - I should add that you'll still need to setup udev rules and the
config file and setup mythtv to use it as an external recorder. The PPA
pretty much only lets you skip the compile and install pieces.
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 26, 2020, 2:35 PM
Post #43 of 67 (1846 views)
Permalink
On Sat, Jul 25, 2020 at 4:39 PM John Hoyt <john.hoyt@gmail.com> wrote:

>
>> You need to add my repo with these commands:
>>
>> sudo add-apt-repository ppa:john-hoyt/hauppaugeusb
>> sudo apt-get update
>>
>> The can install the "drivers" with
>>
>> sudo apt-get install hauppaugeusb
>>
>
> BTW - I should add that you'll still need to setup udev rules and the
> config file and setup mythtv to use it as an external recorder. The PPA
> pretty much only lets you skip the compile and install pieces.
>

After connecting to the repository and running the install, there is
nothing in /opt
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 26, 2020, 3:32 PM
Post #44 of 67 (1846 views)
Permalink
>
> After connecting to the repository and running the install, there is
> nothing in /opt
>

That's strange. Did apt give you any errors? Also, what version of
ubuntu did you land on?

What does the output of "dpkg-query -L hauppaugeusb" give you?
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 26, 2020, 3:33 PM
Post #45 of 67 (1846 views)
Permalink
On Sun, Jul 26, 2020 at 6:32 PM John Hoyt <john.hoyt@gmail.com> wrote:

> After connecting to the repository and running the install, there is
>> nothing in /opt
>>
>
> That's strange. Did apt give you any errors? Also, what version of
> ubuntu did you land on?
>
> What does the output of "dpkg-query -L hauppaugeusb" give you?
>

Here's what mine outputs:

dpkg-query -L hauppaugeusb
/.
/opt
/opt/Hauppauge
/opt/Hauppauge/bin
/opt/Hauppauge/bin/hauppauge2
/opt/Hauppauge/etc
/opt/Hauppauge/etc/sample.conf
/opt/Hauppauge/firmware
/opt/Hauppauge/firmware/llama_usb_vx_host_slave_t22_24.bin
/opt/Hauppauge/firmware/mips_vx_host_slave.bin
/usr
/usr/share
/usr/share/doc
/usr/share/doc/hauppaugeusb
/usr/share/doc/hauppaugeusb/changelog.gz
/usr/share/doc/hauppaugeusb/copyright
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 26, 2020, 5:03 PM
Post #46 of 67 (1845 views)
Permalink
On Sun, Jul 26, 2020 at 3:34 PM John Hoyt <john.hoyt@gmail.com> wrote:

> On Sun, Jul 26, 2020 at 6:32 PM John Hoyt <john.hoyt@gmail.com> wrote:
>
>> After connecting to the repository and running the install, there is
>>> nothing in /opt
>>>
>>
>> That's strange. Did apt give you any errors? Also, what version of
>> ubuntu did you land on?
>>
>> What does the output of "dpkg-query -L hauppaugeusb" give you?
>>
>
> Here's what mine outputs:
>
> dpkg-query -L hauppaugeusb
> /.
> /opt
> /opt/Hauppauge
> /opt/Hauppauge/bin
> /opt/Hauppauge/bin/hauppauge2
> /opt/Hauppauge/etc
> /opt/Hauppauge/etc/sample.conf
> /opt/Hauppauge/firmware
> /opt/Hauppauge/firmware/llama_usb_vx_host_slave_t22_24.bin
> /opt/Hauppauge/firmware/mips_vx_host_slave.bin
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/hauppaugeusb
> /usr/share/doc/hauppaugeusb/changelog.gz
> /usr/share/doc/hauppaugeusb/copyright
>

It said not installed, so I installed the package again, and now /opt is
there. Maybe I accidentally skipped the install step. Sorry for the
noise!
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 28, 2020, 9:10 PM
Post #47 of 67 (1825 views)
Permalink
On Sun, Jul 26, 2020, 5:03 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Sun, Jul 26, 2020 at 3:34 PM John Hoyt <john.hoyt@gmail.com> wrote:
>
>> On Sun, Jul 26, 2020 at 6:32 PM John Hoyt <john.hoyt@gmail.com> wrote:
>>
>>> After connecting to the repository and running the install, there is
>>>> nothing in /opt
>>>>
>>>
>>> That's strange. Did apt give you any errors? Also, what version of
>>> ubuntu did you land on?
>>>
>>> What does the output of "dpkg-query -L hauppaugeusb" give you?
>>>
>>
>> Here's what mine outputs:
>>
>> dpkg-query -L hauppaugeusb
>> /.
>> /opt
>> /opt/Hauppauge
>> /opt/Hauppauge/bin
>> /opt/Hauppauge/bin/hauppauge2
>> /opt/Hauppauge/etc
>> /opt/Hauppauge/etc/sample.conf
>> /opt/Hauppauge/firmware
>> /opt/Hauppauge/firmware/llama_usb_vx_host_slave_t22_24.bin
>> /opt/Hauppauge/firmware/mips_vx_host_slave.bin
>> /usr
>> /usr/share
>> /usr/share/doc
>> /usr/share/doc/hauppaugeusb
>> /usr/share/doc/hauppaugeusb/changelog.gz
>> /usr/share/doc/hauppaugeusb/copyright
>>
>
> It said not installed, so I installed the package again, and now /opt is
> there. Maybe I accidentally skipped the install step. Sorry for the
> noise!
>

Just to report...I was sitting here watching a recorded program on Myth,
when I saw an unfamiliar flash over by the equipment. It was HDPVR2 firing
up to record something. Unfortunately I don't yet have a channel change
solution (my FireWire seems to have crapped out) but at least the recorder
looks to be in good working order. Thank you all so much for the input and
especially John P for writing then sharing his software.
Re: HDPVR intermittent failure [ In reply to ]
wdormann at gmail
Jul 29, 2020, 6:16 AM
Post #48 of 67 (1824 views)
Permalink
On 7/22/20 7:04 PM, John Hoyt wrote:
> I decided to try this with my current Myth setup, and it looks like
> you don't have a version for Ubuntu 16.04. 
>
>
> Correct - sorry about that.  Unfortunately launchpad blocks the upload
> for no longer supported versions of Ubuntu.  I used to have a Xenial
> build posted, but dropped it when I ran out of space in launchpad.


I think I'll add myself to the list of HD-PVR 1212 owners where the
device has slowly gotten less and less reliable over time. And my power
is coming from the computer's PSU, so it can't be the supplied wall wart
that's the problem.

The latest failure sequence was just yesterday:
1) Noticed recording that was choppy
2) Power cycled HD-PVR
3) Rather than being recognized by the computer, it showed up in dmesg as:
usb 1-6: new full-speed USB device number 10 using xhci_hcd
usb 1-6: Device not responding to setup address.
usb 1-6: Device not responding to setup address.
usb 1-6: device not accepting address 10, error -71

Where the device number would increment with each power cycle. This
happened once before perhaps a year ago and I did some number of actions
including opening the case, switching USB ports on the computer, and
switching USB cables, and eventually it worked.

This time around I ended up giving up on it, only to realize that just
after leaving it sit there for a while the device was picked up, and I
confirmed that it is functional to record.


Anyway, long story short, I want a contingency plan for when my device
fully kicks the bucket, and this HD-PVR 2 stuff has piqued my interest.
But I'm a little curious:

1) Ubuntu 16.04 reaches EOL on April 2021, which hasn't arrived yet. So
it seems odd that the upload to support 16.04 wouldn't be allowed for
that reason.
2) It looks like the project page https://github.com/jpoet/HauppaugeUSB
indicates that fixes/31 is required. Is this required to support
external recorders in general?


Based on track record, I've found that updating a system without a
specific worthwhile reason will usually end up in one of two scenarios:
1) After some indefinite amount of time/effort spent, the system may
work as well as it did before.
2) After some indefinite amount of time/effort spent, the system isn't
working as it did before.

As such, I'm a happy owner of a MythTV 29.1 on Ubuntu 16.04 system (ever
since 14.04 went EOL, lather, rinse, repeat...)

If I happen to go the HD-PVR2 route, or if April 2021 rolls around
before I know it, I'm curious if there are any guides to help avoid any
"gotchas" with updating to a newer version of Ubuntu. I seem to recall
seeing chatter here about lirc being problematic starting with Ubuntu
18.04? And I'm an old school lircd user with a homemade receiver wired
into a serial port. I'd hate to go down an upgrade path that results in
a no-longer-working remote control, for example.


Thanks for any tips/info!
-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 29, 2020, 11:27 AM
Post #49 of 67 (1820 views)
Permalink
On Wed, Jul 29, 2020 at 6:16 AM Will Dormann <wdormann@gmail.com> wrote:

> On 7/22/20 7:04 PM, John Hoyt wrote:
> > I decided to try this with my current Myth setup, and it looks like
> > you don't have a version for Ubuntu 16.04.
> >
> >
> > Correct - sorry about that. Unfortunately launchpad blocks the upload
> > for no longer supported versions of Ubuntu. I used to have a Xenial
> > build posted, but dropped it when I ran out of space in launchpad.
>
>
> I think I'll add myself to the list of HD-PVR 1212 owners where the
> device has slowly gotten less and less reliable over time. And my power
> is coming from the computer's PSU, so it can't be the supplied wall wart
> that's the problem.
>
> The latest failure sequence was just yesterday:
> 1) Noticed recording that was choppy
> 2) Power cycled HD-PVR
> 3) Rather than being recognized by the computer, it showed up in dmesg as:
> usb 1-6: new full-speed USB device number 10 using xhci_hcd
> usb 1-6: Device not responding to setup address.
> usb 1-6: Device not responding to setup address.
> usb 1-6: device not accepting address 10, error -71
>
> Where the device number would increment with each power cycle. This
> happened once before perhaps a year ago and I did some number of actions
> including opening the case, switching USB ports on the computer, and
> switching USB cables, and eventually it worked.
>
> This time around I ended up giving up on it, only to realize that just
> after leaving it sit there for a while the device was picked up, and I
> confirmed that it is functional to record.
>
>
> Anyway, long story short, I want a contingency plan for when my device
> fully kicks the bucket, and this HD-PVR 2 stuff has piqued my interest.
> But I'm a little curious:
>
> 1) Ubuntu 16.04 reaches EOL on April 2021, which hasn't arrived yet. So
> it seems odd that the upload to support 16.04 wouldn't be allowed for
> that reason.
> 2) It looks like the project page https://github.com/jpoet/HauppaugeUSB
> indicates that fixes/31 is required. Is this required to support
> external recorders in general?
>
>
> Based on track record, I've found that updating a system without a
> specific worthwhile reason will usually end up in one of two scenarios:
> 1) After some indefinite amount of time/effort spent, the system may
> work as well as it did before.
> 2) After some indefinite amount of time/effort spent, the system isn't
> working as it did before.
>
> As such, I'm a happy owner of a MythTV 29.1 on Ubuntu 16.04 system (ever
> since 14.04 went EOL, lather, rinse, repeat...)
>
> If I happen to go the HD-PVR2 route, or if April 2021 rolls around
> before I know it, I'm curious if there are any guides to help avoid any
> "gotchas" with updating to a newer version of Ubuntu. I seem to recall
> seeing chatter here about lirc being problematic starting with Ubuntu
> 18.04? And I'm an old school lircd user with a homemade receiver wired
> into a serial port. I'd hate to go down an upgrade path that results in
> a no-longer-working remote control, for example.
>
>
> Thanks for any tips/info!
> -WD
>

Can offer a couple things other than what is in this thread. There is a guy
on e-bay selling used used HDPVR2s for I think $80, but they are bare
bones--no power supply or cable for component video input. Had to buy a
6V-2A power supply from Amazon and the cable from Hauppauge. I was able to
get it installed and working on 18.04/Myth 31 using John H's compiled code
and John P's config instructions.

I wasn't sure exactly what John P was referring to re fixes/31. I did not
apply any fixes, just installed latest distro of 18.04. I actually started
with xubuntu 20.04 but had problems with screen-timeouts that I couldn't
resolve. Tried ubuntu 20.04 but it crashed right after install during the
update process. My mobo is like 10 years old so I suspect there may have
been some hardware incompatibilities. Went to 18.04 and it installed
smoothly.

...except there is this problem with the install hanging in some cases due
to a faulty os-prober. See here
<https://unix.stackexchange.com/questions/511289/ubuntu-18-04-server-installation-gets-stuck-at-66-while-runningupdate-grub/600231#600231>
for a workaround.

If you go up to myth 31 note that XMLTV is a *big change* for the listings
grabber, and there is a learning curve. Whereas before you just entered
your schedules direct id/pw in mythtv-setup, now the grabber is a whole
thing you have to install and configure. If you decide to upgrade check
thread "XMLTV setup can't run mythtv-setup as user mythtv" for helpful info
on getting it working.

Good luck!

Steve
Re: HDPVR intermittent failure [ In reply to ]
wdormann at gmail
Jul 29, 2020, 12:51 PM
Post #50 of 67 (1820 views)
Permalink
On 7/29/20 2:27 PM, DryHeat122 wrote:
> I wasn't sure exactly what John P was referring to re fixes/31.  I did
> not apply any fixes, just installed latest distro of 18.04. I actually
> started with xubuntu 20.04 but had problems with screen-timeouts that I
> couldn't resolve. Tried ubuntu 20.04 but it crashed right after install
> during the update process.  My mobo is like 10 years old so I suspect
> there may have been some hardware incompatibilities. Went to 18.04 and
> it installed smoothly.

Interesting. So if you're running the Ubuntu-provided MythTV, I'd say
that you're running 29.1+fixes, if I'm reading
https://packages.ubuntu.com/bionic/mythtv right?

I'm running 29.1+fixes myself on 16.04, as my Mythbuntu PPA:
https://launchpad.net/~mythbuntu/+archive/ubuntu/0.29/+sourcepub/10541501/+listing-archive-extra
as my current MythTV machine's origins can be traced to MythBuntu rather
than Ubuntu + the MythTV package.

If you are indeed on 29.1+fixes from Ubuntu and your HD PVR 2 works,
then I suspect it may be fair to say that the statement in the github
page of "If you want to use this with MythTV, you will want fixes/31 or
later." may be incorrect?

John P: Can you share your motivations for this requirement?


> If you go up to myth 31 note that XMLTV is a /big change/ for the
> listings grabber, and there is a learning curve.  Whereas before you
> just entered your schedules direct id/pw in mythtv-setup, now the
> grabber is a whole thing you have to install and configure.  If you
> decide to upgrade check thread "XMLTV setup can't run mythtv-setup as
> user mythtv" for helpful info on getting it working.


Good to know. So that gives me a thread of 16 messages to sift through.
There's also a thread of 20 messages with the subject of
"[mythtv-users] lircd unreliable after Ubuntu upgrade 16.04 > 18.04".
And maybe there are other troubles that somebody might encounter when
upgrading to Ubuntu 18.04 (or newer), which might require locating and
sifting through other email threads. There's also a thread of 9
messages with the subject line of "[mythtv-users] successful upgrades to
ubuntu 18.04 from 16.04?"

Which perhaps brings us to what I intended to be my original point:
Is there any guide (e.g. a wiki where people could contribute) that may
serve as a single source of the information that one might need before
attempting an upgrade of a MythTV system? Which might include things
that change on the OS level (e.g. lirc) or things that change on the
MythTV level (e.g. XMLTV)


Thanks!
-WD
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 29, 2020, 1:22 PM
Post #51 of 67 (1377 views)
Permalink
On Wed, Jul 29, 2020 at 1:53 PM Will Dormann <wdormann@gmail.com> wrote:

> On 7/29/20 2:27 PM, DryHeat122 wrote:
> > I wasn't sure exactly what John P was referring to re fixes/31. I did
> > not apply any fixes, just installed latest distro of 18.04. I actually
> > started with xubuntu 20.04 but had problems with screen-timeouts that I
> > couldn't resolve. Tried ubuntu 20.04 but it crashed right after install
> > during the update process. My mobo is like 10 years old so I suspect
> > there may have been some hardware incompatibilities. Went to 18.04 and
> > it installed smoothly.
>
> Interesting. So if you're running the Ubuntu-provided MythTV, I'd say
> that you're running 29.1+fixes, if I'm reading
> https://packages.ubuntu.com/bionic/mythtv right?
>
> I'm running 29.1+fixes myself on 16.04, as my Mythbuntu PPA:
>
> https://launchpad.net/~mythbuntu/+archive/ubuntu/0.29/+sourcepub/10541501/+listing-archive-extra
> as my current MythTV machine's origins can be traced to MythBuntu rather
> than Ubuntu + the MythTV package.
>
> If you are indeed on 29.1+fixes from Ubuntu and your HD PVR 2 works,
> then I suspect it may be fair to say that the statement in the github
> page of "If you want to use this with MythTV, you will want fixes/31 or
> later." may be incorrect?
>
> John P: Can you share your motivations for this requirement?
>

I just pushed a change to the README to be more clear. I hope that helps
avoid the confusion.

John
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 30, 2020, 3:40 AM
Post #52 of 67 (1375 views)
Permalink
>
> 1) Ubuntu 16.04 reaches EOL on April 2021, which hasn't arrived yet. So
> it seems odd that the upload to support 16.04 wouldn't be allowed for
> that reason.
>

I guess I misremembered why I wasn't supporting 16.04. It was either I
elected to support the latest Ubuntu LTS version available when John Poet
initially released the code (2018), I ran out of space on launchpad (I was
rolling my own mythbuntu variant at the time) or I was already using a more
modern version of ubuntu (most likely reason). Possibly even a combination
of all of the above :)

At any rate, I just tried pushing a 16.04 version to launchpad and it took
it. Unfortunately, it's unable to build due to the xxd dependency not
being available in Xenial. If I get bored, I may configure pbuilder
for xenial and try to hunt down a ppa to link into the build to resolve the
dependency. If anyone else has solved the dependency issues for Xenial or
has created a patch file to patch the code (again for xenial) let me know
as copying someone else's work will get me to a working solution faster.
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 30, 2020, 4:16 PM
Post #53 of 67 (1370 views)
Permalink
>
> At any rate, I just tried pushing a 16.04 version to launchpad and it took
> it. Unfortunately, it's unable to build due to the xxd dependency not
> being available in Xenial. If I get bored, I may configure pbuilder
> for xenial and try to hunt down a ppa to link into the build to resolve the
> dependency. If anyone else has solved the dependency issues for Xenial or
> has created a patch file to patch the code (again for xenial) let me know
> as copying someone else's work will get me to a working solution faster.
>

Well, I got through the dependency issues and even a debbuilder version
snag then got stymied by a compile error (the same one that kicked off
Steve's upgrade adventure). Unfortunately, this means you really need a
Xenial system to sort out how to get the drivers to compile and generate
the .dsc file necessary to automate the build with launchpad.

If anyone does sort out the required dependencies and gets this to build
(in Xenial), please post your build adventure to the mailing list (...and
if you choose to your .dsc file from debuild...). With that info I can
probably get a version posted to my ppa.
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 31, 2020, 3:47 PM
Post #54 of 67 (1368 views)
Permalink
>
> If anyone does sort out the required dependencies and gets this to build
> (in Xenial), please post your build adventure to the mailing list (...and
> if you choose to your .dsc file from debuild...). With that info I can
> probably get a version posted to my ppa.
>

So after staring at this for a few more minutes, I now have a version that
compiles with pbuilder and is also posted to my ppa (
https://launchpad.net/~john-hoyt/+archive/ubuntu/hauppaugeusb/+packages).

The big issues with compiling were

1. replacing the xxd package with vim-common as that's where Xenial
hides the xxd executable.
2. modifying the source in "Common/Rx/audio_CS8416.cpp" to add an
include statement to cstring and changing the call to memcpy to be
std::memcpy

Here's the diff for a patch file for "Common/Rx/audio_CS8416.cpp:

--- Common/Rx/audio_CS8416.cpp 2016-09-26 16:35:49.000000000 -0400
+++ Common/Rx/audio_CS8416.cpp 2020-07-31 18:11:02.281056836 -0400
@@ -17,6 +17,7 @@
#include <cstdint>
#include <map>
#include <stdexcept>
+#include <cstring>

#include "audio_CS8416.h"

@@ -170,7 +171,7 @@
else {
sendbuff = static_cast<uint8_t*>(malloc(len + 1));
*sendbuff = static_cast<uint8_t>(reg);
- memcpy(sendbuff + 1, data, len);
+ std::memcpy(sendbuff + 1, data, len);
}

result = m_fx2.I2CWrite(CS8416_DEVICE_ADDR, sendbuff, len + 1);


@John Poet - it may be worth appending some instructions to your
gitrepo Readme.md noting Ubuntu Xenial users will need to install
dependencies with

"sudo apt-get install libboost-log-dev libboost-program-options-dev
libusb-1.0-0-dev build-essential"


As well as apply the patch.

~John
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Jul 31, 2020, 4:07 PM
Post #55 of 67 (1368 views)
Permalink
>
> @John Poet - it may be worth appending some instructions to your
> gitrepo Readme.md noting Ubuntu Xenial users will need to install
> dependencies with
>
> "sudo apt-get install libboost-log-dev libboost-program-options-dev
> libusb-1.0-0-dev build-essential"
>
>
Sorry that should have read

"sudo apt-get install libboost-log-dev libboost-program-options-dev
libusb-1.0-0-dev build-essential vim-common"
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Jul 31, 2020, 5:40 PM
Post #56 of 67 (1363 views)
Permalink
On Tue, Jul 28, 2020 at 9:10 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
> [snip]
>
> Just to report...I was sitting here watching a recorded program on Myth,
> when I saw an unfamiliar flash over by the equipment. It was HDPVR2 firing
> up to record something. Unfortunately I don't yet have a channel change
> solution (my FireWire seems to have crapped out) but at least the recorder
> looks to be in good working order. Thank you all so much for the input and
> especially John P for writing then sharing his software.
>
>
Well guys, I spoke a little too soon. Today after solving my
firewire/channel-change problem, I decided to do a test recording via
myth. It failed. I went and tried to do a test recording via command line
and got:

$ /opt/Hauppauge/bin/hauppauge2 -s E524-00-00ABAE4A -i 1 -a 1 -o
/tmp/test.ts
2020-07-31T17:16:38.480742 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
Changing loglevel to NOTC
2020-07-31T17:16:38.480920 CRIT <main> hauppauge2.cpp:347 (main) Starting up
Failed to open dev.
2020-07-31T17:16:38.489129 CRIT <main> hauppauge2.cpp:355 (main) Device
E524-00-00ABAE4A not found on USB bus.

I rebooted and tried again. Same result. But lsusb finds it:

Bus 001 Device 002: ID 2040:e524 Hauppauge

Tried the steps under "troubleshooting" on JohnP's the git page. I
couldn't find the suggested log entry in syslog or mythbackend.log (not
sure what log it's referring to). So I used the bus 1 as given in lsusb.
Still won't do a test recording.

Before I tried the myth test recording I had gone into setup to make sure
the tuning timeout was 15 sec as suggested. I found this in
mythtv-setup.log

/var/log/mythtv/mythtv-setup.log:Jul 31 16:57:21 steve-EP45-UD3P
mythtv-setup.real: mythtv-setup[589]: E ScreenLoad v4l2util.cpp:42 (Open)
V4L2(): Could not open '/opt/Hauppauge/bin/hauppauge2 -c
/opt/Hauppauge/etc/hdpvr2-1.conf': #012#011#011#011eno: No such file or
directory (2)

But both files are there and seem to have the necessary permissions. The
right serial number is in hdpvr2-1.conf:

-rwxr-xr-x 1 root root 1707408 Jul 25 10:57 hauppauge2
-rwxr-xr-x 1 root root 1940 Jul 27 12:50 hdpvr2-1.conf


How to proceed?
Re: HDPVR intermittent failure [ In reply to ]
jppoet at gmail
Jul 31, 2020, 5:57 PM
Post #57 of 67 (1363 views)
Permalink
On Fri, Jul 31, 2020 at 6:43 PM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Tue, Jul 28, 2020 at 9:10 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>> [snip]
>>
>> Just to report...I was sitting here watching a recorded program on Myth,
>> when I saw an unfamiliar flash over by the equipment. It was HDPVR2 firing
>> up to record something. Unfortunately I don't yet have a channel change
>> solution (my FireWire seems to have crapped out) but at least the recorder
>> looks to be in good working order. Thank you all so much for the input and
>> especially John P for writing then sharing his software.
>>
>>
> Well guys, I spoke a little too soon. Today after solving my
> firewire/channel-change problem, I decided to do a test recording via
> myth. It failed. I went and tried to do a test recording via command line
> and got:
>
> $ /opt/Hauppauge/bin/hauppauge2 -s E524-00-00ABAE4A -i 1 -a 1 -o
> /tmp/test.ts
> 2020-07-31T17:16:38.480742 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
> Changing loglevel to NOTC
> 2020-07-31T17:16:38.480920 CRIT <main> hauppauge2.cpp:347 (main) Starting
> up
> Failed to open dev.
> 2020-07-31T17:16:38.489129 CRIT <main> hauppauge2.cpp:355 (main) Device
> E524-00-00ABAE4A not found on USB bus.
>
> I rebooted and tried again. Same result. But lsusb finds it:
>
> Bus 001 Device 002: ID 2040:e524 Hauppauge
>
> Tried the steps under "troubleshooting" on JohnP's the git page. I
> couldn't find the suggested log entry in syslog or mythbackend.log (not
> sure what log it's referring to). So I used the bus 1 as given in lsusb.
> Still won't do a test recording.
>
> Before I tried the myth test recording I had gone into setup to make sure
> the tuning timeout was 15 sec as suggested. I found this in
> mythtv-setup.log
>
> /var/log/mythtv/mythtv-setup.log:Jul 31 16:57:21 steve-EP45-UD3P
> mythtv-setup.real: mythtv-setup[589]: E ScreenLoad v4l2util.cpp:42 (Open)
> V4L2(): Could not open '/opt/Hauppauge/bin/hauppauge2 -c
> /opt/Hauppauge/etc/hdpvr2-1.conf': #012#011#011#011eno: No such file or
> directory (2)
>
> But both files are there and seem to have the necessary permissions. The
> right serial number is in hdpvr2-1.conf:
>
> -rwxr-xr-x 1 root root 1707408 Jul 25 10:57 hauppauge2
> -rwxr-xr-x 1 root root 1940 Jul 27 12:50 hdpvr2-1.conf
>
>
> How to proceed?
>

V4L2() is wrong. Somehow you have it setup with the wrong tuner "type".
That should say Extern, since you are using an External Recorder. Try
deleting that capture device and set it up again.

John
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Aug 1, 2020, 9:25 AM
Post #58 of 67 (1358 views)
Permalink
On Fri, Jul 31, 2020 at 5:58 PM John P Poet <jppoet@gmail.com> wrote:

>
>
> On Fri, Jul 31, 2020 at 6:43 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>>
>>
>> On Tue, Jul 28, 2020 at 9:10 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>> [snip]
>>>
>>> Just to report...I was sitting here watching a recorded program on Myth,
>>> when I saw an unfamiliar flash over by the equipment. It was HDPVR2 firing
>>> up to record something. Unfortunately I don't yet have a channel change
>>> solution (my FireWire seems to have crapped out) but at least the recorder
>>> looks to be in good working order. Thank you all so much for the input and
>>> especially John P for writing then sharing his software.
>>>
>>>
>> Well guys, I spoke a little too soon. Today after solving my
>> firewire/channel-change problem, I decided to do a test recording via
>> myth. It failed. I went and tried to do a test recording via command line
>> and got:
>>
>> $ /opt/Hauppauge/bin/hauppauge2 -s E524-00-00ABAE4A -i 1 -a 1 -o
>> /tmp/test.ts
>> 2020-07-31T17:16:38.480742 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
>> Changing loglevel to NOTC
>> 2020-07-31T17:16:38.480920 CRIT <main> hauppauge2.cpp:347 (main) Starting
>> up
>> Failed to open dev.
>> 2020-07-31T17:16:38.489129 CRIT <main> hauppauge2.cpp:355 (main) Device
>> E524-00-00ABAE4A not found on USB bus.
>>
>> I rebooted and tried again. Same result. But lsusb finds it:
>>
>> Bus 001 Device 002: ID 2040:e524 Hauppauge
>>
>> Tried the steps under "troubleshooting" on JohnP's the git page. I
>> couldn't find the suggested log entry in syslog or mythbackend.log (not
>> sure what log it's referring to). So I used the bus 1 as given in lsusb.
>> Still won't do a test recording.
>>
>> Before I tried the myth test recording I had gone into setup to make sure
>> the tuning timeout was 15 sec as suggested. I found this in
>> mythtv-setup.log
>>
>> /var/log/mythtv/mythtv-setup.log:Jul 31 16:57:21 steve-EP45-UD3P
>> mythtv-setup.real: mythtv-setup[589]: E ScreenLoad v4l2util.cpp:42 (Open)
>> V4L2(): Could not open '/opt/Hauppauge/bin/hauppauge2 -c
>> /opt/Hauppauge/etc/hdpvr2-1.conf': #012#011#011#011eno: No such file or
>> directory (2)
>>
>> But both files are there and seem to have the necessary permissions. The
>> right serial number is in hdpvr2-1.conf:
>>
>> -rwxr-xr-x 1 root root 1707408 Jul 25 10:57 hauppauge2
>> -rwxr-xr-x 1 root root 1940 Jul 27 12:50 hdpvr2-1.conf
>>
>>
>> How to proceed?
>>
>
> V4L2() is wrong. Somehow you have it setup with the wrong tuner "type".
> That should say Extern, since you are using an External Recorder. Try
> deleting that capture device and set it up again.
>
> John
>

I did set it up as an external recorder, but I will delete and try again.
Before that, though, I would like to be sure I can make a command line
test recording. Any idea why it's saying it can't open
/opt/Hauppauge/bin/hauppauge2 when it is there and is executable?
Re: HDPVR intermittent failure [ In reply to ]
mkbloke at gmail
Aug 1, 2020, 9:35 AM
Post #59 of 67 (1358 views)
Permalink
On Sat, 1 Aug 2020 at 17:26, DryHeat122 <dryheat122@gmail.com> wrote:

> Any idea why it's saying it can't open /opt/Hauppauge/bin/hauppauge2 when
> it is there and is executable?
>

Just a thought - have you checked the permissions along the whole path?

--
Cheers, Ian
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Aug 1, 2020, 10:07 AM
Post #60 of 67 (1358 views)
Permalink
On Wed, Jul 29, 2020, 12:52 PM Will Dormann <wdormann@gmail.com> wrote:

> [Snip]
>
> Which perhaps brings us to what I intended to be my original point:
> Is there any guide (e.g. a wiki where people could contribute) that may
> serve as a single source of the information that one might need before
> attempting an upgrade of a MythTV system? Which might include things
> that change on the OS level (e.g. lirc) or things that change on the
> MythTV level (e.g. XMLTV)
>

Not that I know of. You just have to slog through it.

>
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Aug 1, 2020, 10:41 AM
Post #61 of 67 (1343 views)
Permalink
On Sat, Aug 1, 2020 at 9:25 AM DryHeat122 <dryheat122@gmail.com> wrote:

>
>
> On Fri, Jul 31, 2020 at 5:58 PM John P Poet <jppoet@gmail.com> wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 6:43 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Jul 28, 2020 at 9:10 PM DryHeat122 <dryheat122@gmail.com> wrote:
>>>
>>>>
>>>> [snip]
>>>>
>>>> Just to report...I was sitting here watching a recorded program on
>>>> Myth, when I saw an unfamiliar flash over by the equipment. It was HDPVR2
>>>> firing up to record something. Unfortunately I don't yet have a channel
>>>> change solution (my FireWire seems to have crapped out) but at least the
>>>> recorder looks to be in good working order. Thank you all so much for the
>>>> input and especially John P for writing then sharing his software.
>>>>
>>>>
>>> Well guys, I spoke a little too soon. Today after solving my
>>> firewire/channel-change problem, I decided to do a test recording via
>>> myth. It failed. I went and tried to do a test recording via command line
>>> and got:
>>>
>>> $ /opt/Hauppauge/bin/hauppauge2 -s E524-00-00ABAE4A -i 1 -a 1 -o
>>> /tmp/test.ts
>>> 2020-07-31T17:16:38.480742 CRIT <main> Logger.cpp:83 (setLogLevelFilter)
>>> Changing loglevel to NOTC
>>> 2020-07-31T17:16:38.480920 CRIT <main> hauppauge2.cpp:347 (main)
>>> Starting up
>>> Failed to open dev.
>>> 2020-07-31T17:16:38.489129 CRIT <main> hauppauge2.cpp:355 (main) Device
>>> E524-00-00ABAE4A not found on USB bus.
>>>
>>> I rebooted and tried again. Same result. But lsusb finds it:
>>>
>>> Bus 001 Device 002: ID 2040:e524 Hauppauge
>>>
>>> Tried the steps under "troubleshooting" on JohnP's the git page. I
>>> couldn't find the suggested log entry in syslog or mythbackend.log (not
>>> sure what log it's referring to). So I used the bus 1 as given in lsusb.
>>> Still won't do a test recording.
>>>
>>> Before I tried the myth test recording I had gone into setup to make
>>> sure the tuning timeout was 15 sec as suggested. I found this in
>>> mythtv-setup.log
>>>
>>> /var/log/mythtv/mythtv-setup.log:Jul 31 16:57:21 steve-EP45-UD3P
>>> mythtv-setup.real: mythtv-setup[589]: E ScreenLoad v4l2util.cpp:42 (Open)
>>> V4L2(): Could not open '/opt/Hauppauge/bin/hauppauge2 -c
>>> /opt/Hauppauge/etc/hdpvr2-1.conf': #012#011#011#011eno: No such file or
>>> directory (2)
>>>
>>> But both files are there and seem to have the necessary permissions.
>>> The right serial number is in hdpvr2-1.conf:
>>>
>>> -rwxr-xr-x 1 root root 1707408 Jul 25 10:57 hauppauge2
>>> -rwxr-xr-x 1 root root 1940 Jul 27 12:50 hdpvr2-1.conf
>>>
>>>
>>> How to proceed?
>>>
>>
>> V4L2() is wrong. Somehow you have it setup with the wrong tuner "type".
>> That should say Extern, since you are using an External Recorder. Try
>> deleting that capture device and set it up again.
>>
>> John
>>
>
> I did set it up as an external recorder, but I will delete and try again.
> Before that, though, I would like to be sure I can make a command line
> test recording. Any idea why it's saying it can't open
> /opt/Hauppauge/bin/hauppauge2 when it is there and is executable?
>

It's because I was not running the command as sudo. I did so, and can now
get a test recording.

I went through the suggested procedure of deleting the hdpvr2 card and
recreating the capture card. I made sure to use the "external (black box)"
card, and the card description says "external." I am still getting the
same entry in mythtv-setup.log (i.e. with V4L2) ; however, now myth can
tune/record the hdpvr2. Hopefully it will stay that way.
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Aug 1, 2020, 10:47 AM
Post #62 of 67 (1343 views)
Permalink
>
> It's because I was not running the command as sudo. I did so, and can now
> get a test recording.
>
> I went through the suggested procedure of deleting the hdpvr2 card and
> recreating the capture card. I made sure to use the "external (black box)"
> card, and the card description says "external." I am still getting the
> same entry in mythtv-setup.log (i.e. with V4L2) ; however, now myth can
> tune/record the hdpvr2. Hopefully it will stay that way.
>
>
You shouldn't need to run with sudo. Have you created the custom udev rule
(per jpoet's instructions on his github page) and added the mythtv user to
the video user group?
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Aug 1, 2020, 12:09 PM
Post #63 of 67 (1343 views)
Permalink
On Sat, Aug 1, 2020 at 10:47 AM John Hoyt <john.hoyt@gmail.com> wrote:

>
>
>> It's because I was not running the command as sudo. I did so, and can
>> now get a test recording.
>>
>> I went through the suggested procedure of deleting the hdpvr2 card and
>> recreating the capture card. I made sure to use the "external (black box)"
>> card, and the card description says "external." I am still getting the
>> same entry in mythtv-setup.log (i.e. with V4L2) ; however, now myth can
>> tune/record the hdpvr2. Hopefully it will stay that way.
>>
>>
> You shouldn't need to run with sudo. Have you created the custom udev
> rule (per jpoet's instructions on his github page) and added the mythtv
> user to the video user group?
>

I did create /etc/udev/rules.d/99-Hauppauge.rules

/etc/udev/rules.d$ ls -la
total 72
drwxr-xr-x 2 root root 4096 Aug 1 09:21 .
drwxr-xr-x 4 root root 4096 Jul 26 10:49 ..
-rw-r--r-- 1 root root 58549 Jul 26 10:22 70-snap.core.rules
-rw-r--r-- 1 root root 208 Jul 26 14:28 99-Hauppauge.rules


Mythtv is a member of group video

video:x:44:mythtv


steve is not a member of video, though. Maybe that's why it wouldn't run
except as sudo?
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Aug 1, 2020, 12:30 PM
Post #64 of 67 (1343 views)
Permalink
>
> steve is not a member of video, though. Maybe that's why it wouldn't run
> except as sudo?
>
> Correct - you'll want to add steve to that group
Re: HDPVR intermittent failure [ In reply to ]
dryheat122 at gmail
Aug 6, 2020, 3:29 PM
Post #65 of 67 (1300 views)
Permalink
I finally have the HDPVR2 and mythchanger functioning reliably. I have one
question. apt list --upgradable returns in part:

hauppaugeusb/bionic 0.1.1~master.20200729.db7dfb2~ubuntu18.04 amd64
[upgradable from: 0.1.1~master.20200725.0e8ff23~ubuntu18.04]

In general I'm loath to upgrade anything on a working myth box, since doing
so risks upsetting the delicate balance and a multi-day trip down the
rabbit hole. Is this a critical update?
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Aug 6, 2020, 4:28 PM
Post #66 of 67 (1300 views)
Permalink
On Thu, Aug 6, 2020 at 6:30 PM DryHeat122 <dryheat122@gmail.com> wrote:

> I finally have the HDPVR2 and mythchanger functioning reliably. I have one
> question. apt list --upgradable returns in part:
>
> hauppaugeusb/bionic 0.1.1~master.20200729.db7dfb2~ubuntu18.04 amd64
> [upgradable from: 0.1.1~master.20200725.0e8ff23~ubuntu18.04]
>
> In general I'm loath to upgrade anything on a working myth box, since
> doing so risks upsetting the delicate balance and a multi-day trip down the
> rabbit hole. Is this a critical update?
>

They should be effectively the same thing (i.e. either way should work).
When I pushed the xenial package I forgot to comment out the other builds
and so they got resubmitted to launchpad / rebuilt
Re: HDPVR intermittent failure [ In reply to ]
john.hoyt at gmail
Aug 6, 2020, 4:30 PM
Post #67 of 67 (1300 views)
Permalink
On Thu, Aug 6, 2020 at 7:28 PM John Hoyt <john.hoyt@gmail.com> wrote:

> On Thu, Aug 6, 2020 at 6:30 PM DryHeat122 <dryheat122@gmail.com> wrote:
>
>> I finally have the HDPVR2 and mythchanger functioning reliably. I have
>> one question. apt list --upgradable returns in part:
>>
>> hauppaugeusb/bionic 0.1.1~master.20200729.db7dfb2~ubuntu18.04 amd64
>> [upgradable from: 0.1.1~master.20200725.0e8ff23~ubuntu18.04]
>>
>> In general I'm loath to upgrade anything on a working myth box, since
>> doing so risks upsetting the delicate balance and a multi-day trip down the
>> rabbit hole. Is this a critical update?
>>
>
> They should be effectively the same thing (i.e. either way should work).
> When I pushed the xenial package I forgot to comment out the other builds
> and so they got resubmitted to launchpad / rebuilt
>

BTW - if you're really that upgrade-phobic - you can delete the ppa from
/etc/apt/sources.list.d and it will not bug you about future updates.

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal