Mailing List Archive

Keep losing p2p firewire connection on dch3200
I had my DCH-3200 box connected to my mythtv and mostly working in broadcast
mode, but it would occasionally crap out.

I read that peer to peer mode is more reliable so I tried to switch to that
and got it working, but I seem to be losing the peer to peer connection
every time the cable box is reset.

So, to save power my setup is that my backend/frontend and the cable box get
powered off when not in use.
When mythbackend wakes back up (via RTC or because I want to watch its
recordings), it also turns the cable box back on.

With broadcast, that kind of just all worked.

With P2P, it seems like the poweroff/poweron causes the p2p connection to be
lost, and mythbackend doesn't seem to re-enable it.

So, I can reprime the firewire connection, which typically gets p2p working
again:

My initscript looks like this:

/usr/local/bin/firewire_tester -p -n 0 -r 5 || true
# http://www.mythtv.org/wiki/FireWire
plugctl -n 0 "oPCR[0].n_p2p_connections=1" || true
plugctl -n 1 "oPCR[0].n_p2p_connections=1" || true
sleep 3
test -f /etc/default/locale && . /etc/default/locale
LANG=$LANG /usr/bin/mythbackend --syslog local7 --loglevel debug --user mythtv

When I come back from sleep, though, I'm unclear as to what needs to get
fixed and in which order.

1) do I indeed need to reprime?
2) looks like I need to reset the p2p bit to on
3) then it seems like mythbackend has lost the connection to firewire and
needs to be retarted, but usually if I restart it too quickly, firewire
isn't stable yet, and sometimes it misses the firewire recording backend.

I can try adding more sleeps and kludges, but the delay becomes annoying.

Is there a way to make this all work, or should I go back to broadcast?

Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On 4/29/2012 2:45 AM, Marc MERLIN wrote:
> I had my DCH-3200 box connected to my mythtv and mostly working in broadcast
> mode, but it would occasionally crap out.
>
> I read that peer to peer mode is more reliable so I tried to switch to that
> and got it working, but I seem to be losing the peer to peer connection
> every time the cable box is reset.
>
> So, to save power my setup is that my backend/frontend and the cable box get
> powered off when not in use.
> When mythbackend wakes back up (via RTC or because I want to watch its
> recordings), it also turns the cable box back on.
>
> With broadcast, that kind of just all worked.
>
> With P2P, it seems like the poweroff/poweron causes the p2p connection to be
> lost, and mythbackend doesn't seem to re-enable it.
>
> So, I can reprime the firewire connection, which typically gets p2p working
> again:
>
> My initscript looks like this:
>
> /usr/local/bin/firewire_tester -p -n 0 -r 5 || true
> # http://www.mythtv.org/wiki/FireWire
> plugctl -n 0 "oPCR[0].n_p2p_connections=1" || true
> plugctl -n 1 "oPCR[0].n_p2p_connections=1" || true
> sleep 3
> test -f /etc/default/locale && . /etc/default/locale
> LANG=$LANG /usr/bin/mythbackend --syslog local7 --loglevel debug --user mythtv
>
> When I come back from sleep, though, I'm unclear as to what needs to get
> fixed and in which order.
>
> 1) do I indeed need to reprime?
> 2) looks like I need to reset the p2p bit to on
> 3) then it seems like mythbackend has lost the connection to firewire and
> needs to be retarted, but usually if I restart it too quickly, firewire
> isn't stable yet, and sometimes it misses the firewire recording backend.
>
> I can try adding more sleeps and kludges, but the delay becomes annoying.
>
> Is there a way to make this all work, or should I go back to broadcast?
>
> Thanks,
> Marc
When you say "powered off" do you mean actual wall power removed from
the cable box? With the soft power off by using a remote to power off
the box my firewire connection remains and nothing gets lost. On the
other hand powering off the box at the wall causes the Comcast cable
system loses all its channels and takes several minutes to get them back
after powering on, and several days to get the program guide back.

I have a script that turns off the box via IR blaster. I have no issues
with that. The box still has power, but hopefully uses less than when it
is full on.

