Last week was a busy week, a lot of action and idea's.
I haven't seen paradxum here for a while, we could use his input/vision.
But, what should we do now to keep the wheel moving? :)
Short Term:
- (like Lewis already said) Select (a) maintainer(s) with enough free time and a good knowledge about gjukebox to apply patches and make a new release, after a few beta's. We should make a list/change the list paradxum made with bugs/patches that have to be applied.
- Make and finish the road map and the requirements document on the WIKI.
- Get a good testing document. What should work, what should fail.
Long Term:
- Get feedback from users. What does the average jukebox user want? Witch options does he/she uses and the ones that are not in gjukebox.
- Another thing I've been thinking about is the massive functionality. Mpf20 support, downloading songs from other jukebox's installations. Does this work?
And what else can be done at the moment?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started to post exactly the same thing last night and decided not to submit it. :)
I applied your latest patch for ogg2analyse.pl and then realized that there is a point where you can't continue without checking things in to a semi-public CVS.
The maintainers haven't said a peep about the recent activity; should we assume that a fork of the project is the only way to keep it alive?
I've got a lot of changes on my live Jukebox, most important and drastic changes are the beginnings of the templates... I was thinking about posting my CVS tree to my personal webspace:
-- sort using field for albums
-- template for album cover display
-- downloading large coverart; displaying a small version of that coverart but storing both (later I want to use the large one in the album detail display)
-- moved some frequently used code in getpictures.pl to functions
-- fixed user-uploaded coverart, while at it I also force this to save large and small versions
-- fix for group selection (posted in forum)
-- change genre id numbers to ID3/Winamp 'standards' (although I realize this will mess up genres on existing installations... In the long run I think using a standardized genre group is better than a random list -- some may disagree and a mapping method can be investigated)
-- small fix for new daemonizing scheme in ripd.pl
---------------------
Would like to see
- auto rip on CD insert, auto eject on completion
- better administration (something like what Slash uses seems better -- put all variables into a table, don't use checkboxes or pull-downs, just use text fields)
- clean up streaming support
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry guys for my absence from the project for awhile ... my day job has been keeping me tied to the desk... (And falling over dead when I get home)...
I love to see that others are working on this project again. :)
WIKI? We have a WIKI... why wasn't I notified??!!?!
Honestly I've always just worried about the files that come with the package. If a requirement changes I've always tried and kept the Requirements document in the CVS updated. (And the install script since most of the install is scripted.)
When it comes to time spent on maintaining a project, I would like to state that it does take quite a bit of time. The simple process of applying a submitted patch may take a few hours. If youre familiar with the program, you have to make sure that the patch will not break anything. And honestly, most patches are not created with care, and need modification. That said, the patches are wonderful.
I agree that someone with the proper time and knowledge should maintain the project. (Please show me who that is... I we have any volunteers please raise your hand.)
Now for my 2cents on all the proposed improvements:
Response from users and input:
That is what this forum is for, seeing what people want and their opinion of it... the RFE is also a good place to see what people want.
Mass functionality:
I'm assuming youre talking about allowing the program to be easily used by a wider audience. I agree that this should be a focus. The primary way to achieve this is by providing packages for platforms. "I" unfortunately have been too busy to roll these like i had planned.
Mpf20:
I'm assuming that this is a type of solid state mp3 player. not <a href="http://www.axygen.com/jsp/coreIdDetail.jsp?coreId=MPF20"> this</a> . I'm not the expert on the downloading to players section, but the download to a Rio player section worked the last time I used it (quite awhile ago as it may be.)
downloading songs from other jukebox's installations:
I honestly was going to work on the whole syncing jboxs problem. From what I understand downloading songs from other jboxs isnt a problem, and is fully supported and working. But Ive never had anyone offer their jbox to me so I cant vouch for it. (and Im truthfully afraid to offer mine to others because mine is so big Im afraid of the bandwidth hit Id take from someone deciding to download 10,000 of my songs )
Forking the project:
I don't know, I guess that is up to you, we do value your input here, but it is open source, do as you wish I guess .... :)
Unresponsive developers:
peep. ;-P
Templates:
I am pretty torn on this issue. I believe that using a template system would be nice, and that we should use one that conforms to a standard. I lean towards Smarty for php myself (it's about as standard as I've found) The installation issue is problem, however we can always include a copy in the distro and link to that copy, that way we have no install problems and don't affect the users global php environment as much. ... Just an Idea, but I'm pretty open... If there is a better php template environment out there that others would rather see us use I'm open to the possibility.
Change genre id numbers to ID3/Winamp 'standards':
I am pretty firmly against this. The genre's id's in the table do not match the ID3/Winamp ones because those "standards" didn't exist when it was initially written. So, it did a match against the name of the genre. In addition it can automatically add user defined genres. To keep cross jukebox functionality the name of the genre should be used for matches and not the id number. (The id number is simply an index number). You can spit out the genre's name instead of the key with a simple join in your sql query. And yes, changing this would break others jukeboxes. If everyone is absolutely hell-bent on these index numbers matching than when a patch is submitted with these changes, a script to update peoples current db's should be included. (The script should be written to work with the build scripts update facilities)
I appreciate your other patches, I hope that I, or one of the other developers will have a chance to review and include them in the cvs version soon, however, many of us are chained to our desks if we want to eat. :)
Auto rip on CD insert:
Tricky, but I have faith in you. I dont know how to set an on insert event. Id love to know how though.
Auto eject on completion:
I would love this also.....
Better administration -- put all variables into a table:
They are. However the variables are identified as to type and thus generate the appropriate widget.
Just use text fields:-- Do not use cannon to kill a fly
Clean up streaming support:
That would be soooo soooo cool. ;)
There are a few things I would absolutely LOVE to see:
--- option for cd's to be ripped as a single file
(goes along with above) -- option for a song to be defined as part of a file i.e. file aaaa.ogg start time: 00:45:32 end time: 01:12:32
(yes, I'm a Floyd fan, yes , dsm rocks, and YES, hearing the breaks between songs bugs the hell out of me.)
--- Better import support. Allow the import script to view things at a directory level and process the svf checksums, m3u play list and .cue files.
--- CD Burning support (I know how to do it, Just too darned busy to write a ui for it in all the different themes..... any UI dev volunteers?)
--- I think I have a page full of little tweaks ... but there is a start. ... and it's late and I'd have to FIND that file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--- option for cd's to be ripped as a single file
(goes along with above) -- option for a song to be defined as part of
a file i.e. file aaaa.ogg start time: 00:45:32 end time: 01:12:32
(yes, I'm a Floyd fan, yes , dsm rocks, and YES, hearing the breaks
between songs bugs the hell out of me.)
----------------------
Just copy the ogg files to one big file :) It works with OGG, it's designed to allow those things :)
The CUE support isn't easy I think, you should change the database to get that working. This might be something for the future.
(And yes, I hate those skips between PF songs too :) )
-------------------------
> WIKI? We have a WIKI... why wasn't I notified??!!?!
Because you didn't monitor the forums? :) Well, that's a little but unfriendly, but I hope you've read the streaming thread in the help forums?
-----------------------------
> I agree that someone with the proper time and knowledge should
> maintain the project. (Please show me who that is... I we have any
> volunteers please raise your hand.)
*raises hand*. I haven't all the time in the world, but I'm still in school and get enough free hours. And maybe with help from William to have at least two people making regular commits to the CVS and maintaining things. With the current active developers of course! They can't be missed of course.
---------------------------------
I think that all the nice new features we are all talking about should wait. Our main priority should be releasing a new version, making a road map and all agree on witch way we should go. But thinking about those is always good. I'm going to post a road map on the wiki in the next few days, at the moment in writing something. If you all would edit the things you don't like or discuss them here when it's finished?
Including the templates by Wellis sounds very cool, but it might be too fresh/new to put the code in the new 4.1 release. Maybe 4.2 or 5?
About the fork: I don't think that will be necessary? I've never had any trouble with the developers here.
It's cool to see some progress, even it it's a little bit slow and disorganized in the beginning.. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know how to rip them all as one... ... but it should be in the jbox..... and I should be able to listen to all "or" one of them without having a duplicate..... (i.e. if track 5 is playing, gets to the end, track6 of the same "file" is next, it should just never stop playing..... :) )
--- btw.. this will take awhile to write and implement.... <shrug> ... it would, in my opinion be the best way to do it.... ...albiet, time consming...
No, I don't expect everyone to monitor ALL the forums.... I monitor the Open Discussion and the dev mailing list. .... Devlopment and Program direction discussions don't belong in the Help forum.... (The one I don't monitor....) That forum is for help installing and using....
Ok, you have the time..... If you can e-mail me with some of your work, projects you've worked on. I don't want to sound mean, but maintaining a project is not exactly easy.... You can't merge a patch unless it's right... and doesn't break things..... (your not expected to be perfect.... but believe me... some users expect it.) ... It takes a TON of time and alot of patience... (and everyone wants their patches merged imediatly.... even if it breaks things and you wouldn't merge it no matter what.....) If your up to it I'd love to give henrik a yell on your behalf....
Honestly I agree, the new features should wait.... and that's why some of the feture update patches arn't in the cvs.... because I am simply trying to stabilize the jukebox so it works and can be installed easily. Then a tarball and some rpms can be included. lets get the true "bugs" out of the way. The other issue is if you guys really want to get this out the door then go through the bug list, and add comments and patches against the current cvs... and I'll reiterate.... go through the BUG list.... anotherwards enough discussing and fixing bugs through the forums... if someone asks for help regarding a bug.... point them at the bug in the tracker and leave it at that. We need the discussions there.... so that the Devlopers can keep track of it.... and btw, you think that's alot of bugs.... look at ....<a href="https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=the&field0-0-1=component&type0-0-1=substring&value0-0-1=the&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=the&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=the"> this </a>
We're not doing so bad.
Off I go to the day job.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Last week was a busy week, a lot of action and idea's.
I haven't seen paradxum here for a while, we could use his input/vision.
But, what should we do now to keep the wheel moving? :)
Short Term:
- (like Lewis already said) Select (a) maintainer(s) with enough free time and a good knowledge about gjukebox to apply patches and make a new release, after a few beta's. We should make a list/change the list paradxum made with bugs/patches that have to be applied.
- Make and finish the road map and the requirements document on the WIKI.
- Get a good testing document. What should work, what should fail.
Long Term:
- Get feedback from users. What does the average jukebox user want? Witch options does he/she uses and the ones that are not in gjukebox.
- Another thing I've been thinking about is the massive functionality. Mpf20 support, downloading songs from other jukebox's installations. Does this work?
And what else can be done at the moment?
I started to post exactly the same thing last night and decided not to submit it. :)
I applied your latest patch for ogg2analyse.pl and then realized that there is a point where you can't continue without checking things in to a semi-public CVS.
The maintainers haven't said a peep about the recent activity; should we assume that a fork of the project is the only way to keep it alive?
I've got a lot of changes on my live Jukebox, most important and drastic changes are the beginnings of the templates... I was thinking about posting my CVS tree to my personal webspace:
-- sort using field for albums
-- template for album cover display
-- downloading large coverart; displaying a small version of that coverart but storing both (later I want to use the large one in the album detail display)
-- moved some frequently used code in getpictures.pl to functions
-- fixed user-uploaded coverart, while at it I also force this to save large and small versions
-- fix for group selection (posted in forum)
-- change genre id numbers to ID3/Winamp 'standards' (although I realize this will mess up genres on existing installations... In the long run I think using a standardized genre group is better than a random list -- some may disagree and a mapping method can be investigated)
-- small fix for new daemonizing scheme in ripd.pl
---------------------
Would like to see
- auto rip on CD insert, auto eject on completion
- better administration (something like what Slash uses seems better -- put all variables into a table, don't use checkboxes or pull-downs, just use text fields)
- clean up streaming support
Sorry guys for my absence from the project for awhile ... my day job has been keeping me tied to the desk... (And falling over dead when I get home)...
I love to see that others are working on this project again. :)
WIKI? We have a WIKI... why wasn't I notified??!!?!
Honestly I've always just worried about the files that come with the package. If a requirement changes I've always tried and kept the Requirements document in the CVS updated. (And the install script since most of the install is scripted.)
When it comes to time spent on maintaining a project, I would like to state that it does take quite a bit of time. The simple process of applying a submitted patch may take a few hours. If youre familiar with the program, you have to make sure that the patch will not break anything. And honestly, most patches are not created with care, and need modification. That said, the patches are wonderful.
I agree that someone with the proper time and knowledge should maintain the project. (Please show me who that is... I we have any volunteers please raise your hand.)
Now for my 2cents on all the proposed improvements:
Response from users and input:
That is what this forum is for, seeing what people want and their opinion of it... the RFE is also a good place to see what people want.
Mass functionality:
I'm assuming youre talking about allowing the program to be easily used by a wider audience. I agree that this should be a focus. The primary way to achieve this is by providing packages for platforms. "I" unfortunately have been too busy to roll these like i had planned.
Mpf20:
I'm assuming that this is a type of solid state mp3 player. not <a href="http://www.axygen.com/jsp/coreIdDetail.jsp?coreId=MPF20"> this</a> . I'm not the expert on the downloading to players section, but the download to a Rio player section worked the last time I used it (quite awhile ago as it may be.)
downloading songs from other jukebox's installations:
I honestly was going to work on the whole syncing jboxs problem. From what I understand downloading songs from other jboxs isnt a problem, and is fully supported and working. But Ive never had anyone offer their jbox to me so I cant vouch for it. (and Im truthfully afraid to offer mine to others because mine is so big Im afraid of the bandwidth hit Id take from someone deciding to download 10,000 of my songs )
Forking the project:
I don't know, I guess that is up to you, we do value your input here, but it is open source, do as you wish I guess .... :)
Unresponsive developers:
peep. ;-P
Templates:
I am pretty torn on this issue. I believe that using a template system would be nice, and that we should use one that conforms to a standard. I lean towards Smarty for php myself (it's about as standard as I've found) The installation issue is problem, however we can always include a copy in the distro and link to that copy, that way we have no install problems and don't affect the users global php environment as much. ... Just an Idea, but I'm pretty open... If there is a better php template environment out there that others would rather see us use I'm open to the possibility.
Change genre id numbers to ID3/Winamp 'standards':
I am pretty firmly against this. The genre's id's in the table do not match the ID3/Winamp ones because those "standards" didn't exist when it was initially written. So, it did a match against the name of the genre. In addition it can automatically add user defined genres. To keep cross jukebox functionality the name of the genre should be used for matches and not the id number. (The id number is simply an index number). You can spit out the genre's name instead of the key with a simple join in your sql query. And yes, changing this would break others jukeboxes. If everyone is absolutely hell-bent on these index numbers matching than when a patch is submitted with these changes, a script to update peoples current db's should be included. (The script should be written to work with the build scripts update facilities)
I appreciate your other patches, I hope that I, or one of the other developers will have a chance to review and include them in the cvs version soon, however, many of us are chained to our desks if we want to eat. :)
Auto rip on CD insert:
Tricky, but I have faith in you. I dont know how to set an on insert event. Id love to know how though.
Auto eject on completion:
I would love this also.....
Better administration -- put all variables into a table:
They are. However the variables are identified as to type and thus generate the appropriate widget.
Just use text fields:-- Do not use cannon to kill a fly
Clean up streaming support:
That would be soooo soooo cool. ;)
There are a few things I would absolutely LOVE to see:
--- option for cd's to be ripped as a single file
(goes along with above) -- option for a song to be defined as part of a file i.e. file aaaa.ogg start time: 00:45:32 end time: 01:12:32
(yes, I'm a Floyd fan, yes , dsm rocks, and YES, hearing the breaks between songs bugs the hell out of me.)
--- Better import support. Allow the import script to view things at a directory level and process the svf checksums, m3u play list and .cue files.
--- CD Burning support (I know how to do it, Just too darned busy to write a ui for it in all the different themes..... any UI dev volunteers?)
--- I think I have a page full of little tweaks ... but there is a start. ... and it's late and I'd have to FIND that file.
Moving to the dev list...
--- option for cd's to be ripped as a single file
(goes along with above) -- option for a song to be defined as part of
a file i.e. file aaaa.ogg start time: 00:45:32 end time: 01:12:32
(yes, I'm a Floyd fan, yes , dsm rocks, and YES, hearing the breaks
between songs bugs the hell out of me.)
----------------------
Just copy the ogg files to one big file :) It works with OGG, it's designed to allow those things :)
The CUE support isn't easy I think, you should change the database to get that working. This might be something for the future.
(And yes, I hate those skips between PF songs too :) )
-------------------------
> WIKI? We have a WIKI... why wasn't I notified??!!?!
Because you didn't monitor the forums? :) Well, that's a little but unfriendly, but I hope you've read the streaming thread in the help forums?
-----------------------------
> I agree that someone with the proper time and knowledge should
> maintain the project. (Please show me who that is... I we have any
> volunteers please raise your hand.)
*raises hand*. I haven't all the time in the world, but I'm still in school and get enough free hours. And maybe with help from William to have at least two people making regular commits to the CVS and maintaining things. With the current active developers of course! They can't be missed of course.
---------------------------------
I think that all the nice new features we are all talking about should wait. Our main priority should be releasing a new version, making a road map and all agree on witch way we should go. But thinking about those is always good. I'm going to post a road map on the wiki in the next few days, at the moment in writing something. If you all would edit the things you don't like or discuss them here when it's finished?
Including the templates by Wellis sounds very cool, but it might be too fresh/new to put the code in the new 4.1 release. Maybe 4.2 or 5?
About the fork: I don't think that will be necessary? I've never had any trouble with the developers here.
It's cool to see some progress, even it it's a little bit slow and disorganized in the beginning.. :)
I know how to rip them all as one... ... but it should be in the jbox..... and I should be able to listen to all "or" one of them without having a duplicate..... (i.e. if track 5 is playing, gets to the end, track6 of the same "file" is next, it should just never stop playing..... :) )
--- btw.. this will take awhile to write and implement.... <shrug> ... it would, in my opinion be the best way to do it.... ...albiet, time consming...
No, I don't expect everyone to monitor ALL the forums.... I monitor the Open Discussion and the dev mailing list. .... Devlopment and Program direction discussions don't belong in the Help forum.... (The one I don't monitor....) That forum is for help installing and using....
Ok, you have the time..... If you can e-mail me with some of your work, projects you've worked on. I don't want to sound mean, but maintaining a project is not exactly easy.... You can't merge a patch unless it's right... and doesn't break things..... (your not expected to be perfect.... but believe me... some users expect it.) ... It takes a TON of time and alot of patience... (and everyone wants their patches merged imediatly.... even if it breaks things and you wouldn't merge it no matter what.....) If your up to it I'd love to give henrik a yell on your behalf....
Honestly I agree, the new features should wait.... and that's why some of the feture update patches arn't in the cvs.... because I am simply trying to stabilize the jukebox so it works and can be installed easily. Then a tarball and some rpms can be included. lets get the true "bugs" out of the way. The other issue is if you guys really want to get this out the door then go through the bug list, and add comments and patches against the current cvs... and I'll reiterate.... go through the BUG list.... anotherwards enough discussing and fixing bugs through the forums... if someone asks for help regarding a bug.... point them at the bug in the tracker and leave it at that. We need the discussions there.... so that the Devlopers can keep track of it.... and btw, you think that's alot of bugs.... look at ....<a href="https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=the&field0-0-1=component&type0-0-1=substring&value0-0-1=the&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=the&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=the"> this </a>
We're not doing so bad.
Off I go to the day job.