I posted some time ago that I have a request site designed to work with IDJC, and there seemed to be no interest here for it. I'm bringing this up again to let everyone know that I have a request site that I'm willing to share.
It integrates with the latest IDJC (0.8.14) [with some patches to IDJC].
On the server side, all that's needed is PHP and MySQL (you have to be using a Ampache or P3 database for the site to work)
If you are interested, please contact me at brian at millham dot net and PLEASE include IDJC Request site in the subject so I see it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm bringing this up again to let everyone know that I have a request
site that I'm willing to share.
Great! Could you provide a few details about how requests work with your
code, please? I'm curious about how a request gets passed to the machine
running IDJC.
In the Airtime community we often get requests for listener
interactivity. We recommend IDJC as a source client for Airtime, but
that prompts the question of how to make that interactivity work with
both programs. For example, you might have hours of the night when the
IDJC users are offline and Airtime is scheduling the files to play out.
Cheers!
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are 2 ways that the request site can interact with IDJC. The easier mode is to have IDJC using the Ampache database on the web site directly (this will only work if you have a good internet connection) IDJC will see new requests within a few seconds of them being made. Tracks are marked as played by a script that runs on the server that is scraping the shoutcast server for play info.
The more complex way is to have IDJC run pointed to your local database, and run 2 scripts, one that watches the remote database for requests and populate the remote database, and a second script that uses the IDJCmon functionality to mark track as played on the request site.
Of course, there is a special songdb.py (the IDJC module that handles the database features) that has an additional tab: Requests.
The request site can handle either the P3 database format, or the Ampache database.
I don't use airplay, so I don't know how that would work.
If you would like to see my actual live request site, it's at http: // bmillham dot millham dot net
(Just trying to prevent spam here, I think you'll figure it out)
The request site is a very simple interface, as I don't like lots of fancy graphics, ect. I prefer a nice clean simple interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since there is some interest in this, I will work on getting a version of the code that I can release. As it currently is, there is lots of manual setup to get a site working, so I need to add a better way to do the setup. Initially, I won't have it available via git, I'll just do a tarball of it. Hopefully, I'll have something available in the next few days
My music taste is all over the place ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't forgotten about this :-) It turns out that I can't use the current git base, because it contains way to many (removed in the current master, but still in the history) files that just were not needed, accidentily added, etc. They make the current repostory HUGH, and just plain aren't needed, so I've decided to start over, make a new clean repository from the current version, with no history.
Once I get that done, I need to do some work on documenting how to set a site up. I'm working on a setup tool to help do most of the work.
At this time, each DJ needs to have a subdomain for the site to work. i.e.: dj1.yoursite.com, dj2.yoursite.com etc. And they will all need to clone their database to the request site server (I have a script for that for Ampache databases), or they need to allow the site to be able to access their local database (probably not a good idea), or move their database to the request site. (may work if you have a good internet connection)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I posted some time ago that I have a request site designed to work with IDJC, and there seemed to be no interest here for it. I'm bringing this up again to let everyone know that I have a request site that I'm willing to share.
It integrates with the latest IDJC (0.8.14) [with some patches to IDJC].
On the server side, all that's needed is PHP and MySQL (you have to be using a Ampache or P3 database for the site to work)
If you are interested, please contact me at brian at millham dot net and PLEASE include IDJC Request site in the subject so I see it.
Hi Brian,
Great! Could you provide a few details about how requests work with your
code, please? I'm curious about how a request gets passed to the machine
running IDJC.
In the Airtime community we often get requests for listener
interactivity. We recommend IDJC as a source client for Airtime, but
that prompts the question of how to make that interactivity work with
both programs. For example, you might have hours of the night when the
IDJC users are offline and Airtime is scheduling the files to play out.
Cheers!
Daniel
Im intrested, we are work with airtime, and dj work all with idjc 0.8.13
Creats
There are 2 ways that the request site can interact with IDJC. The easier mode is to have IDJC using the Ampache database on the web site directly (this will only work if you have a good internet connection) IDJC will see new requests within a few seconds of them being made. Tracks are marked as played by a script that runs on the server that is scraping the shoutcast server for play info.
The more complex way is to have IDJC run pointed to your local database, and run 2 scripts, one that watches the remote database for requests and populate the remote database, and a second script that uses the IDJCmon functionality to mark track as played on the request site.
Of course, there is a special songdb.py (the IDJC module that handles the database features) that has an additional tab: Requests.
The request site can handle either the P3 database format, or the Ampache database.
I don't use airplay, so I don't know how that would work.
If you would like to see my actual live request site, it's at http: // bmillham dot millham dot net
(Just trying to prevent spam here, I think you'll figure it out)
The request site is a very simple interface, as I don't like lots of fancy graphics, ect. I prefer a nice clean simple interface.
Hi Brian,
Thanks for explaining it - I'm sure if you release the code, you will
get more interest. Did you have a license in mind?
I've made a request, you have good music taste :-)
Cheers!
Daniel
Since there is some interest in this, I will work on getting a version of the code that I can release. As it currently is, there is lots of manual setup to get a site working, so I need to add a better way to do the setup. Initially, I won't have it available via git, I'll just do a tarball of it. Hopefully, I'll have something available in the next few days
My music taste is all over the place ;-)
I haven't forgotten about this :-) It turns out that I can't use the current git base, because it contains way to many (removed in the current master, but still in the history) files that just were not needed, accidentily added, etc. They make the current repostory HUGH, and just plain aren't needed, so I've decided to start over, make a new clean repository from the current version, with no history.
Once I get that done, I need to do some work on documenting how to set a site up. I'm working on a setup tool to help do most of the work.
At this time, each DJ needs to have a subdomain for the site to work. i.e.: dj1.yoursite.com, dj2.yoursite.com etc. And they will all need to clone their database to the request site server (I have a script for that for Ampache databases), or they need to allow the site to be able to access their local database (probably not a good idea), or move their database to the request site. (may work if you have a good internet connection)