Roku Developer Program

[bryankaiser]

I'm having an issue with my channel and bif files and wanted to see if anyone had seen anything similar.

I've added my SD and HD bif urls to my xml file and I've added support for them into the videoplayer example. I can see (from my Apache logs) that the Roku requests the bif file, but the video never begins playing. Sometimes it will give me the quality info (dots), other times not. From the Apache logs I can see that the Roku is requesting the video. If I press pause (or select) the bif images show and I can press Right/Left and select them. But no matter what I do the video won't play. If I remove the bif urls from the xml the video does play. The only info I see from the debugger is that the connection timed out. I'm not sure what it's timing out on as the request for the bif file does complete (200 in the Apache logs) and parts of the video are being delivered successfully (206s in the logs).

So, has anyone else seen this?

[bryankaiser]

I'm still having this issue. Here's a little more information:

I've tested this on several videos now and it fails universally. The video will get to the "Retrieving" screen, will sometimes show the dots, othertimes it won't, and then it just sits there. If I press pause (or select) while it is waiting to load, I can see the images from the bif file and I can cycle through them (either left/right or FF/RW). If I select one of the bif images, it starts to rebuffer, then continues to sit there. If I take the bif file out of the XML, everything works correctly.

The code changes I made to the videoplayer example were minor. In showFeed.brs I added lines to find the URLs in the XML (around line 130):

'fetch all values from the xml for the current show
item.hdImg            = validstr(curShow@hdImg) 
item.sdImg            = validstr(curShow@sdImg)
item.HDBifUrl		= validstr(curShow@HDBifUrl)
item.SDBifUrl		= validstr(curShow@SDBifUrl)

So I'm passing the path to the bif files as an attribute of the current <item> like so:

<item sdImg="http://192.168.1.98:8080/images/WEDDING.jpg" hdImg="http://192.168.1.98:8080/images/WEDDING.jpg" SDBifUrl="http://192.168.1.98:8080/encodes/bif/WEDDING_SD.bif" HDBifUrl="http://192.168.1.98:8080/encodes/bif/WEDDING_HD.bif">
		<title>Our Wedding Video</title>
		<contentId>10006</contentId>
		<contentType>movie</contentType>
		<contentQuality>SD</contentQuality>
		<media>
			<streamFormat>mp4</streamFormat>
			<streamQuality>SD</streamQuality>
			<streamBitrate>1900</streamBitrate>
			<streamUrl>http://192.168.1.98:8080/encodes/WEDDING.mp4</streamUrl>
		</media>
		<synopsis>Our Wedding Video</synopsis>
		<genres>Movie</genres>
		<runtime>4500</runtime>
	</item>

I created the bif files using the examples from viewtopic.php?t=23520. I used the same commands as RokuAaron, but with 16:9 dimensions (240x135 and 320x180). The Roku obviously sees the bif files and can load them (since I can get into trick play while it's trying to buffer), but the video never plays.

I've been through the docs several times and I can't find anything I'm missing. Has anyone gotten the bif files to work with the videoplayer example? Did you do anything differently than I have? I am doing this on windows, if that matters. I'm not sure where else to go from here.

[RokuAaron]

The problem seems to be that your video files are not playing, perhaps because they are not supported. I don't think this has anything to do with bifs; you may be chasing a red herring.

What we need to talk about is your encoding format, your encoder settings, etc.

[bryankaiser]

RokuAaron,

The videos play when I don't specify the bif url though. When I have the bif urls in my XML, the video will not play (but I can get into trick play), when I remove the bif urls, the video will play with no problems.

I did a test where I used a video that was 5 minutes of bars and tone. The bif file created off of that worked correctly, but using any other videos that I've encoded causes either a network error or a connection timeout. If I try to replay the video again immediately, it will cause the Roku to crash and restart.

I'm going to keep plugging away at this over the weekend, but I'd love any advice anyone has.

[RokuKevin]

This is just a wild guess (and maybe a bit of a goose chase), but may at least be worth a try..... We've seen issues with port numbers in URLs in other places in the sdk.

Could you run a quick test changing your bif URLs: http://192.168.1.98:8080/encodes/bif/WEDDING_HD.bif to something like http://192.168.1.98/encodes/bif/WEDDING_HD.bif. (not use the port number part of the url).

Let me know if that has any affect.

Thanks,

Kevin

[bryankaiser]

Kevin,

No dice on that I'm afraid. I reconfigured to push out on port 80 and removed the port setting in the URL. I still had the same issue. I'm trying to put together a test case that I'd be able to distribute (video and bif file included). This is, unfortunately, something that I can't debug. This makes me think that maybe a verbose logging mode for the ro* components might not be a bad idea. At least then we might be able to get a little more information that will help us solve these kinds of problems ourselves.

Bryan

[RokuKevin]

If you put together the test case, I'll take a look.

--Kevin

[mjr]

I'm running into *exactly* this same problem - the situation and symptoms are precisely as described by the original poster. This thread looks like it died without resolution four years ago, so maybe the OP gave up without finding a solution, but I'm hoping there's a known fix or workaround. Does anyone have any ideas?

One interesting data point. If I move the .bif files to a separate server box, it works. That is, the .bif is served from one physical server and the .mp4 is served from a separate physical server, both of which are Windows PCs on my LAN. This wouldn't be ideal as an actual solution, obviously, but I point it out in case it gives anyone any ideas about the underlying cause. Given that the two-box approach works, I next tried setting up a second Apache instance on the original physical server (on port 8080, vs the original Apache on port 80) and serving the .bif out of the port 8080 server and the .mp4 out of the port 80 server, but that's back to the original freeze-on-startup problem. The Apache access logs show successful GETs (status 200) for both the .bif and .mp4 in all scenarios, so whatever's going on doesn't seem to be a problem on the Apache side.