Props and Feature Request
Props and Feature Request
Nice little tool, Very handy.
At the time of writing this, I was not able to register a "Log Service" account, due to it saying the service was full. This was irritating.
A few things to note thou:
-Web Service: Should be able to specify which IP the RTB Web Interface is bound to. A bit of a pain in the arse when you have your SC services all running off of one IP which are all associated with a specific domain name, and RTB binds itself to another IP, which has another domain on it.... it creates headaches.
-Java Applet: On the web interface a little java applet that shows the same information as the Graph or Current Stats displays when actually looking at the program. Thus allowing all management and technical staff to monitor the stations performance, without having to run more than one instance of RTB on multiple computers.
-Graph: The ability to output this graph every so often to a png/gif file for updating on a website.
-Script: It is noted that there looks to be some sort of MySQL support in the near future, this should include, full song tracking support. Allowing station managers to view what songs are played most, least, users joined or lost per song, etc.
Perhaps the ability to have RTB accept a "flag" from the current DJ marking a song as a requested song and not one from the DJ's play list. Thus allowing tracking of Most Requested songs, etc.
Also, title checking tell RTB not to track certain tracks in the database, such as Promos, Ad's, Station IDs, etc... (IE: Promo01--NOTRACK would tell RTB not to track that item)
[Edit]
In thinking about this, perhaps instead of not tracking Promos, Ads, and Station IDs, they should be tracked but into a seperate report, showing how many users heard this ad over a period of time, or how many times this promo is being used, etc. But still not added into the song tracking as it would just be a bother.
[/Edit]
-Stations: Grouping of servers by station, IE: The station I currently work with has a primary feed server, plus 3 relays, as well as 3 or 4 test servers to allow our DJs to setup their sets, make sure their feeds will come across clean, etc. If I could group my production servers into say "Production" and have it track stats, etc separately from my "Test Server" group, again would allow me to track all my stations resources from one instance of RTB. And of course, the option to track stats on a group/server into the database or simply just show its current status.
-Full DB support: All station/server information stored in a DB.
Just a few ideas that popped up while I was setting up RTB, by far your package offers the most from the others that I have been able to find. It has the most potential and is also the least invasive, which for me is a major point. Thanks a lot and keep up the good work! If some of the features suggested above make it into the product it would be definatly something I would buy.
tek
tek (at) aurekx (dot) net
At the time of writing this, I was not able to register a "Log Service" account, due to it saying the service was full. This was irritating.
A few things to note thou:
-Web Service: Should be able to specify which IP the RTB Web Interface is bound to. A bit of a pain in the arse when you have your SC services all running off of one IP which are all associated with a specific domain name, and RTB binds itself to another IP, which has another domain on it.... it creates headaches.
-Java Applet: On the web interface a little java applet that shows the same information as the Graph or Current Stats displays when actually looking at the program. Thus allowing all management and technical staff to monitor the stations performance, without having to run more than one instance of RTB on multiple computers.
-Graph: The ability to output this graph every so often to a png/gif file for updating on a website.
-Script: It is noted that there looks to be some sort of MySQL support in the near future, this should include, full song tracking support. Allowing station managers to view what songs are played most, least, users joined or lost per song, etc.
Perhaps the ability to have RTB accept a "flag" from the current DJ marking a song as a requested song and not one from the DJ's play list. Thus allowing tracking of Most Requested songs, etc.
Also, title checking tell RTB not to track certain tracks in the database, such as Promos, Ad's, Station IDs, etc... (IE: Promo01--NOTRACK would tell RTB not to track that item)
[Edit]
In thinking about this, perhaps instead of not tracking Promos, Ads, and Station IDs, they should be tracked but into a seperate report, showing how many users heard this ad over a period of time, or how many times this promo is being used, etc. But still not added into the song tracking as it would just be a bother.
[/Edit]
-Stations: Grouping of servers by station, IE: The station I currently work with has a primary feed server, plus 3 relays, as well as 3 or 4 test servers to allow our DJs to setup their sets, make sure their feeds will come across clean, etc. If I could group my production servers into say "Production" and have it track stats, etc separately from my "Test Server" group, again would allow me to track all my stations resources from one instance of RTB. And of course, the option to track stats on a group/server into the database or simply just show its current status.
-Full DB support: All station/server information stored in a DB.
Just a few ideas that popped up while I was setting up RTB, by far your package offers the most from the others that I have been able to find. It has the most potential and is also the least invasive, which for me is a major point. Thanks a lot and keep up the good work! If some of the features suggested above make it into the product it would be definatly something I would buy.
tek
tek (at) aurekx (dot) net
-
Jay
- Will work for food (Administrator)
- Posts: 3020
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
yea some of the statistics you mentioned are offered in the online log service or could be offered there.
Station grouping is something that would have to be offered much later. Would require quite a rewrite, but I have considered it. Also this could be offered in the Online Log Service now without any change to the application.
FYI I just looked and a slot is available at the online log service.
Station grouping is something that would have to be offered much later. Would require quite a rewrite, but I have considered it. Also this could be offered in the Online Log Service now without any change to the application.
FYI I just looked and a slot is available at the online log service.
- Jay
Yeah..
I got lucky and snagged that slot!
Already feeding it with some stats to start tracking.
Now that I can see the online log service, I know what it has to offer. It is usefull, but limited.
The reason I would like to see Full DB support is mainly to allow the running of reports on the fly, and customized and more intensive real-time tracking. You don't want me and my staff slamming your site with 30-100 refreshes per minute to keep tabs on things. Hence, if it goes into one of my DBs its all on me and I'm not racking your bandwidth!
But at is stands right now.. I like the tool.. alot!
I got lucky and snagged that slot!
Already feeding it with some stats to start tracking.Now that I can see the online log service, I know what it has to offer. It is usefull, but limited.
The reason I would like to see Full DB support is mainly to allow the running of reports on the fly, and customized and more intensive real-time tracking. You don't want me and my staff slamming your site with 30-100 refreshes per minute to keep tabs on things. Hence, if it goes into one of my DBs its all on me and I'm not racking your bandwidth!
But at is stands right now.. I like the tool.. alot!
-
Jay
- Will work for food (Administrator)
- Posts: 3020
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
well the script service is really extensible, the whole reason I wrote it as I did was so that someone could extend it's capabilities to whatever you would like.
Unfortunately no one has stepped up to really show it's full potential and unfortunately my time has been extremely limited. I would probably update the log service before I would make changes to the includes script.
Unfortunately no one has stepped up to really show it's full potential and unfortunately my time has been extremely limited. I would probably update the log service before I would make changes to the includes script.
- Jay
Yeah.. The script service has that power..
Maybe I can bribe one of the php guru types i know to be my slave for a while and whip something up...
What I would realllllly love is if the information on the Current Stats window were pollable for a Java Applet.. That would make many people I know happy. If those values could be polled I could have someone write the java applet...
Maybe I can bribe one of the php guru types i know to be my slave for a while and whip something up...
What I would realllllly love is if the information on the Current Stats window were pollable for a Java Applet.. That would make many people I know happy. If those values could be polled I could have someone write the java applet...
-
Jay
- Will work for food (Administrator)
- Posts: 3020
- Joined: Mon Jan 14, 2002 12:48 am
- Location: Next Door
- Contact:
well my plan was mysql support would be funneled through the script interface stuff, so you can write a real simple catcher script which dumps data into a any database you like.
You can find rtb.xml in your web interface.
ie: http://localhost:4000/rtb.xml
You can find rtb.xml in your web interface.
ie: http://localhost:4000/rtb.xml
- Jay