My experience has shown that any type of reset of the cable box,
including any disconnection of the firewire cable or power off at the
wall, needs to be followed by a restart of the back end. I have also
noticed that if the cable box gets unplugged even briefly, and replugged
it may receive a different port. The backend does not recover from this
and needs to be restarted. Also the n_p2p_connections gets reset if you
disconnect or power off the cable box at the wall.

I have always used p2p with great success, except for the "No input in
xxx msec", for which I have a patch, and with the patch my setup is
completely reliable. On my cable box, broadcast does not work at all.

If your problem is the No input in xxx msec messages, thousands of them
in the log, and recording that fails, then I have a solution that works.
Let me know.

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On Tue, May 01, 2012 at 02:21:40PM -0400, Peter Bennett wrote:
> When you say "powered off" do you mean actual wall power removed from
> the cable box? With the soft power off by using a remote to power off

Yes, I mean using an insteon appliance module the takes the power away.

> the box my firewire connection remains and nothing gets lost. On the
> other hand powering off the box at the wall causes the Comcast cable
> system loses all its channels and takes several minutes to get them back
> after powering on, and several days to get the program guide back.

1) I don't use its program guide, so I don't care :)
2) it takes 50 seconds to be able to tune its channels after being powered
back on.
3) with whatever bundle/channels I have, I have never lost the ability to
tune channels even though the box is likely off 21H/day on average.

> I have a script that turns off the box via IR blaster. I have no issues
> with that. The box still has power, but hopefully uses less than when it
> is full on.

I measured it, it saves 1W at best. In other words, it turns off the display
and continues to suck as much power as it used to. It's a sad joke.

> My experience has shown that any type of reset of the cable box,
> including any disconnection of the firewire cable or power off at the
> wall, needs to be followed by a restart of the back end. I have also
> noticed that if the cable box gets unplugged even briefly, and replugged
> it may receive a different port. The backend does not recover from this
> and needs to be restarted. Also the n_p2p_connections gets reset if you
> disconnect or power off the cable box at the wall.

Right, I noticed that.
So I think it worked a lot better for me when I was using broadcast mode: I
did not have to reprime firewire or restart the backend, it kind of just
worked.

> I have always used p2p with great success, except for the "No input in
> xxx msec", for which I have a patch, and with the patch my setup is
> completely reliable. On my cable box, broadcast does not work at all.

Interesting. For me broadcast worked for years, it was just 98% reliable so
I thought I'd use P@P.
Yes, I have the occasional 'No input in xxx msec' problem too.
If it's still in mythtv 0.25 (I just upgraded), I'd love the patch.

Anyway it sounds like I should go back to broadcast mode, P2P and power
resets don't seem to mix :)

If you're interested, I have somewhat elaborate scripts that check the FW
connection and reset it, and also make sure that my FW input exists on
mythbackend or restarts it if not.

Those can all be run from cron:
http://marc.merlins.org/linux/scripts/myth_check_empty_recordings
http://marc.merlins.org/linux/scripts/myth_check_encoder4
http://marc.merlins.org/linux/scripts/myth_check_restart_backend
http://marc.merlins.org/linux/scripts/myth_check_restart_firewire

and my somewhat complicated ACPI S3 shutdown/restart script:
http://marc.merlins.org/linux/scripts/myth_suspend

Cheers,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On Tue, May 1, 2012 at 3:20 PM, Marc MERLIN <marc_mtv@merlins.org> wrote:
> On Tue, May 01, 2012 at 02:21:40PM -0400, Peter Bennett wrote:
>> My experience has shown that any type of reset of the cable box,
>> including any disconnection of the firewire cable or power off at the
>> wall, needs to be followed by a restart of the back end. I have also
>> noticed that if the cable box gets unplugged even briefly, and replugged
>> it may receive a different port. The backend does not recover from this
>> and needs to be restarted. Also the n_p2p_connections gets reset if you
>> disconnect or power off the cable box at the wall.
>
> Right, I noticed that.
> So I think it worked a lot better for me when I was using broadcast mode: I
> did not have to reprime firewire or restart the backend, it kind of just
> worked.

