[mythtv-users] Schedules Direct DataDirect replacement service testing

[Bill Meek]

On 10/02/2014 03:19 AM, Kris Jensen wrote:
> On Wed, Oct 1, 2014 at 2:56 PM, Robert Eden <rmeden at yahoo.com> wrote:
>
>>   I'm ready for more testing of my replacement Data Direct service.  The
>> new JSON service is still the preferred solution.
>>
>> There are two ways to use the new service.   If you can modify your code,
>> replacing Tribune's hostname in the WSDL or Service request with
>> dd.schedulesdirect.org.
>>
>> If you can't modify your code, you (and your users) can add this to your
>> hosts file.
>>
>> 54.84.32.205 docs.tms.tribune.com webservices.schedulesdirect.tmsdatadirect.com
>>
>> That's it!  I hope the change is totally transparent to applications.
>> Please let me know, Nov 1 is getting closer!
>>
>> You can contact me via email or the SD forum:  DataDirect replacement
>> service - BETA 1
>> <http://forums.schedulesdirect.org/viewtopic.php?f=8&t=2591>
>> (known issues are in the forum post)
>>
>> Added the change to my hosts file.
> Did a mythfilldatabase. So far so good.
>
> way too easy.
>
> Thanks!

Same here, it just works. All my testing was with 0.28-pre and my systems are
setup to use --dd-grab-all at the run time suggested by the server.

I'd encourage anyone testing the new server to watch their mythfilldatabase.log
files (or wherever you put them.) I did all my tests with -v network,file
--loglevel debug.

I also used Wireshark to look at the protocol. Should anyone need it, the
following can be used to get the bits, then the file can be scp'ed to another
host and viewed: tshark -i eth0 -f "host 54.164.149.223" -w someFileName.pcap

I've made *no* attempt to change anything in my lineup at Schedules Direct.
According to http://forums.schedulesdirect.org/viewtopic.php?f=8&t=2591,
that code isn't written yet.

My observations:

One issue *could* be that the new server doesn't respond to pings. For some
reason, I seem to remember an old thread where someone mentioned using a
wrapper script that did a ping before calling mythfilldatabase. That would
fail. It could also be my imagination.

On my production box, the next suggested time retrieval always fails. This
is normally retrieved in a new TCP conversation following the schedule download.
It isn't a problem because the MythTV code uses the current time plus 1 day
when it fails. Specifically done here:

     mythfilldatabase/filldata.cpp updateLastRunStatus(QString &status)

On my test box, it never fails. If that rings a bell with anyone, please
let me know. Side note, Robert Eden tells me that at this time, the new
server also simply adds 1 day to the current time to create the next
suggested time (no complex, finely honed load balancing algorithm ;) .)

-- 
Bill