As referenced in this old thread - viewtopic.php?f=34&t=25954 This still doesn't work. The bif files are fine because if they are on another server, or on Amazon S3, they load and the video plays. The video is fine because without the bif file on the same local apache LAN server, the video plays. When they are both hosted by Apache, the buffering bar never fills up and it comes back with a timeout -5 error media corrupt.
It would be great if a solution could be found, or this could be fixed. Even with hosting bif files on USB, that will work with the newest beta firmware, but even if that goes live, it won't help anyone with old roku boxes on firmware 3. Plex resolved this problem by setting up a proxy server and secondary 'bif provider' service. I have set up a Raspberry Pi with apache just to serve bif files, so that works for me - and at 5 watts of power per hour it's not that big a deal - it was just a big hassle to set up (DHCP reservation, ftp setup, apache configuration, fiddling with SD card imaging, etc etc).
It's real easy to duplicate the issue - on a windows box, install Apache. Put an mp4 file in the htdocs folder. Create and place a bif file for that in the htdocs folder. Set the firewall to allow access on port 80. Have any roku channel try to load and play said file and bif file with rovideoscreen - using the 192.168.x.xxx IP of your pc. I guess I'm not surprised this wouldn't be fixed in four years, and it's not like a lot of people are doing this, but the limited threads documenting the issue ought to get someone there to at least acknowledge the problem exists.
BTW - on another note - the stated ffmpeg command for generating graphics does kind of work - I suppose it depends on your source video file. Most of the time for me it generates 3 of the same image and then an image from ~8 seconds, followed by 19 seconds, followed by 27 seconds, etc - it is fast, can be batched to do hundreds of videos, etc etc - but it is truly sloppy in the results, requiring files to be renamed after it's done, and so on. I tried builds of ffmpeg going back from the latest and 'greatest' to versions in 2008 and all exhibit this problem. The way I resolved it was using VirtualDub and a plugin to allow loading MP4 files. The 'ffmpeg input driver' mentioned here - http://www.donsalva.com/2011/07/03/how- ... virtualdub allows that. So you can load your mp4 into virutaldub, go to video/framerate and select "decimate by". If your video is 25fps then decimate by would be 250. If 23.976 then 239 would be 'close enough' - 29.976 would be 299 or 300... Well, then go to Video/Filters and add 'resize' to set your image dimensions (320x240) , and then file/export image sequence. It starts the numbering at 0, you can set the number of leading 0's, defaults to JPG and you can set quality, and it's faster than ffmpeg (at least it seems faster to me). Then you can run the standard biftool, python, ruby script or whatever you use for the images and it turns out accurate results.
VirtualDub also has a batch mode... It is also quicker to just re-run the batch file of your videos with changed dimensions for making SD images, than to use any graphic 'resizing' tool. Photoshop CS5 is waaay slow at resizing hundreds of thousands of graphics, one by one, so it's just easier/quicker to resave them from the source video at the size needed.
It's the Raspian Wheezy install from here -- http://www.raspberrypi.org/downloads/ I added Apache 2.2, added PHP, and added VSFTP - set the keyboard type to US, corrected the original 'boot header' present in the source raspian image, set the home directory to home/pi/www I changed the default file permissions for uploads to 777 so everything can read or execute the files as needed - since it's on your internal LAN, if you can't trust people in your home who can you trust? I couldn't get FTP to work with anonymous login, so the ftp login/password is the same as the image -
User name: pi Password: raspberry
You can connect with FTP, upload your bifs, and I recommend either setting the raspberry to a static IP internally (directions here: http://www.kevinhooke.com/2012/12/20/co ... pberry-pi/ ) If you are booting into the GUI already, run XTerminal to get to the command line.
If you don't want to set it internally, it's probably just quicker to set a dhcp reservation in your router for the raspberry pi's MAC Address. Then with your roku channel code, any BIF file you need, just point the url to the IP/location of your bif on the raspberrypi.
If you need to hold a lot more files than the 16GB card can hold (approximately 14GB are free on installation), you can extract the image to a 32GB/64GB card and rerun the raspi-config program to expand the image to the size of the card you are using. 16GB was the largest I had on hand, and I'll use more than 2GB, so I figured I'd just start with this 16GB one. It's big enough for my needs anyway.
The thought did occur to me, since the SDK has a sample for webserver that I used before and it worked fine - but I don't like how any connected USB device is never allowed to enter sleep mode - it gets super hot being plugged in for any period of time. I thought the bifs weren't working because it was missing the content-length header, but I tried forcing the header and it didn't make a difference, tried a bunch of different stuff that didn't work...so... The Plex guys would love to have it work too (according to their bif-server comments in their source code) so that they don't need to do the proxy dance and could run Plex with fewer resources - but until then, any solution seems reasonable to fill the need without paying for actual internet hosting.
No, but having the correct file extensions in the conf file changes the mime type header for the file. ie without 'bif specified it defaults to "text/plain" -- but adding bif it could change to "application/octet-stream". Plex uses octet-stream according to the source code here - https://github.com/anachirino/bifserver ... fserver.py Line 175 -- so I tried both and they have the same effect (timeout)