I had a DCH-3200 from Comcast and had all sorts of trouble with it
over firewire. I was never able to get it to work reliably. I went
to Verizon FiOS for a few months, then switched back to Comcast and
got another DCH-3200. This one has worked flawlessly, with the same
MythTV backend hardware. I have no idea what the difference is.

> Anyway it sounds like I should go back to broadcast mode, P2P and power
> resets don't seem to mix :)

For Comcast, I can't recommend the HD HomeRun Prime highly enough. I
now only rely on the firewire connection when I have at least three
other recordings going.

Eric
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On Tue, May 1, 2012 at 7:31 PM, Eric Sharkey <eric@lisaneric.org> wrote:
....
> I had a DCH-3200 from Comcast and had all sorts of trouble with it
> over firewire.  I was never able to get it to work reliably.  I went
> to Verizon FiOS for a few months, then switched back to Comcast and
> got another DCH-3200.  This one has worked flawlessly, with the same
> MythTV backend hardware.  I have no idea what the difference is.

As obvious from all the updates for the firewire vendor id, there
have been many revisions of the box. Apparently some work
better than others. Of course it is also possible that between
the first and the second box Comcast rolled out another firmware
upgrade.

If the revision id's that matter (perhaps on the diagnostic pages?)
are obtainable, it *might* be valuable to document (on the wiki?)
those revisions that work better or worse so that when someone
goes into the Comcast office they can try to "negotiate" with the
CSR to get one that works better with MythTV. Perhaps a new
page of "Motorola STB quirks"?

> For Comcast, I can't recommend the HD HomeRun Prime highly enough.  I
> now only rely on the firewire connection when I have at least three
> other recordings going.

I agree that OCUR devices are just easier to deal with, and
are far less likely to encounter problems with the next
Comcast STB firmware upgrade(*).

Gary

(*) I do not know what happened to it, but I recall that
Comcast was going to roll out a new and improved(**)
gui for their STBs across the country. It may have been
bundled into their channel remap plans, or maybe it got
lost in the Xfinity branding, or maybe it happened and I
never noticed.

(**) It cannot be BOTH new, and improved (pick at most one).
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On 5/1/2012 5:36 PM, Gary Buhrmaster wrote:
>> For Comcast, I can't recommend the HD HomeRun Prime highly enough. I
>> now only rely on the firewire connection when I have at least three
>> other recordings going.
> I agree that OCUR devices are just easier to deal with, and
> are far less likely to encounter problems with the next
> Comcast STB firmware upgrade(*).
>
> Gary
>
> (*) I do not know what happened to it, but I recall that
> Comcast was going to roll out a new and improved(**)
> gui for their STBs across the country. It may have been
> bundled into their channel remap plans, or maybe it got
> lost in the Xfinity branding, or maybe it happened and I
> never noticed.
>
> (**) It cannot be BOTH new, and improved (pick at most one).
> _______________________________________________
>
I got the Comcast new GUI around April 2011. This is the event that
actually precipitated returning the comcast DVR and setting up MythTV
with a set top box and DVB tuners. the new DVR GUI was worse than the
old. Unfortunately the update also stopped firewire channel changing
from working, so I had to get an IR blaster.

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: Keep losing p2p firewire connection on dch3200 [ In reply to ]
On 5/1/2012 3:20 PM, Marc MERLIN wrote:
>
>
> Interesting. For me broadcast worked for years, it was just 98% reliable so
> I thought I'd use P@P.
> Yes, I have the occasional 'No input in xxx msec' problem too.
> If it's still in mythtv 0.25 (I just upgraded), I'd love the patch.
The bug is still there in 0.25. I am reworking the patch for 0.25. I
should have it soon. The patch was working on 0.24 for some months but
there were so many code changes in 0.25 that I have to rework some of
it. hopefully it will

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore [ In reply to ]
On Tue, May 01, 2012 at 12:20:46PM -0700, Marc MERLIN wrote:
> > it may receive a different port. The backend does not recover from this
> > and needs to be restarted. Also the n_p2p_connections gets reset if you
> > disconnect or power off the cable box at the wall.
>
> Right, I noticed that.
> So I think it worked a lot better for me when I was using broadcast mode: I
> did not have to reprime firewire or restart the backend, it kind of just
> worked.
>
> > I have always used p2p with great success, except for the "No input in
> > xxx msec", for which I have a patch, and with the patch my setup is
> > completely reliable. On my cable box, broadcast does not work at all.
>
> Interesting. For me broadcast worked for years, it was just 98% reliable so
> I thought I'd use P2P.
> Yes, I have the occasional 'No input in xxx msec' problem too.
> If it's still in mythtv 0.25 (I just upgraded), I'd love the patch.

