[mythtv-users] mythfilldatabase not updating since last week's boot

[Barry Martin]

Hi Bill!

Thanks for the replies and being patient with my questions. Trying to 
figure out what I'm looking at where peering into these 'Black Boxes'.  
(The figurative concept ones, not the computer case ones! ...Though...!)

>> Yup! Me again!? Trying to figure out SchedulesDirect is being blocked. Noticed in /etc/hosts on the Backend I have "192.168.0.13 MythBE1", which
>> is the correct IP and name but for whatever reason in? this machine (the one I'm typing on and has no connection with the MythTV systems) it's
>> "127.0.1.1?????? Lenovo-M58".
>>
>> Probably nothing, especially as Firefox and Chromium work fine on that Backend.? Just looking for possibilities.
> Go to their forum. Here's an example:
>
>       http://forums.schedulesdirect.org/viewtopic.php?f=5&t=2938
>
> Note Robert's comment about resetting anyone's login after it's
> blocked. [and how often it takes to get blocking put on]

Will do - just trying to get enough stuff together so I can post a 
semi-intelligent question -- you guys are half-way used to me here!

> Make sure you don't have some bizarre cron entry doing things too often.

No user-initiated crons on Backends.  (Hey! I know what a 'cron' is!! :) )


> Did I understand in a earlier post here that you can run mythfilldatabase
> OK from one host, but not in another? If so, are they using the same WAN
> IP? The Private Network IPs 192.168 etc. don't matter.

Yes, though last night I noticed BE2 didn't appear to have 
(mythfilldatatabase) updated from the previous night - indicated 12 
days, which isn't normally a problem as only 13 days and that depends on 
the timing of the update.  More slight paranoia as BE1's isn't working 
at all.

As for the WAN, the short answer is yes:

DSL == my gateway (192.168.0.1) == gigabit hub == gigabit hub == both 
Backends and a RPI WiFi



>>> Figured?out?how?to?get?a?text?file?from?WireShark?-?and?just?posted?one?just?now?with?my?attempt?to?contact?SchedulesDirect.??It's?at
>>> https://pastebin.com/vZjyZ9Fq???Hope?it?make?sense.
>>> It?does.
>>>
>>> Look?at?frames?138?&?139,?the?very?start?of?the?connection.?The?backend?is?sending?a?SYN
>>> to?port?80,?as?it?should:
>>>
>>> ??????138?37.412640180???192.168.0.13??????????54.85.117.227?????????TCP??????74?????44732???80?[SYN]?Seq=0?Win=29200?Len=0?...
>>> ??????139?37.465501093???54.85.117.227?????????192.168.0.13??????????ICMP?????102????Destination?unreachable?(Port?unreachable)
>>>
>>> Schedules?Direct?returns?Destination?unreachable.?That?matches?up?with
>>> the?earlier?post?with?the?error?in?the?mfdb?log.?You?should?be?getting
>>> a?SYN,?ACK?back.
>> OK, here comes a stupid question, Bill -- more of a verification of my guess: the problem appears to be SchedulesDirect (54.85.117.227) can't
>> get/isn't giving an ACK (acknowledgement) to? my Backend (MythBE1, 192.168.0.13), right?? I'm also guessing I'm (MythBE1) or this end probably
>> isn't the problem??? Reading David's reply, quoted below, SchedulesDirect?is?being?the?problem.
> You've got it. We're talking about the "Three Way Handshake". A SYN is sent, a SYN/ACK is returned (normally) and then the the client returns an ACK.  I understand that Wireshark has a 'bit' of a learning curve. In the GUI, look at the headings and you'll see the Source and Destination columns. That should nail it for you.
>
> https://en.wikipedia.org/wiki/Handshaking#TCP_three-way_handshake

OK -- I'll look at that later -- the birthday party we're hosting is 
coming up shortly.

So the "good news" is the problem is on the SchedulesDirect side. 
Appears the timing of the reboot or some minor change here occurred at 
the same time, which caused me to think the issue was on my side.

Will go to the  SchedulesDirect forum and 'bug' them a bit!  (And 
remember to update this forum!)

Thanks again!
Barry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171125/34de72d1/attachment.html>