Odd RTMP + DNS behavior - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: Add-on Support (https://forum.kodi.tv/forumdisplay.php?fid=27) +---- Forum: VideoPlayer InputStream (https://forum.kodi.tv/forumdisplay.php?fid=312) +---- Thread: Odd RTMP + DNS behavior (/showthread.php?tid=131642) |
Odd RTMP + DNS behavior - Ozymandyaz - 2012-05-16 Hi all - This is more of an FYI observation than anything else.. I have an ATV2 with XBMC and it works great. I use the "Canada on Demand" plug-in (cuz I live in Canada...) to watch stuff on the local TV networks (its like Free Cable but for Canada.) However in the last few weeks I also started using a DNS based US proxy/VPN provider so that I can use a US Netflix account. But, as soon as I did that, ALL of my RTMP based streaming broke in the ATV2. It took a lot of troubleshooting, but here is what I found: Looks like using any kind of DNS based solution to to get around IP geo-coding has a tendency to break ATV2 streaming. In fact using google DNS (8.8.8.8) also breaks all of my RTMP streams, but ONLY for the ATV2... I have an ATV1 Crystalbuntu box and a Windows XBMC install that both play the streams just fine regardless of what DNS server they are attached to... So its very specific to the ATV2. I read somewhere that even iTunes streaming was having trouble with stuff like Google or open DNS because they would cause the geo-coding to misread the location of the IP address and in turn send the stream request to the wrong Akami CDN hub... Either way, I suspect its an RTMP issue here, but I find it odd that Windows and Linux RTMP do not suffer the same issue. Anyone else seeing this behaviour? Any workarounds? RE: Odd RTMP + DNS behavior - macf1an - 2012-05-16 there are good dns geo-masking services and there are.. not so good ones. In general if a dns provider claims a site as "supported" you should be ok. Not all sites work "right-out-of-the-box" - some need particular support by the server. The effect you see is known (to me at least) and happens with some free dns services - I've experienced it with the epixhd addon in particular. The stream just fails to load.. A tested and working (but paid) option is unotelly. Netflix, Epix, Hulu, Crackle, Pandora, Vevo - all play fine on eden with both the default and the updated rtmp from supertv. Watch your logs for the type of error the rtmp srever returns. Warnings "client requested 6 server sent 9" are usually skippable but if you see a handshake type 9 error - choose another cdn (if present) or upgrade your librtmp RE: Odd RTMP + DNS behavior - Ozymandyaz - 2012-05-16 (2012-05-16, 21:26)macf1an Wrote: there are good dns geo-masking services and there are.. not so good ones. Hi there macf1an - Thanks for taking a look! I agree that there are good and bad geo-masking services as I have tried a few. I also think its interesting that I see the same behaviour when I use 8.8.8.8 as my DNS. The service I am using right-now works perfectly for Netflix (on the ATV2 as well as all my other boxes), Pandora, Hulu etc... And it works great with XBMC in an ATV1 (Crystalbuntu) and a windows set-up. The only issue that I have right now is specific to the ATV2. I have tried on iOS 4.3 and 5.0 with the same result and I have also updated my librtmp to the one that Bluecop complied a while back. Here is a snippet of the error I receive: Code: 06:19:16 T:149725184 NOTICE: {'app': 'ondemand', 'scheme': 'rtmpe', 'querystring': 'auth=dbEc8bFaFckc1crbGaucsbzc5aybUaZa.cS-bpS6Lu-eS-iYG-ovF1onDCq&aifp=v001&slist=/s_!ctv/shows/2012/05/10/', 'playpath': 'mp4:s_!ctv/shows/2012/05/10/Conan-2254-clip02.mp4?auth=dbEc8bFaFckc1crbGaucsbzc5aybUaZa.cS-bpS6Lu-eS-iYG-ovF1onDCq&aifp=v001&slist=/s_!ctv/shows/2012/05/10/', 'netloc': 'cp45924.edgefcs.net'} RE: Odd RTMP + DNS behavior - macf1an - 2012-05-17 strange but true... until yesterday, hulu via unotelly was ok, using akamai with the default eden librtmp since today all akamai streams fail with the very same error..RTMP_ReadPacket, failed to read RTMP packet header I had to switch to level3 (not supported by the default librtmp due to HandleCtrl: SWFVerification Type 2 request not supported! Patches welcome...) but it's ok with supertv's librtmp (get it here http://supercloudtv.com/librtmp.html ) I guess akamai upped their game a bit.. RE: Odd RTMP + DNS behavior - Ozymandyaz - 2012-05-17 Actually, that new librtmp seems to have fixed me up... |