Ok, I need to amend my finding and I updated the subject line.

Any idea what changed in the firewire code and if there is a way to reset it
without restarting mythbackend? (fixing 'Power cmd failed (no response)')

So, I can promise you that I had ACPI S3 sleep working and I used to hard
power off my DCH-3200 when my mythtv was sleeping.
When I came back from sleep, everything came back with mythtv 0.24.
I did NOT have to restart mythtv-backend.

Now, I tried not powering off my STB and I noticed that even like that I
still need to restart mythbackend for it to be able to tune channels over
firewire. Before the restart, mythbackend knows that it has a firewire
input, and it shows it as connected, but any attempt to tune channels gives:

May 1 22:36:49 myth mythbackend[9058]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: gandalfthegreat as a client (events: 0)
May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(4): Changing from None to WatchingLiveTV
May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(4): HW Tuner: 4->4
May 1 22:36:49 myth mythbackend[9058]: E TVRecEvent firewiredevice.cpp:121 (GetPowerState) FireDev(001E46FFFE6C0D04): Power cmd failed (no response)
May 1 22:36:49 myth mythbackend[9058]: E TVRecEvent tv_rec.cpp:3645 (TuningFrequency) TVRec(4): Failed to set channel to 750. Reverting to kState_None
May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(4): Changing from WatchingLiveTV to None


2012-05-01 22:36:48.697741 N TV: Spawning LiveTV Recorder -- begin
2012-05-01 22:36:48.725282 N TV: Spawning LiveTV Recorder -- end
2012-05-01 22:36:48.735319 E GetEntryAt(-1) failed.
2012-05-01 22:36:48.735345 E It appears that your backend may be misconfigured. Check your backend logs to determine whether your capture cards, lineups, channels, or storage configuration are reporting errors. This issue is commonly caused by failing to complete all setup steps properly. You may wish to review the documentation for mythtv-setup.
2012-05-01 22:36:48.735441 E EntryToProgram(0@Wed Dec 31 16:00:00 1969) failed to get pginfo
2012-05-01 22:36:48.735462 E TV: HandleStateChange(): LiveTV not successfully started

Restarting the backend fixes this.

Now, I'm forced to leave my STB on because it takes 50 seconds to boot, and
I can't wait 50 seconds for my mythtv to come back from sleep, power on the
STB, then wait 50 seconds, then retart mythbackend, wait another 5 to 10
seconds and only then start mythfrontend.

