Here are my latest tests. Not really what I was hoping for.
As already stated, the new plugin from TV-Browser didn't work.
So I went back to the old plugin, and also changed my "hosts" file, as instructed elsewhere in this forum:
My listings "download" now lasted only 35 seconds of loading and going straight to "Your listings are ready", but they were not. It didn't work. I can corroborate that it connected to the new IP-- 188.8.131.52. But the program failed to finish the complete update. Something is not translating from SD to TV-Browser.
So I tried to test my old setup. I kept the old working plugin, but changed the "hosts" files back to its original state. When I tried to download the listings, it failed again. What I discovered is that my new test went straight to the new IP address, 184.108.40.206. So I must have been one of those 50% that are automatically routed by TMS directly to the new address. I think this can shed some light that something seems to be wrong with the way the new data is acquired (or not) by TV-Browser.
Hoping on the randomness of TMS, I tried again, same setup as the last test, nothing changed. This time, my request went straight to "web services.schedulesdirect.tmsdatadirect...." which I believe is the old server and service. And it worked!! The download and processing took 2.5 minutes for a week's worth of data for a lot of channels. I could follow TV-Browser while it "Loaded" the info, "Read" the info, Calculated the entries and the showed me the "Your listings ready" window. After clicking OK, there was my schedule for next week.
So, in summary, there is something wrong with how the new data is acquired/analyzed or processed with SD and TV-Browser. Hope this info can help.
The TV-Browser jar is open to anyone who wants to investigate this further. But it is a bit out of my domain right now.
This tests were done with both TV-Browser versions 3.4 and 220.127.116.11 RC, with same results. Mac OS X 10.10 (Yosemite), JRE 1.6.