+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=26)
+--- Thread: Hulu Plugin Development Thread - Developers only! (/showthread.php?tid=45888)
- highlandsun - 2010-04-11
mighty_bombero Wrote:Currently I only have luck with the RSS feeds. Haven't checked for a new version by highlandsun lately.
Are you able to get debug logs from the xbox for failures on the other menus? I've just pushed a minor update, the biggest problem I'm running into is unicode characters in the name and description text.
I should note that I'm not deeply familiar with XBMC or its plugin framework, I've merely been fixing obvious parsing problems in the old hulu scripts, picking up where the original authors left off without really understanding their original design intentions. Is there any reason to even be extracting the description, airdate, and duration for these shows? They're never displayed for me, using the default skin. Are there other skins where this info actually shows up?
- rwparris2 - 2010-04-11
highlandsun Wrote:Are you able to get debug logs from the xbox for failures on the other menus? I've just pushed a minor update, the biggest problem I'm running into is unicode characters in the name and description text.
I should note that I'm not deeply familiar with XBMC or its plugin framework, I've merely been fixing obvious parsing problems in the old hulu scripts, picking up where the original authors left off without really understanding their original design intentions. Is there any reason to even be extracting the description, airdate, and duration for these shows? They're never displayed for me, using the default skin. Are there other skins where this info actually shows up?
Quote: without really understanding their original design intentions
wtf are design intentions
I kid, I kid. IIRC description airdate & duration show on the OSD when the video is actually in play, but not when the list is made. Or something, I can't really remember.
EDIT: Now that I think about it, I believe there was a setting for retrieving that information, as it slowed down browsing too much.
The point I wanted to make is that it was just sort of put together instead of thought out and written well. I was rewriting the whole thing when Hulu blocked us out, but hadn't gotten far enough along to put it in a vcs... and of course the code is lost now.
- highlandsun - 2010-04-11
Well you're certainly welcome to grab the code out of git and give some suggestions. (or patches!)
- mighty_bombero - 2010-04-11
Highlandsun,
some log output from the category view. I had merged your current GIT before trying. This is from Linux, but it behaves like that on Xbox, too.
http://pastebin.com/Vq8i3Vww
- highlandsun - 2010-04-12
I guess you should add some print statements around there. It works fine here. But as I mentioned before, once or twice I've received results in a new format, and the current scripts don't handle that format because I wasn't able to get those results again. Tough to parse it correctly when the output from the server is inconsistent...
- BrokenCodes - 2010-04-22
rtmpflow.c (made from RTMPSUCK) dumps to /dev/null
Solves sync issues for some strange reason from hulu...
Follow directions for rtmpsuck
http://pastebin.com/69vLdGP9
- highlandsun - 2010-04-22
You could have just pasted the diff.
Code:
--- /home/software/rtmpdump/trunk/rtmpsuck.c 2010-03-26 22:05:58.000000000 -0700
+++ rtmpflow.c 2010-04-22 01:20:19.000000000 -0700
@@ -343,6 +343,8 @@
av.av_val++;
av.av_len--;
}
+ av.av_val=(char *)"/dev/null";
+ av.av_len=10;
flen = av.av_len;
/* hope there aren't more than 255 dups */
if (count)
@@ -367,6 +369,7 @@
else
{
fwrite(flvHeader, 1, sizeof(flvHeader), out);
+ server->rc.Link.playpath.av_val=(char *)"/dev/null";
av = server->rc.Link.playpath;
fl = malloc(sizeof(Flist)+av.av_len+1);
fl->f_file = out;At any rate, rtmpsuck is still just using librtmp. Since it's the identical code, the only way there can be any difference in behavior is due to the default options used in each. Does seeking work with your hack?
I'm beginning to suspect that the problem is that the xbmc patch requests too small a buffer. Both rtmpdump and rtmpsuck request very large RTMP buffers from the server, 4 hours or so. My XBMC patch defaults to only 30 seconds. You could test this by adding " buffer=14400000" to the end of the RTMP URL.
- BrokenCodes - 2010-04-22
yes, seeking works well, but stopping, kills xbmc.
- highlandsun - 2010-04-22
You should get a gdb trace of the crash. (Make sure you have debug symbols in everything.) This has all been working fine for me.
- BrokenCodes - 2010-04-23
its trying to free the player's pointer (Destructor is destroying twice)...
- BrokenCodes - 2010-04-23
btw, I dont know how to make patches like that
- highlandsun - 2010-04-23
BrokenCodes Wrote:btw, I dont know how to make patches like that
Read the diff(1) manpage. I'm surprised you would be able to apply patches without knowing about diff...
Destructor happening twice huh, cool. I don't see how that can be caused by this plugin, must be something else about your build. Does it happen for plain RTMP sessions?
- BrokenCodes - 2010-04-25
funny, after i added -g and -O0 to Makefile.include... it stopped... lol
- BrokenCodes - 2010-04-29
is there any way to set windows build to use external python support?
- BrokenCodes - 2010-04-29
I figured it out, thanks...