XiphWiki - User contributions [en]

Icebreaker::Worklog

2007-08-14T19:45:25Z

Nickmudd:

'''Week 1 May 28-June 4''' 
Spent time reading. 
Started Wiki, sent mail to Icecast-dev. 
Started learning TurboGears. 
----
'''June 5''' 
Changed MySQLdb to SQLObject in populate.py 
----
'''June 6''' 
Added genre support to populate.py.
Committed populate.py and config.py to svn.
----
'''June 7-9''' 
Reading ''Producing Open Source Software'' and ''Rapid Web Applications with TurboGears.'' 
I've had a fever and sinus infection, and been away from the computer a lot. 
----
'''June 10-13''' 
More reading. Pleased to report that my sinus infection is gone and I am much better. 
Started designing database, writing pseudocode to figure out how to switch playlists, etc. 
----
'''June 14-15''' 
Reading ''Rapid Web Applications with TurboGears'' 
----
'''June 16-17''' 
In Chicago for the Cubs game. 
Didn't read much, just at the hotel at night. 
----
'''June 18''' 
Even more reading in ''Rapid Web Applications with TurboGears'' 
I'm beginning to realize I repeat myself a lot. 
----
'''June 19''' 
Finally started working on TurboGears frontend. 
Planning on committing the project to svn this afternoon after I get a few things written in there, just so I can get SOMETHING in svn because I feel like a slacker. 
Committed initial project files to svn. 
----
'''June 20-24''' 
Added views to TurboGears app. 
Added sample metadata to database. 
Reading more in ''Rapid Web Applications with TurboGears'' to figure out how to get data from forms and stuff. 
----
'''June 25-27''' 
Some more reading and trying to figure out forms. 
I'm looking at Select-Shuttle TurboGears widget for picking tracks from the database, but then i still have to make filtering the data work. Any suggestions? 
----
'''June 28''' 
Select-shuttle isn't working, trying to find documentation, help on #turbogears. 
----
'''June 29''' 
Added README file. 
Did some work in controllers.py to see if that jump starts the form, it doesn't. 
Took a look in the toolbox and specifically Select-shuttle's widgets.py and found a few clues, updated controllers.py and create.kid. 
create.kid was all wrong, all it needed was a few lines of code. controllers.py needed the variables I supplied to be passed to a select-shuttle module and then assigned to a new object i called create. 
Putting that into controllers.py did not work, I got the error "name 'create' is not defined." I decided to define it in create.kid also, the form displayed but did not jump values. I am not sure what difference that made. 
----
'''June 30-July 1''' 
I searched online to find the cause of the values not switching lists, I decided it must be related to javascript, but since i know nothing of javascript i have no idea what the problem is. 
I still searched to figure out why create wont get defined in controllers.py. Google code search didnt get me any examples, and i found no tutorials and only an antiquated explanation of its function on a mailing list. 
----
'''July 2-3''' 
Sent an email to Conrad asking for some help. Asked around in #turbogears for help, got no response. Repeated search for documentation and the like. 
----
'''July 4''' 
Happy Independence Day, I celebrated by drinking a few pints of some tasty British ales. MMMMMMMMMMM Nothing like celebrating our independence from the British than drinking British beer. 
----
'''July 5''' 
The usual searching, sent an email to the author of Select-Shuttle and as of 7-10 have no response.
----
'''July 6''' 
Decided to lay off searching for a while to get real work done, started the backend. 
----
'''July 7''' 
Read Chapter 12 "Time Operations" and Chapter 13 "Controlling Execution" in ''Python In a Nutshell'' to see how to handle the date/time stuff in the backend and see if i could find out how to make it a daemon.
----
'''July 8''' 
Heard back from Conrad. 
Made a few minor changes to create.kid 
Work on the backend. 
----
'''July 9-11''' 
Found a bit of code on how to daemonize. Cannibalizing it and my old script to make a new one. 
Added new variables to config.py. 
Removed python code block from create.kid, making it the correct way of handling things. 
If I cant get Select-shuttle going Im just gonna write my own forms by hand and use some ajax to do the job, its more code, but at least users wont have to download and install Select-shuttle as a dependency. 
----
'''July 12-13''' 
Realized that I didn't put support in icebreaker.py for stopping a playlist. For example, if I schedule a playlist to run from 7pm to 9pm it should switch off of the list onto shuffle mode or to another list.Doing a little re-working to get it the way it should work. 
----
'''July 14-15''' 
Edited icebreaker.py to make stop times work. Moved some stuff around, worked out some logical stuff on paper. 
----
'''July 16-17''' 
Worked on icebreaker.py, asked around on #turbogears for some help with forms. Power went out from 8am until after midnight so I got nothing done on the 17th. 
----
'''July 18''' 
Committed new version of icebreaker.py. 
----
'''July 19-24''' 
Fried computer, spent time reading and waiting on new computer to get here. 
----
'''July 25-29''' 
Installed Ubuntu on new computer, wrestled with TurboGears, gave up on TurboGears, moved on to the backend.
I also cracked the screen on my laptop, my BRAND NEW laptop, and had to send it in for repair. I've invested in a nice laptop case for it and I hope for that to never happen again. I was off of the internet completely for almost 2.5 weeks. Luckily it was under warranty but I lost a lot of time.
----
'''August 14''' 
I got the laptop back and started up work again. I want to switch from TurboGears to PyGTK. TurboGears sucks. I looked into Pylons and didnt feel like messing with that sort of thing again. If I want a Web interface at a later time, I will find a better way of doing it, probably writing my own self-contained program.

