PDA

View Full Version : The XBMP/XBMC XStream Contest


Gamester17
2003-11-07, 17:14
xbmp/xbmc xstream contest

bald bouncer (uk) (http://www.baldbouncer.co.uk) has kindly donated some nice prizes for us to run this xstream contest. the goal of the contest is for you developers out there to create one platform independent and user-friendly xstream server (http://sourceforge.net/projects/xstream/), the code must be in c++ and fully open source. the ultimate goal is that when the contest is over we only end up with one, and only one official xstream server (http://sourceforge.net/projects/xstream/) which the xbmp/xbmc projects will retaining ownership of. the contest starts of right away and will come to an end in two months from now. all good entries (winners or not) can/will be integrated in the winning source code base, however the top-three entries (decided by the existing xbmp/xbmc team members) will win prizes listed bellow (again, thanks bald bouncer (http://www.baldbouncer.co.uk)) and get an invitation to join the official xstream development team (http://sourceforge.net/projects/xstream/). developers are allowed to enter the contest as a team, (in fact we encourage it), note however that a team entry will count as one entry.

prizes (sponsored by bald bouncer (http://www.baldbouncer.co.uk)):
first-prize: winner can select one (and only one) of these two alternatives bellow
*- alternative #1 (uk only): xbox pre-modded xecuter 2.2 pro (cromwell linux bios)*
*- alternative #2 (world-wide): 8 x xecuter 2.3 lite modchips (note lite, not liteplus)**
second-prize (world-wide): 5 x xecuter 2.3 lite modchips (note lite, not liteplus)**
third-prize (world-wide): 3 x xecuter 2.2 pro modchips**

xstream contest code requirements:
- full source must be submitted as open source (l/gpl)
- code must be c++ and compile under msvc++/msvs
- code can not have any specific compiler dependencies
- base core code must be platform (os/hw) independent
- full xns (http://www.xboxmediaplayer.de/cgi-bin/ib31/ikonboard.cgi?act=st;f=3;t=873) protocol server backwards compatibility option
- full xbmsprotocol (http://www.xboxmediaplayer.de/cgi-bin/ib31/ikonboard.cgi?act=st;f=3;t=2719) server backwards compatibility option
- server must be fully compatible with both xbmp & xbmc
- server must have a separate gui and service mode
- simple step to share one or several cd/dvd-rom drives
- configuration wizard/s (setting up shared file/folder etc.)
- xml base for multi-language support, similar to xbm-p/c
- compiled binary for win32 must also be produced at entry
- pc test client so other devs can develop without an xbox
- development documentation (structure/protocols, etc.)
* (note! development documentation/s are very important)

xstream contest code bonus points:
- configuration wizard to setup xbmp/xbmc xml file(s)
- parse zip, rar archives and/or cd image files (iso)
- build-in ftp-client in gui to transfer files to the xbox
- xns (http://www.xboxmediaplayer.de/cgi-bin/ib31/ikonboard.cgi?act=st;f=3;t=873)/xbmsp (http://www.xboxmediaplayer.de/cgi-bin/ib31/ikonboard.cgi?act=st;f=3;t=2719) protocol enhancements (such as proxy,
* *file-size, userid/password & no-disconnect support)
- upnp mediaserver (http://sourceforge.net/tracker/index.php?func=detail&aid=820610&group_id=87054&atid=581841) support in the pc server side code
- upnp mediarenderer (http://sourceforge.net/tracker/index.php?func=detail&aid=820603&group_id=87054&atid=581841) support for the client (xbmc) side
- upnp renderingcontrol (http://sourceforge.net/tracker/index.php?func=detail&aid=820609&group_id=87054&atid=581841) for the server and/or the client
- build-in dhcp server with option to enable/disable

xstream contest rules and conditions:
- contest requirements must be meet, but not bonuses
- no illegally acquired or copyrighted code can be used
- no illegally acquired or copyrighted pics can be used
- no existing xbmp or xbmc team members may join
- code judged on quality, functions, cleanness and docs
- if functions are equal winner will be chosen on quality
- the last competition submission date is 10/01-2004
- winner will be decided by the xbmp & xbmc team
- the winner will should announced before 25/01-2004
- one person or team may submit more than one entry
- if a team wins a prize they have to split it themselves
- the full source must be submitted before contest end
- all valid submissions can/will be integrated in code.
- prize winners must actively help unify their code in cvs
- we reserve the right to cancel this contest if needed

*only shipping to the united kingdom is possible for this because of cost/insurance/it-will-break
**shipping to one location only, meaning winner/s can not divide it up shipping to several locations

source code can be submitted here (link) (http://sourceforge.net/tracker/?group_id=94106&atid=606723), make sure you select "xstream contest #1" as category in order to join this contest. we recommend you register a sourceforge.net account (http://sourceforge.net/account/register.php) and login (https://sourceforge.net/account/login.php) before you submit a patch as you then can update or change the entry as you progress. note that sourceforge has a 256kb upload limited per file, though you can attach more than one file if you need more space you can upload the file/s here (link) (http://www.xboxmediaplayer.it/upload) after you submitted the entry on sourceforge to get a "patch entry id #".

ps! we would've loved to make upnp (http://www.upnp.org) support requireed, but we didn't because xdk multicast limitations (http://www.xboxmediaplayer.de/cgi-bin/ib31/ikonboard.cgi?act=st;f=3;t=3657).

Gamester17
2003-11-07, 18:11
prizes (sponsored by bald bouncer (http://www.baldbouncer.co.uk)):
first-prize: winner can select one (and only one) of these two alternatives bellow
- alternative #1 (uk only): xbox pre-modded xecuter 2.2 pro (cromwell linux bios)*
- alternative #2 (world-wide): 8 x xecuter 2.3 lite modchips (note lite, not liteplus)**
second-prize (world-wide): 5 x xecuter 2.3 lite modchips (note lite, not liteplus)**
third-prize (world-wide): 3 x xecuter 2.2 pro modchips*
just to clearify it; the winner does not get first, second and third prize, only one of the first-prize.
you see, second-prize is for the first runner-up, and the third-prize is for the second runner-up.

ravemax
2003-11-20, 21:44
not that ive the time to develope a server - busy with this real life thing - but this requirement bugs me:

code must be c++ and compile under msvc++/msvs
- why c++ and not c or even java (pretty portable ;-))
- msvc - costs much $$. what about gcc only ?

Gamester17
2003-11-21, 15:38
- why c++ and not c or even java (pretty portable ;-))c++ because all xbmp/xbmc official devs can c++ and can thus help with the code, not possible with java, delphi. etc.

- msvc - costs much $$. what about gcc only ?msvs is relativly expensive, msvc++ is not and are also available on trial with books or free versions for education.
(and again all xbmp/xbmc developers have msvc++ and/or msvs, this is to be one official maintained project)

Bhellium
2003-11-25, 23:29
im wondering how is the competition going? are there any teams out there?

/bhellium

Gamester17
2003-11-26, 13:51
im wondering how is the competition going?me too, i have not heard anything from anyone

san9jay
2003-11-26, 16:14
in my opinion i think writing the server in java would make a lot of sense. in one stroke you would get support for all the platforms.

i would be willing to write a java server if the competition is expanded to include java. (i probably will write a java server in any case since i have a couple of other applications in mind like tunnelling protocols over xns)

rjm2k
2003-11-26, 18:14
in my opinion i think writing the server in java would make a lot of sense. in one stroke you would get support for all the platforms.

i would be willing to write a java server if the competition is expanded to include java. (i probably will write a java server in any case since i have a couple of other applications in mind like tunnelling protocols over xns)
using java would be a great idea for a basic server, but would it cope with some of the more complex features that we currently have, like shoutcast scraping, zip/rar support etc?

Bhellium
2003-11-26, 19:31
back in the days of xbmp there was a java streaming server
remember, gamester17? my experience of it was that it was horribly slow and could barely stream mp3īz.
i am running mac, and im perfectly content with xbmsx.

gamester17 makes a good point that the people behind xbmc has
to be able to edit the code without any external help. if the coder
desides to not help in coding no more the entire xbmc comunity is stranded without a streamer.

/bhellium

san9jay
2003-11-26, 22:47
using java would be a great idea for a basic server, but would it cope with some of the more complex features that we currently have, like shoutcast scraping, zip/rar support etc?

i dont see why not. regarding shoutcast scraping. watch this space. i am putting the final touches for a replacement for shoutscraper written in java. shoutscraper does not seem to be developed/supported anymore.
zip support is very easy in java as well. i dont think the developers of xbmp/xbmc have time to develop eveything so having the servers in java will not prove to be a big drawback. as long as the code is opensource if the original developer stops developing it then somebody else can pick it up.

Gamester17
2003-11-27, 11:01
i'm sure java and other languages all have strenghts, etc. but the requirements for c++ in this contest will not change, sorry.

Bhellium
2003-11-29, 16:57
still, no response. no one is developing a new streamer?
that is not good news, i was hoping.

/bhellium

f00bs
2003-12-03, 05:30
the contest requirements are a bit strict... backwards compatability with protocols that have a lot of inherit problems just makes things more of a pain. if the goal is to create a streaming application that is the defacto standard for xbmc (ie to replace relax and ccxstream and friends) then why is backwards compatability a requirement?

i see the main problem with the current protocols "as is", is that when id3 tags are turned on its very very slow. i haven't look at any of the code, however it seems like in order to read the last whatever bytes of an mp3 to get the id3 info it is downloading (or seeking) to the end of the file and this is taking quite a while over the network. i dont see why this cant be done server side (ie on the host computer) and have the id3 information sent.

at any rate, it is a waste of developer resources for many people/teams to work on the same problem. why not have some knowledgeable dev come up with a technical requirements document that describes what the protocol should do, how it should fit into the application... and then split the prize amungst the people who aid in the development?

dont mean to piss in anyones cheerios, dont let me discourage any of you who are implementing bright ideas for this contest.

Gamester17
2003-12-03, 10:55
the contest requirements are a bit strict... backwards compatability with protocols
well, it should work with xns and xbmsp for xbmp 2.4 / cvs + latest xbmc (we don't care if don't work with older xbmp).
(i'm told that simply adding support for that should not take more that a couple of hours for a decent pro programmer)

Gamester17
2004-01-13, 14:56
last submission date for this xbmp/xbmc xstream contest has now passed without any entries, the contest is now closed.

ravemax
2004-01-13, 22:14
no entries ... some reasons:

- backwards compatibility <-- no need for it. the reason why the x86-cpu still and always will suck.
- configuration wizard <-- everyone should be able to modify a simple xml file.
- code can not have any specific compiler dependencies <-- its pretty hard to develope this kind of source with vs.

like mentioned before: a java server would be the solution - runs everywhere.