I swear I didn't have to do with with mythtv 0.24, it just kind of recovered
at runtime. I'm sure it was unable to tune channels on FW for the first 60
seconds, but it did not need to since it woke up from sleep 2mn before the
next recording, or because it was woken up to play saved recordings.

Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore [ In reply to ]
On 5/2/2012 2:10 AM, Marc MERLIN wrote:
> On Tue, May 01, 2012 at 12:20:46PM -0700, Marc MERLIN wrote:
>>> it may receive a different port. The backend does not recover from this
>>> and needs to be restarted. Also the n_p2p_connections gets reset if you
>>> disconnect or power off the cable box at the wall.
>> Right, I noticed that.
>> So I think it worked a lot better for me when I was using broadcast mode: I
>> did not have to reprime firewire or restart the backend, it kind of just
>> worked.
>>
>>> I have always used p2p with great success, except for the "No input in
>>> xxx msec", for which I have a patch, and with the patch my setup is
>>> completely reliable. On my cable box, broadcast does not work at all.
>>
>> Interesting. For me broadcast worked for years, it was just 98% reliable so
>> I thought I'd use P2P.
>> Yes, I have the occasional 'No input in xxx msec' problem too.
>> If it's still in mythtv 0.25 (I just upgraded), I'd love the patch.
> Ok, I need to amend my finding and I updated the subject line.
>
> Any idea what changed in the firewire code and if there is a way to reset it
> without restarting mythbackend? (fixing 'Power cmd failed (no response)')
>
> So, I can promise you that I had ACPI S3 sleep working and I used to hard
> power off my DCH-3200 when my mythtv was sleeping.
> When I came back from sleep, everything came back with mythtv 0.24.
> I did NOT have to restart mythtv-backend.
>
> Now, I tried not powering off my STB and I noticed that even like that I
> still need to restart mythbackend for it to be able to tune channels over
> firewire. Before the restart, mythbackend knows that it has a firewire
> input, and it shows it as connected, but any attempt to tune channels gives:
>
> May 1 22:36:49 myth mythbackend[9058]: I ProcessRequest mainserver.cpp:1362 (HandleAnnounce) adding: gandalfthegreat as a client (events: 0)
> May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(4): Changing from None to WatchingLiveTV
> May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:3459 (TuningCheckForHWChange) TVRec(4): HW Tuner: 4->4
> May 1 22:36:49 myth mythbackend[9058]: E TVRecEvent firewiredevice.cpp:121 (GetPowerState) FireDev(001E46FFFE6C0D04): Power cmd failed (no response)
> May 1 22:36:49 myth mythbackend[9058]: E TVRecEvent tv_rec.cpp:3645 (TuningFrequency) TVRec(4): Failed to set channel to 750. Reverting to kState_None
> May 1 22:36:49 myth mythbackend[9058]: I TVRecEvent tv_rec.cpp:1014 (HandleStateChange) TVRec(4): Changing from WatchingLiveTV to None
>
>
> 2012-05-01 22:36:48.697741 N TV: Spawning LiveTV Recorder -- begin
> 2012-05-01 22:36:48.725282 N TV: Spawning LiveTV Recorder -- end
> 2012-05-01 22:36:48.735319 E GetEntryAt(-1) failed.
> 2012-05-01 22:36:48.735345 E It appears that your backend may be misconfigured. Check your backend logs to determine whether your capture cards, lineups, channels, or storage configuration are reporting errors. This issue is commonly caused by failing to complete all setup steps properly. You may wish to review the documentation for mythtv-setup.
> 2012-05-01 22:36:48.735441 E EntryToProgram(0@Wed Dec 31 16:00:00 1969) failed to get pginfo
> 2012-05-01 22:36:48.735462 E TV: HandleStateChange(): LiveTV not successfully started
>
> Restarting the backend fixes this.
>
> Now, I'm forced to leave my STB on because it takes 50 seconds to boot, and
> I can't wait 50 seconds for my mythtv to come back from sleep, power on the
> STB, then wait 50 seconds, then retart mythbackend, wait another 5 to 10
> seconds and only then start mythfrontend.
>
> I swear I didn't have to do with with mythtv 0.24, it just kind of recovered
> at runtime. I'm sure it was unable to tune channels on FW for the first 60
> seconds, but it did not need to since it woke up from sleep 2mn before the
> next recording, or because it was woken up to play saved recordings.
>
> Thanks,
> Marc
I suggest try running plugreport from the command line before and after
the power-off, to see if maybe the port is changing, or some other
parameter is getting reset. If the port is changed or the n_p2p is reset
this may be preventing the backend from connecting.

Another suggestion - set the wakeup for 5 minutes early, then have a
script that checks plugreport for a good connectionto the firewire, then
restarts the backend. I am not sure how you will kick off this script at
wake-up time, there probably are several ways to do this.

My experience is that I cannot use sleep. I think that my USB QAM tuners
prevent sleep. If I try to suspend, the machine hangs. So I shut down
the server and use ACPI wakeup to reboot with a 5 minutes early setting.
This works well, it may be preferable to using a suspend.

I have a bunch of scripts for checking the status of firewire and other
things, and sending emails and text messages if something is
disconnected of failing. I can share them if they may be useful.