Icebreaker::Worklog

2007-08-14T19:41:25Z

Nickmudd:

Icebreaker::Worklog

2007-07-25T09:14:53Z

Nickmudd:

Icebreaker::Worklog

2007-07-18T15:42:49Z

Nickmudd:

Icebreaker::Worklog

2007-07-18T15:41:38Z

Nickmudd:

Icebreaker::Worklog

2007-07-16T01:08:31Z

Nickmudd:

Icebreaker::UserWantedFeatures

2007-07-14T09:30:50Z

Nickmudd:

== List of features requested by Users ==

=== GUI ===

I think an interesting alternative for a GUI would be a XUL interface.
I once saw a XUL interface for the Amarok music collection, and it was very neat.

=== Compatibility ===

I don't know a lot about the internals from icecast and the like, but it would be
really cool if it would be possible to use your software with StreamTranscoder.
(have a look at this: http://www.oddsock.org/tools/streamTranscoderV3/)
I think it's important to be able to split up streams, f.ex. to offer users
with a low bandwidth a resampled stream with a lower quality.
Though, the problem is, if you want to be compatible you propably will have to
abandon any direct interaction with the actual streaming server, and i don't know if
that is in your interest.

=== I/O ===

- XSPF playlist output format by default
- Amarok (http://amarok.kde.org) compatibility => XSPF as input format

- generation of xml config file for Ices

=== Scheduling ===

- hourly news / logo / commercial support
- scheduling differents playlists at different timeboxes (e.g. dub from 8-10, rock from 10-12, ...)

Icebreaker::Design

2007-07-14T09:30:17Z

Nickmudd:

= Design =
I've put a few things that I've been thinking about on this wiki page. 
If you would like to comment, please make a note. 
== Database ==
Here is a simple structure with explanations. 

Database: On a server or sqlite, doesnt matter. 
:data- table; houses file data. 
::path- path of file on the file system. 
::genre- genre example: Rock 
::artist- artist example: Misfits 
::title- title example: Hybrid Moments 
::album- album example: Static Age 
:playlists- table; definition on databases, scheduling, defined in web-app. 
::name- playlist name. 
::description- description of playlist 
::position- position in playlist, so that play is not started over from beginning. Incremented when track begins. 
::day- scheduling, a string of days to play??? numbers 1-7. 
::time- scheduling, a dictionary of times to play based with day (1-7) as key. 
::current- designates the currently running playlist, value is 1 or 0. 
:playlist- table, name of table is playlist? maybe incorporated in playlists table?

Icebreaker::Worklog

2007-07-14T09:18:18Z

Nickmudd:

'''Week 1 May 28-June 4''' 
Spent time reading. 
Started Wiki, sent mail to Icecast-dev. 
Started learning TurboGears. 
----
'''June 5''' 
Changed MySQLdb to SQLObject in populate.py 
----
'''June 6''' 
Added genre support to populate.py.
Committed populate.py and config.py to svn.
----
'''June 7-9''' 
Reading ''Producing Open Source Software'' and ''Rapid Web Applications with TurboGears.'' 
I've had a fever and sinus infection, and been away from the computer a lot. 
----
'''June 10-13''' 
More reading. Pleased to report that my sinus infection is gone and I am much better. 
Started designing database, writing pseudocode to figure out how to switch playlists, etc. 
----
'''June 14-15''' 
Reading ''Rapid Web Applications with TurboGears'' 
----
'''June 16-17''' 
In Chicago for the Cubs game. 
Didn't read much, just at the hotel at night. 
----
'''June 18''' 
Even more reading in ''Rapid Web Applications with TurboGears'' 
I'm beginning to realize I repeat myself a lot. 
----
'''June 19''' 
Finally started working on TurboGears frontend. 
Planning on committing the project to svn this afternoon after I get a few things written in there, just so I can get SOMETHING in svn because I feel like a slacker. 
Committed initial project files to svn. 
----
'''June 20-24''' 
Added views to TurboGears app. 
Added sample metadata to database. 
Reading more in ''Rapid Web Applications with Turbogears'' to figure out how to get data from forms and stuff. 
----
'''June 25-27''' 
Some more reading and trying to figure out forms. 
I'm looking at Select-Shuttle TurboGears widget for picking tracks from the database, but then i still have to make filtering the data work. Any suggestions? 
----
'''June 28''' 
Select-shuttle isnt working, trying to find documentation, help on #turbogears. 
----
'''June 29''' 
Added README file. 
Did some work in controllers.py to see if that jump starts the form, it doesnt. 
Took a look in the toolbox and specicifically Select-shuttle's widgets.py and found a few clues, updated controllers.py and create.kid. 
create.kid was all wrong, all it needed was a few lines of code. controllers.py needed the variables I supplied to be passed to a select-shuttle module and then assigned to a new object i called create. 
Putting that into controllers.py did not work, I got the error "name 'create' is not defined." I decided to define it in create.kid also, the form displayed but did not jump values. I am not sure what difference that made. 
----
'''June 30-July 1''' 
I searched online to find the cause of the values not switching lists, I decided it must be related to javascript, but since i know nothing of javascript i have no idea what the problem is. 
I still searched to figure out why create wont get defined in controllers.py. Google code search didnt get me any examples, and i found no tutorials and only an antiquated explanation of its function on a mailing list. 
----
'''July 2-3''' 
Sent an email to Conrad asking for some help. Asked around in #turbogears for help, got no response. Repeated search for documentation and the like. 
----
'''July 4''' 
Happy Independence Day, I celebrated by drinking a few pints of some tasty British ales. MMMMMMMMMMM Nothing like cepebrating our independence from the British than drinking British beer. 
----
'''July 5''' 
The usual searching, sent an email to the author of Select-Shuttle and as of 7-10 have no response.
----
'''July 6''' 
Decided to lay off searching for a while to get real work done, started the backend. 
----
'''July 7''' 
Read Chapter 12 "Time Operations" and Chapter 13 "Controlling Execution" in ''Python In a Nutshell'' to see how to handle the date/time stuff in the backend and see if i could find out how to make it a daemon.
----
'''July 8''' 
Heard back from Conrad. 
Made a few minor changes to create.kid 
Work on the backend. 
----
'''July 9-11''' 
Found a bit of code on how to daemonize. Cannibalizing it and my old script to make a new one. 
Added new variables to config.py. 
Removed python code block from create.kid, making it the correct way of handling things. 
If I cant get Select-shuttle going Im just gonna write my own forms by hand and use some ajax to do the job, its more code, but at least users wont have to download and install Select-shuttle as a dependency. 
----
'''July 12-13''' 
Realized that I didnt put support in icebreaker.py for stopping a playlist. For example, if I schedule a playlist to run from 7pm to 9pm it should swithc off of the list onto shuffle mode or to another list.Doing a little re-working to get it the way it should work.

Icebreaker::Worklog

2007-07-10T12:25:46Z

Nickmudd:

'''Week 1 May 28-June 4''' 
Spent time reading. 
Started Wiki, sent mail to Icecast-dev. 
Started learning TurboGears. 
----
'''June 5''' 
Changed MySQLdb to SQLObject in populate.py 
----
'''June 6''' 
Added genre support to populate.py.
Committed populate.py and config.py to svn.
----
'''June 7-9''' 
Reading ''Producing Open Source Software'' and ''Rapid Web Applications with TurboGears.'' 
I've had a fever and sinus infection, and been away from the computer a lot. 
----
'''June 10-13''' 
More reading. Pleased to report that my sinus infection is gone and I am much better. 
Started designing database, writing pseudocode to figure out how to switch playlists, etc. 
----
'''June 14-15''' 
Reading ''Rapid Web Applications with TurboGears'' 
----
'''June 16-17''' 
In Chicago for the Cubs game. 
Didn't read much, just at the hotel at night. 
----
'''June 18''' 
Even more reading in ''Rapid Web Applications with TurboGears'' 
I'm beginning to realize I repeat myself a lot. 
----
'''June 19''' 
Finally started working on TurboGears frontend. 
Planning on committing the project to svn this afternoon after I get a few things written in there, just so I can get SOMETHING in svn because I feel like a slacker. 
Committed initial project files to svn. 
----
'''June 20-24''' 
Added views to TurboGears app. 
Added sample metadata to database. 
Reading more in ''Rapid Web Applications with Turbogears'' to figure out how to get data from forms and stuff. 
----
'''June 25-27''' 
Some more reading and trying to figure out forms. 
I'm looking at Select-Shuttle TurboGears widget for picking tracks from the database, but then i still have to make filtering the data work. Any suggestions? 
----
'''June 28''' 
Select-shuttle isnt working, trying to find documentation, help on #turbogears. 
----
'''June 29''' 
Added README file. 
Did some work in controllers.py to see if that jump starts the form, it doesnt. 
Took a look in the toolbox and specicifically Select-shuttle's widgets.py and found a few clues, updated controllers.py and create.kid. 
create.kid was all wrong, all it needed was a few lines of code. controllers.py needed the variables I supplied to be passed to a select-shuttle module and then assigned to a new object i called create. 
Putting that into controllers.py did not work, I got the error "name 'create' is not defined." I decided to define it in create.kid also, the form displayed but did not jump values. I am not sure what difference that made. 
----
'''June 30-July 1''' 
I searched online to find the cause of the values not switching lists, I decided it must be related to javascript, but since i know nothing of javascript i have no idea what the problem is. 
I still searched to figure out why create wont get defined in controllers.py. Google code search didnt get me any examples, and i found no tutorials and only an antiquated explanation of its function on a mailing list. 
----
'''July 2-3''' 
Sent an email to Conrad asking for some help. Asked around in #turbogears for help, got no response. Repeated search for documentation and the like. 
----
'''July 4''' 
Happy Independence Day, I celebrated by drinking a few pints of some tasty British ales. MMMMMMMMMMM Nothing like cepebrating our independence from the British than drinking British beer. 
----
'''July 5''' 
The usual searching, sent an email to the author of Select-Shuttle and as of 7-10 have no response.
----
'''July 6''' 
Decided to lay off searching for a while to get real work done, started the backend. 
----
'''July 7''' 
Read Chapter 12 "Time Operations" and Chapter 13 "Controlling Execution" in ''Python In a Nutshell'' to see how to handle the date/time stuff in the backend and see if i could find out how to make it a daemon.
----
'''July 8''' 
Heard back from Conrad. 
Made a few minor changes to create.kid 
Work on the backend. 
----
'''July 9-10''' 
Found a bit of code on how to daemonize. Cannibalizing it and my old script to make a new one. 
Added new variables to config.py. 
Removed python code block from create.kid, making it the correct way of handling things. 
If I cant get Select-shuttle going Im just gonna write my own forms by hand and use some ajax to do the job, its more code, but at least users wont have to download and install Select-shuttle as a dependency.

Icebreaker

2007-06-29T06:56:58Z

Nickmudd: /* Subversion */

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Subversion ==
https://trac.xiph.org/browser/trunk/icebreaker

== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.

== Design ==

see [[Icebreaker::Design]]

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Worklog ==

see [[Icebreaker::Worklog]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory. 
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script. 
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead. 

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker

2007-06-29T06:34:20Z

Nickmudd: /* Application */

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Subversion ==
https://svn.xiph.org/trunk/icebreaker/
== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.

== Design ==

see [[Icebreaker::Design]]

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Worklog ==

see [[Icebreaker::Worklog]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory. 
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script. 
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead. 

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker::Worklog

2007-06-28T00:02:34Z

Nickmudd:

Icebreaker::Worklog

2007-06-25T23:26:12Z

Nickmudd:

Icebreaker::Worklog

2007-06-19T22:21:41Z

Nickmudd:

Icebreaker::Design

2007-06-19T13:03:35Z

Nickmudd:

Icebreaker::Worklog

2007-06-19T12:08:08Z

Nickmudd:

Icebreaker::Worklog

2007-06-19T12:07:14Z

Nickmudd:

Icebreaker

2007-06-14T07:23:34Z

Nickmudd:

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Subversion ==
https://svn.xiph.org/trunk/icebreaker/
== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.

== Design ==

see [[Icebreaker::Design]]

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Worklog ==

see [[Icebreaker::Worklog]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker

2007-06-14T07:11:26Z

Nickmudd:

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.

== Design ==

see [[Icebreaker::Design]]

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Worklog ==

see [[Icebreaker::Worklog]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker::Design

2007-06-14T07:08:45Z

Nickmudd:

= Design =
I've put a few things that I've been thinking about on this wiki page. 
If you would like to comment, please make a note. 
== Database ==
Here is a simple structure with explanations. 

Database: On a server or sqlite, doesnt matter. 
:data- table; houses file data. 
::path- path of file on the file system. 
::genre- genre example: Rock 
::artist- artist example: Misfits 
::title- title example: Hybrid Moments 
::album- album example: Static Age 
:playlists- table; definition on databases, scheduling, defined in web-app. 
::name- playlist name. 
::description- description of playlist 
::position- position in playlist, so that play is not started over from beginning. Incremented when track begins. 
::date/time- scheduling, a tuple of times to play, idk really. any suggestions? 
::current- designates the currently running playlist, value is 1 or 0. 
:playlist- table, name of table is playlist? maybe incorporated in playlists table? 

== Pseudocode ==
coming soon

Icebreaker::Worklog

2007-06-14T06:09:52Z

Nickmudd:

Icebreaker::Worklog

2007-06-14T05:43:13Z

Nickmudd:

Icebreaker::Worklog

2007-06-09T09:51:24Z

Nickmudd:

Icebreaker::Worklog

2007-06-07T05:26:07Z

Nickmudd:

Icebreaker::Worklog

2007-06-05T02:38:12Z

Nickmudd:

'''Week 1 May 28-June 4''' 
Spent time reading. 
Started Wiki, sent mail to Icecast-dev. 
Started learning TurboGears. 
----

Icebreaker

2007-06-04T23:16:35Z

Nickmudd:

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.
--[[User:Nickmudd|Nickmudd]] 18:54, 30 May 2007 (PDT)

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Worklog ==

see [[Icebreaker::Worklog]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest Vorbis collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses Ogg tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker

2007-06-01T05:01:03Z

Nickmudd:

== Introduction ==
Icebreaker is a playlist authoring/scheduling system for Icecast. It uses a database to store playlists and scheduling data. Icebreaker's main objective is to be easy to use, so that writing playlists by hand can be avoided. Icebreaker is being designed to use a web-based interface through TurboGears. Icebreaker is _NOT_ a web-based streamer or a client.

== Plans ==

My plans are as follows:

# Written in Python.
# Metadata in database.
# Playlists stored in database.
# Playlist scheduling.
# Backend/frontend design, possibly multible frontends.
# No web server needed, interface comes from TurboGears.
# Minimal configuration, after all thats why I started the project.
# SQLObject will be used to work with any database.
--[[User:Nickmudd|Nickmudd]] 18:54, 30 May 2007 (PDT)

== User Wanted Features ==

see [[Icebreaker::UserWantedFeatures]]

== Application ==

I run a Icecast stream for the use of myself and my friends, and while making playlists for it, I was very overcome by the enormity of the task. I have a modest OGG collection by some standards, 2500 tracks. I pity anyone that has ever tried to make playlists for a large streaming site with who knows how many tracks. What's more, I can't be bothered to switch playlists out all the time. So the natural progression seemed to be a simple drag-and-drop interface to create and schedule playlists.

I plan to use a separate backend from the web interface, so that a X-based frontend could be added eventually, or support could be added in an existing media application. SQLObject will be used to provide support for multiple databases with one set of code. I will try to minimize configuration to media path, and database connections, and password for the interface.

I have some code written, a script that populates a database, and a script that will be called by Ices and Icecast that provides the next track to play. I wish to include searching/adding media to a playlist based on metadata, as the populate.py script parses OGG tags and adds them to the database.

The frontend will be based off of TurboGears (http://www.turbogears.org) and could be packaged as a python egg, separately or included with the source for the backend. In the event that no playlist is scheduled, there will be a random playlist that will be automatically generated. Future plans are to integrate with Google Calendar, to display to any users which playlists will be scheduled. Another of my plans is to research integration with Icecast, to add support for controlling it. I've been thinking about this project and planning it since December, and I am extremely excited.

The main focus of this project is ease, and I will facilitate use in these ways:

1. Simple Interface, very self-explanatory.
2. Minimal configuration. No web server needed, no PHP, extremely easy to get up and running. (Possibly) a few Python Libraries to install. One short configuration file. However, Ices will need to be configured to accept input from a script.
3. Database agnostic. If no database server is installed, SQLite will work perfectly in it's stead.

My goals in this project are not overly ambitious, and will contribute greatly to media enthusiasts like myself. I have set up a project page on Google Code (http://code.google.com/p/icebreaker/). I have not released any code because the code is not usable by anyone other than myself for the initial development. Soon I will add the code I have completed to the project page after adding database support to the Ices-callable script. I realize this description is very short in comparison to the 7500 character limit, but a few details are currently "up in the air". Namely, how I will handle scheduling and whether or not I will daemonize the backend. I have several ideas on how to handle the internals, but it's too early to tell how it will work. Very soon I plan on doing a few flowcharts to illustrate the architecture of the project, and the various ways it may manifest.

I plan on having this application feature complete about 75% through the summer, as I am already greatly obsessed with it and am only abstaining from the project to focus on my schoolwork. I have the entire summer to work on this project if it is accepted and will spend at least 30 hours a week on it. Almost everything I code is media-oriented. I usually write converter scripts in python or bash to manipulate files. I am most comfortable in Python and I have done a little work in C. I also took a course in VB.net and hated every minute of it. I dont think of myself as a programmer, but I greatly enjoy making things and enjoying the outcome of my labor.

Though I wont contribute specifically to any one of your projects in code, I feel that my project will enhance other xiph projects.

Icebreaker

2007-05-31T01:56:57Z

Nickmudd:

Icebreaker

2007-05-31T01:54:54Z

Nickmudd:

Icebreaker

2007-05-31T01:46:12Z

Nickmudd:

Icebreaker

2007-05-31T01:45:40Z

Nickmudd:

Icebreaker

2007-05-31T00:28:32Z

Nickmudd: