[mythtv-users] REGRESSION: mythbackend 0.25 does not recover firewire connection without restart anymore

[Peter Bennett]

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 at 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