Peter
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore [ In reply to ]
> I suggest try running plugreport from the command line before and
> after
> the power-off, to see if maybe the port is changing, or some other
> parameter is getting reset. If the port is changed or the n_p2p is
> reset
> this may be preventing the backend from connecting.
>
> Another suggestion - set the wakeup for 5 minutes early, then have a
> script that checks plugreport for a good connectionto the firewire,
> then
> restarts the backend. I am not sure how you will kick off this script
> at
> wake-up time, there probably are several ways to do this.
>
> My experience is that I cannot use sleep. I think that my USB QAM
> tuners
> prevent sleep. If I try to suspend, the machine hangs. So I shut down
> the server and use ACPI wakeup to reboot with a 5 minutes early
> setting.
> This works well, it may be preferable to using a suspend.
>
> I have a bunch of scripts for checking the status of firewire and
> other
> things, and sending emails and text messages if something is
> disconnected of failing. I can share them if they may be useful.
>
> Peter

Yes, please share.

Gerald
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore [ In reply to ]
On Thu, May 03, 2012 at 11:10:59AM -0400, Peter Bennett wrote:
> I suggest try running plugreport from the command line before and after
> the power-off, to see if maybe the port is changing, or some other
> parameter is getting reset. If the port is changed or the n_p2p is reset
> this may be preventing the backend from connecting.

I forgot to mentoin that I went back to broadcast first, since broadcast was
working fine with S3 sleep with myth 0.24, and it does not work anymore
without me restarting mythbackend

Before sleep:
Node 0 GUID 0x001e8c0001700d3a
------------------------------

Node 1 GUID 0x001e46fffe6c0d04
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
channel=63, data_rate=1, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2

After sleep:
Node 0 GUID 0x001e8c0001700d3a
------------------------------

Node 1 GUID 0x001e46fffe6c0d04
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
channel=63, data_rate=1, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2

> Another suggestion - set the wakeup for 5 minutes early, then have a
> script that checks plugreport for a good connectionto the firewire, then
> restarts the backend. I am not sure how you will kick off this script at
> wake-up time, there probably are several ways to do this.

That's great for a backend, but not for my backend/frontend.

> I have a bunch of scripts for checking the status of firewire and other
> things, and sending emails and text messages if something is
> disconnected of failing. I can share them if they may be useful.

I see you wrote your own too :)
Sure, maybe you have something I don't have (please look at the scripts I sent
you in the URLs of my last Email).

Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users
Re: REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore [ In reply to ]
On 5/3/2012 11:14 AM, Gerald Brandt wrote:
>> I suggest try running plugreport from the command line before and
>> after
>> the power-off, to see if maybe the port is changing, or some other
>> parameter is getting reset. If the port is changed or the n_p2p is
>> reset
>> this may be preventing the backend from connecting.
>>
>> Another suggestion - set the wakeup for 5 minutes early, then have a
>> script that checks plugreport for a good connectionto the firewire,
>> then
>> restarts the backend. I am not sure how you will kick off this script
>> at
>> wake-up time, there probably are several ways to do this.
>>
>> My experience is that I cannot use sleep. I think that my USB QAM
>> tuners
>> prevent sleep. If I try to suspend, the machine hangs. So I shut down
>> the server and use ACPI wakeup to reboot with a 5 minutes early
>> setting.
>> This works well, it may be preferable to using a suspend.
>>
>> I have a bunch of scripts for checking the status of firewire and
>> other
>> things, and sending emails and text messages if something is
>> disconnected of failing. I can share them if they may be useful.
>>
>> Peter
> Yes, please share.
>
> Gerald
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

My scripts are here - this is a work in progress - I am reworking them
for 0.25 so they may not work perfectly at this time. I have an earlier
version running successfully on 0.24. There is also some testing stuff,
patches, executables, etc. Look in install/opt/mythtv for the scripts.
Parameters for the scripts are in install/etc/opt/mythtv.

https://www.dropbox.com/sh/2pxr0wo8lax4720/_S-zDs9Qsm


Peter

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://www.mythtv.org/mailman/listinfo/mythtv-users