I was thinking it ought to be fairly modest whilst I try to get the developers up-to-speed on true svn collaboration - should we limit our ambitions to the GUI changes plus bugfixes that shake out of testing revision 71, or accept mass changes from the public at large and attempt a real 0.7.2 public/compiled release? How much testing is 'enough' for the latter? Should we have a beta cycle with revisions 72-7x and then a fully vetted "production" revision that we release?
Rodney
Revision 72 goals?
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
Well, first up, that CRF method for x264 should really work its way into the svn eventually. It's a better constant quality mode than the CQP method used right now. Maybe, for simplicity's sake, just replace CQP with the CRF instead of offering both? That could be done with a simple two line encx264.c edit. Whereas implementing it as a separate feature would require GUI changes, initializing a variable or two in a couple of headers, and adding it to HBTest. (Even calling CQP "constant quality" is slightly confusing. Reading discussions on doom9's forum, where a lot of the heavy lifting for x264's development occurs, "Constant Quality" usually means "CRF" and "Constant Quantizer" usually means "CQP.")
I'd like to see that new GUI dynaflash's been working on integrated.
Then there's that new MacIntel code I keep hearing about...
Besides that, I think just bug fixing. IMO, as long as the forum goes down every time rhester tries to do a 2-pass encode, a binary release is a little premature =)
So I guess what I'm suggesting is that r72 switches constant quality's method from CQP to CRF, includes the new GUI, and keeps the focus on stability for 2-pass encodes and x86 Macs. The result gets a binary release as 0.7.2. If either my CRF thing or dynaflash's GUI adds a bunch of bugs, they get held back. After 0.7.2's out, start accepting mass changes (can something be done about dvd ripping problems?) and go through a beta cycle.
Right now, the way I look at it, we're just updating HB by bringing it (late) into 2006: support for new iPods, recent x264, modern Macs. But after that's released in a stable form, I'd like to see some marked differences in functionality between this code base and titer's.
Whenever we do start adding features, what I really want to talk about is kinda grandiose: I'd like to get some advanced x264 options. I'll start a new thread eventually explaining exactly what I want to do. I already know how and where to pass the options to libx264 from HandBrake's encx264.c, and what each of those settings is called in the x264 API. I've even successfully put together a build that enables all of the advanced settings with hard coded values.
P.S.
Are there any particularly great resources for learning how to use an SVN?
I'd like to see that new GUI dynaflash's been working on integrated.
Then there's that new MacIntel code I keep hearing about...
Besides that, I think just bug fixing. IMO, as long as the forum goes down every time rhester tries to do a 2-pass encode, a binary release is a little premature =)
So I guess what I'm suggesting is that r72 switches constant quality's method from CQP to CRF, includes the new GUI, and keeps the focus on stability for 2-pass encodes and x86 Macs. The result gets a binary release as 0.7.2. If either my CRF thing or dynaflash's GUI adds a bunch of bugs, they get held back. After 0.7.2's out, start accepting mass changes (can something be done about dvd ripping problems?) and go through a beta cycle.
Right now, the way I look at it, we're just updating HB by bringing it (late) into 2006: support for new iPods, recent x264, modern Macs. But after that's released in a stable form, I'd like to see some marked differences in functionality between this code base and titer's.
Whenever we do start adding features, what I really want to talk about is kinda grandiose: I'd like to get some advanced x264 options. I'll start a new thread eventually explaining exactly what I want to do. I already know how and where to pass the options to libx264 from HandBrake's encx264.c, and what each of those settings is called in the x264 API. I've even successfully put together a build that enables all of the advanced settings with hard coded values.
P.S.
Are there any particularly great resources for learning how to use an SVN?
While I agree replacing CQP with CRF would be the faster (and most likely less risky) road, I'm not a big fan of needlessly eliminating functionality. As soon as you do it, someone will come along with a strong need or preference for CQP. 
I'd rather take the longer route of properly supporting both, in libhb, the CLI, and the GUI. It's worth the time and effort, in my opinion, and once done will likely remain static for some time.
I would very much like to see dynaflash's GUI make it into svn as well. Ideally, both his GUI and the addition of CRF would be coupled together, such that CRF and CQP (in addition to ABR) would be accessible from both GUI and CLI, giving users the best of all worlds (but then comes the burning question...if all is left unspecified, what is the default? I think it's best to do things the way they always have been there in order to maintain compatibility. Nobody uses the defaults anyway =).
I'm going to make a separate post on the MacIntel code to draw attention to it.
For clarification, any forum outages as a result of my testing are largely a result of the fact that the Linux box hosting this forum (and the svn) isn't real - it's a VMware virtual machine running on my XP Pro machine (see http://multics.dynalias.com/blog/?page_id=2 for details). Even when I nice the HBTest process, occasionally system I/O goes high enough to impact network connectivity, and the memory leaks used to outright crash out VMware. Both appear to no longer be a significant issue. =)
I applaud your desires to take HandBrake in a new and more powerful direction - that's something I'd like to see as well. I want it to maintain its roots as the "iPod widget of choice", because it performs so well in that role, but it is clearly capable of so much more. Besides the PSP and iPod market segments, there's a growing demand for "professional"-quality H.264 output that reaches into realms like HD that I think HandBrake could be at the forefront on.
Regarding SVN - there's nothing more instructional than setting up your own (it's ridiculously easy on Linux and I suspect similar on MacOS X) and toying with it in an environment you're free to break.
The one big limitation of SVN is there are no take-backs...check in a "bad" revision, and it stays forever, and the only way to resolve it is to check in another with the fix. That's probably it's greatest shortcoming compared to cvs (and the fact that revisions are at the project level rather than the file level - a theoretical difference of opinion that prompted svn in the first place).
The SVN FAQ at http://subversion.tigris.org/faq.html does have a good bit of information on common-case how-tos, and there's always the very-complete-but-somewhat-unwieldy Subversion Book at http://svnbook.red-bean.com/ for more in-depth study. 99% of open-source svn users never use more than 1% of the functionality of the tool, so the FAQ combined with local experimentation is almost always more than sufficient for all but edge cases.
Besides, this forum was created exclusively to support the developers, so as questions arise, feel free to post them - either myself or someone else knowledgable in Subversion (I do not claim to be an expert will be happy to assist, I'm sure.
Rodney
I'd rather take the longer route of properly supporting both, in libhb, the CLI, and the GUI. It's worth the time and effort, in my opinion, and once done will likely remain static for some time.I would very much like to see dynaflash's GUI make it into svn as well. Ideally, both his GUI and the addition of CRF would be coupled together, such that CRF and CQP (in addition to ABR) would be accessible from both GUI and CLI, giving users the best of all worlds (but then comes the burning question...if all is left unspecified, what is the default? I think it's best to do things the way they always have been there in order to maintain compatibility. Nobody uses the defaults anyway =).
I'm going to make a separate post on the MacIntel code to draw attention to it.
For clarification, any forum outages as a result of my testing are largely a result of the fact that the Linux box hosting this forum (and the svn) isn't real - it's a VMware virtual machine running on my XP Pro machine (see http://multics.dynalias.com/blog/?page_id=2 for details). Even when I nice the HBTest process, occasionally system I/O goes high enough to impact network connectivity, and the memory leaks used to outright crash out VMware. Both appear to no longer be a significant issue. =)
I applaud your desires to take HandBrake in a new and more powerful direction - that's something I'd like to see as well. I want it to maintain its roots as the "iPod widget of choice", because it performs so well in that role, but it is clearly capable of so much more. Besides the PSP and iPod market segments, there's a growing demand for "professional"-quality H.264 output that reaches into realms like HD that I think HandBrake could be at the forefront on.
Regarding SVN - there's nothing more instructional than setting up your own (it's ridiculously easy on Linux and I suspect similar on MacOS X) and toying with it in an environment you're free to break.
The one big limitation of SVN is there are no take-backs...check in a "bad" revision, and it stays forever, and the only way to resolve it is to check in another with the fix. That's probably it's greatest shortcoming compared to cvs (and the fact that revisions are at the project level rather than the file level - a theoretical difference of opinion that prompted svn in the first place).The SVN FAQ at http://subversion.tigris.org/faq.html does have a good bit of information on common-case how-tos, and there's always the very-complete-but-somewhat-unwieldy Subversion Book at http://svnbook.red-bean.com/ for more in-depth study. 99% of open-source svn users never use more than 1% of the functionality of the tool, so the FAQ combined with local experimentation is almost always more than sufficient for all but edge cases.
Besides, this forum was created exclusively to support the developers, so as questions arise, feel free to post them - either myself or someone else knowledgable in Subversion (I do not claim to be an expert
will be happy to assist, I'm sure.Rodney
Couldnt have said it better. Like it or not, just by reading the forums, the iPod currently has to be the number one target for HB right now. I agree that h264 is where things are likely to focus for a large number of HB users. Besides the iPod, I think the forthcoming iTV is likely to be a huge target as well, which obviously will support even higher quality h264 than the iPod currently does.I applaud your desires to take HandBrake in a new and more powerful direction - that's something I'd like to see as well. I want it to maintain its roots as the "iPod widget of choice", because it performs so well in that role, but it is clearly capable of so much more. Besides the PSP and iPod market segments, there's a growing demand for "professional"-quality H.264 output that reaches into realms like HD that I think HandBrake could be at the forefront on.
As far as the GUI goes, while I realize that it is just eye candy compared to the nuts and bolts c level encoding stuff, it is what a great majority of HB users interact with and see. So, I think it is largely what they base their opinion of HB on.
Personally, the road for the gui in my mind is that it is able to basically incorporate both the simplicity of Instant HB as well as the full capabilities of the Full HB. Ultimately one GUI and program that can satisfy the biggest Power User or the most basic noob. User prefs and saved settings
can make HB operation much simpler. I have even thought and tinkered with an "Expert and Basic" preference that changes the gui depending on your needs and what you are trying to accomplish.
That along with a "Hint" panel where you can specify in preference a target plaform to hint, would tell you if your settings meet that platforms requirements ie. iPod Video pre 1.2 firmware, iPod Video post 1.2 firmware, PSP. If this was easy to use and worked right, you could pretty much eliminate a good percentage of forum posts right there. Obviously this is nothing critical and may be kind of stupid, but I could see alot of people using it.
Anyway, those are just some of my thoughts regarding the gui.
Give me a few more days to get some additional features into it if only for demonstration and then I would love to share it with the rest to get some feedback. You guys tell me the best way to go about doing that.
Again, outstanding work all. Especially when everyone is busy right before the holidays, etc.
So, I will hammer out the CRF CQP into the user prefs (I can always take them out if they are not ready in time to post the next rev).rhester wrote:I would very much like to see dynaflash's GUI make it into svn as well. Ideally, both his GUI and the addition of CRF would be coupled together, such that CRF and CQP (in addition to ABR) would be accessible from both GUI and CLI, giving users the best of all worlds (but then comes the burning question...if all is left unspecified, what is the default? I think it's best to do things the way they always have been there in order to maintain compatibility. Nobody uses the defaults anyway =).
Also, I know it sounds trivial, but I am adding a pref to use default file output naming for MP4 to use .mp4 (as it currently is) or use iTunes/iPod friendly .m4v. This is something I am always changing when naming my files.
Just an update on the gui.
I have been busy at work lately and between that and pre holiday stuff, I have been hard pressed to develop the gui lately. But, plan to keep plugging away at it. I am hoping to be able to make it available next week, between Christmas and New Years. I think (at least for my use) it is an improvement over the current one and makes using HB less cumbersome.
Having said that, jbrjake and/or rhester, what do you want me to try to incorporate in terms of the CQP / CRF preference? Is that something we still want to try ?
One other note. MK2000 over on the official forums is offering a PPC binary of our 0.7.1a2 . Do we want to consider offering both PPC and Intel versions as a binary download for right after Christmas ? There are alot of new Video iPods sitting under Christmas Trees right now that will be opened on Dec. 25 and alot of people are going to be looking to fill them with content. May be an excellent time to get alot of feedback on the new iPod h.264 encoding!
Or, is that too aggressive?
If we do want to offer binary downloads, I would imagine that with Titers absence, we can't really use the official website. If we agree we want to try it, and we have no other means, I have a web server that I would be willing to offer. Only thing would be if the bandwidth went completely through the roof. But, I can handle a fair amount. I want to do what I can to help get the new version out if we feel we are ready.
Thoughts/Ideas/Concerns ?
I have been busy at work lately and between that and pre holiday stuff, I have been hard pressed to develop the gui lately. But, plan to keep plugging away at it. I am hoping to be able to make it available next week, between Christmas and New Years. I think (at least for my use) it is an improvement over the current one and makes using HB less cumbersome.
Having said that, jbrjake and/or rhester, what do you want me to try to incorporate in terms of the CQP / CRF preference? Is that something we still want to try ?
One other note. MK2000 over on the official forums is offering a PPC binary of our 0.7.1a2 . Do we want to consider offering both PPC and Intel versions as a binary download for right after Christmas ? There are alot of new Video iPods sitting under Christmas Trees right now that will be opened on Dec. 25 and alot of people are going to be looking to fill them with content. May be an excellent time to get alot of feedback on the new iPod h.264 encoding!
Or, is that too aggressive?
If we do want to offer binary downloads, I would imagine that with Titers absence, we can't really use the official website. If we agree we want to try it, and we have no other means, I have a web server that I would be willing to offer. Only thing would be if the bandwidth went completely through the roof. But, I can handle a fair amount. I want to do what I can to help get the new version out if we feel we are ready.
Thoughts/Ideas/Concerns ?
I'll leave the strategy discussions to you guys, but I'm currently hosting binaries at http://multics.dynalias.com/handbrake/ and would be happy to include the latest builds - all I need is a place to get them from.
E-mail or FTP is fine if no other convenient method exists, PM me for details.
Rodney
E-mail or FTP is fine if no other convenient method exists, PM me for details.
Rodney
Let's get your GUI going first, before adding a checkbox for CRF.dynaflash wrote: Having said that, jbrjake and/or rhester, what do you want me to try to incorporate in terms of the CQP / CRF preference? Is that something we still want to try ?
One other note. MK2000 over on the official forums is offering a PPC binary of our 0.7.1a2 . Do we want to consider offering both PPC and Intel versions as a binary download for right after Christmas ?
I'm still trying to wrap my head around how Interface Builder works. I'm not even sure yet how to pass a value from a widget in the GUI to libhb. I think the files we'll need to edit for CRF are: controller.mm, controller.h, common.c, common.h, and encx264.c. Plus the .nib. That sound about right? Anyway, I'd rather toy with that stuff in the new interface rather than in the old one.
As far as binary goes, I'd say we're not ready. For one thing, that failed compile attempt in the testing thread scares me. For another, trying to support a bunch of iPod newbies the day after Christmas would be a nightmare, imo. If someone really wants it, they'll find MK2000's build. I think having an official binary release might give users the impression that a milestone's been hit, when it really hasn't. As long as trying to read from the optical drive makes HB crash, we've got issues. =(
EDIT: I just tried reading from the optical drive in HBTest. Works great, as does scanning every title on the DVD. This makes me believe that getting DVD read working again in the GUI might be real easy...
In retrospect, after reading your input, I have to agree. In my excitement over the new h.264 output and what not. I forgot all about the optical drive issue. I always run HB off of a folder on my hd, so had totally forgotten that =( . You are right.jbrjake wrote:As far as binary goes, I'd say we're not ready. For one thing, that failed compile attempt in the testing thread scares me. For another, trying to support a bunch of iPod newbies the day after Christmas would be a nightmare, imo. If someone really wants it, they'll find MK2000's build. I think having an official binary release might give users the impression that a milestone's been hit, when it really hasn't. As long as trying to read from the optical drive makes HB crash, we've got issues. =(
A question that sounds stupid about the PPC Binary: Since I dont have an Intel machine, I cant verify this, but should'nt the HB compile be Universal? The last offical HB was a Universal Binary and I dont know what we would have changed to make it PPC only , or Intel only. I dont have much history working with Universal Binaries, so I dont know.
On the gui, I have been thinking I may go ahead and make it available to you guys to check out without the Multiple User Presets and we can go from there. What I will have is the ability to set one default group of settings as the default set when HB fires up.
All is working out okay except for the Picture size. Since that depends on the source resoltuion as to what is available for output resolution. But, I want to try something here that I took from Instant HB to extrapolate from your picture size when you set the default to apply to other sources. The other option would be to, for now anyway, have the default settings ignore picture size and leave you to set that for each source.
I would leave out the default prefs feature but, I really think this will help alot of people. Since, once you figure out what you like, you really can set up an encode with just one or two clicks. That will be nice. I also would like to look into the whole Optical Drive issue as well as the update notifications not working.
The simplest method would involve compiling the PPC version on an PPC machine and then the Intel version on an Intel machine. We would then use 'lipo' to merge them into a Universal Binary (this is according to a long ago post from titer over at the official forums)dynaflash wrote:In retrospect, after reading your input, I have to agree. In my excitement over the new h.264 output and what not. I forgot all about the optical drive issue. I always run HB off of a folder on my hd, so had totally forgotten that =( . You are right.jbrjake wrote:As far as binary goes, I'd say we're not ready. For one thing, that failed compile attempt in the testing thread scares me. For another, trying to support a bunch of iPod newbies the day after Christmas would be a nightmare, imo. If someone really wants it, they'll find MK2000's build. I think having an official binary release might give users the impression that a milestone's been hit, when it really hasn't. As long as trying to read from the optical drive makes HB crash, we've got issues. =(
A question that sounds stupid about the PPC Binary: Since I dont have an Intel machine, I cant verify this, but should'nt the HB compile be Universal? The last offical HB was a Universal Binary and I dont know what we would have changed to make it PPC only , or Intel only. I dont have much history working with Universal Binaries, so I dont know.
I don't have easy access to an Intel machine so that's why I'm not offering a Universal Binary.
It's possible that we don't actually need an Intel machine, though, if I'm reading Apple's tutorial on open source Universal Binary projects correctly.
http://developer.apple.com/opensource/b ... ersal.html
mk2000
My compile went fine on the Intel, although I'm still having the encoding issues with certain DVD's. I haven't looked into the compiling issues the previous Intel poster was having, but I should have some time this weekend to look at it. I was not using the OSX default version of Jam, I downloaded the one Titer instructed us to use, so I'll see if that was the issue.
When we want to post binaries, I'll be happy to compile a UB, but I believe you are right in that you can compile a UB on any system in XCode, Intel or PPC. My only questions would be that I have never compiled a project of this nature into a UB. By that I mean, a project that would benefit from processor specific optimizations (Altivec, MMX, etc.) XCode would compile the OSX specific code into a UB, but the code compiled by the Jam process might not be properly optimized. Again, this is all new to me. I don't know what that would do to the UB build process, but I think its worth looking into. Having two separate binaries seems messy when the Apple standard is to go Universal.
When we want to post binaries, I'll be happy to compile a UB, but I believe you are right in that you can compile a UB on any system in XCode, Intel or PPC. My only questions would be that I have never compiled a project of this nature into a UB. By that I mean, a project that would benefit from processor specific optimizations (Altivec, MMX, etc.) XCode would compile the OSX specific code into a UB, but the code compiled by the Jam process might not be properly optimized. Again, this is all new to me. I don't know what that would do to the UB build process, but I think its worth looking into. Having two separate binaries seems messy when the Apple standard is to go Universal.
I just got this from the BUILD file in the main project directory.
Again, I don't know if this is the cause of the Intel compile problems others are having, but Rev72 compiled cleanly on my machine after making this one change/addition. I should have documented that better in my posts.
I downloaded, put it in the main project directory, and ran it instead of the OSX default installation. (./configure && ./jam).+ jam
I use 2.5rc3, earlier versions might cause issues.
On BeOS, you can download it at <http://www.haiku-os.org/develop.php>.
On OS X, you cannot use the modified jam shipped with the developer
tools, use this one instead:
<http://download.m0k.org/handbrake/jam-2.5rc3-OSX.zip>.
Again, I don't know if this is the cause of the Intel compile problems others are having, but Rev72 compiled cleanly on my machine after making this one change/addition. I should have documented that better in my posts.
SndChsr, yup, in fact all mac, PPC or Intel requires that file. It has never been very well documented. When I first started poking around with compiling handbrake from the source, I actually just happened to stumble on it.
Brings up what is probably a stupid question, but why not just include that file in with the rest of them? I am a bit unclear as to why it is a separate download.
Never have figured that one out.
Brings up what is probably a stupid question, but why not just include that file in with the rest of them? I am a bit unclear as to why it is a separate download.
Never have figured that one out.
Okay, here is the Universal Binary of 0.7.1a2 that I created:
http://www.evolutionkakumei.com/HandBra ... 1a2-UB.zip
I've tested it lightly on the PPC side and it runs fine but I don't know about its encoding ability on the Intel side.
I did compile the Intel binary on my parents' iMac Core 2 Duo but since I did it remotely I could not actually play with a VIDEO_TS folder (since no one was around to insert a DVD).
Anyhow, lipo worked great in making the UB.
If somebody could do some light testing with the UB on an Intel machine and let us know if it works, that would be great!
p.s. I thought that maybe titer had died or something but I went to check the forums for his Transmission project (same m0k.org) and he just posted on Dec 18!
mk2000
http://www.evolutionkakumei.com/HandBra ... 1a2-UB.zip
I've tested it lightly on the PPC side and it runs fine but I don't know about its encoding ability on the Intel side.
I did compile the Intel binary on my parents' iMac Core 2 Duo but since I did it remotely I could not actually play with a VIDEO_TS folder (since no one was around to insert a DVD).
Anyhow, lipo worked great in making the UB.
If somebody could do some light testing with the UB on an Intel machine and let us know if it works, that would be great!
p.s. I thought that maybe titer had died or something but I went to check the forums for his Transmission project (same m0k.org) and he just posted on Dec 18!
mk2000
First off, big thanks to you all for continuing development of this awesome app!
I've been been silently following development for a while (I'm no coder, unfortunately) and decided to jump in now since a Mactel tester was needed (that, I can do!).
Downloaded your UB, mk2000. App launches fine. After manual selection of DVD folder, rips and encodes as well. Currently ripping chapters 1, 2 of "40 Year Old Virgin" @ 21fps on a 1.83 MB w/ 2GB RAM.
On a semi-related note, I'm a long-time BeOS user. I own 3 copies, including R3.1, R4.5. Of course, I also have 5PE (never got r5 pro...). If testing is needed, I can assist there as well.
I've been been silently following development for a while (I'm no coder, unfortunately) and decided to jump in now since a Mactel tester was needed (that, I can do!).
Downloaded your UB, mk2000. App launches fine. After manual selection of DVD folder, rips and encodes as well. Currently ripping chapters 1, 2 of "40 Year Old Virgin" @ 21fps on a 1.83 MB w/ 2GB RAM.
On a semi-related note, I'm a long-time BeOS user. I own 3 copies, including R3.1, R4.5. Of course, I also have 5PE (never got r5 pro...). If testing is needed, I can assist there as well.
Rip completed successfully. Encoded using h.264 (Baseline 3.0).
Tested the gui out and seems solid. No crashes, hangs etc when clicking through any of the options.
P.S. Every time I launch this new UB, it notifies me of a "new" version, which looks like the last official build. Easily fixed by disabling that feature, and probably already known...
Tested the gui out and seems solid. No crashes, hangs etc when clicking through any of the options.
P.S. Every time I launch this new UB, it notifies me of a "new" version, which looks like the last official build. Easily fixed by disabling that feature, and probably already known...
New Icon
As already noted, GUI is what users probably notice most when using new builds.
Tom Stoelwinder ("Ice Spectre") designed a new icon that is much more representative of the app itself (what's the deal with the pineapple anyway!?)
They can be found here: http://www.modelconcept.net/?p=146
Would make a great default icon for all new builds, provided Tom gives permission. Perhaps someone more "official" could mail him?
(ice_spectre@modelconcept.net)
Tom Stoelwinder ("Ice Spectre") designed a new icon that is much more representative of the app itself (what's the deal with the pineapple anyway!?)
They can be found here: http://www.modelconcept.net/?p=146
Would make a great default icon for all new builds, provided Tom gives permission. Perhaps someone more "official" could mail him?
(ice_spectre@modelconcept.net)
Okay, thanks for testing the UB.
Both the "Check for New Version" bug and the "Read for Optical Drive" Bug existed before the UB.
Those cropped up once we move the svn from Titers Official Site to this svn. In the ensuing upgrades, we dont think any of that code changed, but obviously something is amiss which we will need to correct before we release anything to the general public.
However, for those of you testing this test build, here are the workarounds:
"Check for New Version": Go to prefs and uncheck "Check for new Version". The prefs code works and it will no longer check on startup.
"Read for Optical Drive": Manually navigate to the VIDEO_TS folder on said DVD in the drive, just like you would with a File Set on your hard drive (ie. as if you ripped the dvd first with MTR). Then it will read off the drive.
I am working through the mac prefs code as I am adding User Default Settings and will take a look at the dvd drive issue there. I am sure it is in the mac DriveDetector code as Drive Detection does work currently in the CLI.
Thanks all for the testing and feel free to keep posting your results and any problems you may encounter.
New GUI is in the works and I am hoping to have it out next week. I am really excited about this one!
Both the "Check for New Version" bug and the "Read for Optical Drive" Bug existed before the UB.
Those cropped up once we move the svn from Titers Official Site to this svn. In the ensuing upgrades, we dont think any of that code changed, but obviously something is amiss which we will need to correct before we release anything to the general public.
However, for those of you testing this test build, here are the workarounds:
"Check for New Version": Go to prefs and uncheck "Check for new Version". The prefs code works and it will no longer check on startup.
"Read for Optical Drive": Manually navigate to the VIDEO_TS folder on said DVD in the drive, just like you would with a File Set on your hard drive (ie. as if you ripped the dvd first with MTR). Then it will read off the drive.
I am working through the mac prefs code as I am adding User Default Settings and will take a look at the dvd drive issue there. I am sure it is in the mac DriveDetector code as Drive Detection does work currently in the CLI.
Thanks all for the testing and feel free to keep posting your results and any problems you may encounter.
New GUI is in the works and I am hoping to have it out next week. I am really excited about this one!
Re: New Icon
andrego, I agree about the nice quality of that icon, I have seen it before. However, I cannot speak for the other developers, but I am not in a position to change the default icon for what I still consider titers app. Especially since it is easily changed by the end user as it is for any Mac App.andrego wrote:As already noted, GUI is what users probably notice most when using new builds.
Tom Stoelwinder ("Ice Spectre") designed a new icon that is much more representative of the app itself (what's the deal with the pineapple anyway!?)
They can be found here: http://www.modelconcept.net/?p=146
Would make a great default icon for all new builds, provided Tom gives permission. Perhaps someone more "official" could mail him?
(ice_spectre@modelconcept.net)
In my opinion, we are kind of treading in strange waters (at least for me) in that we have moved ahead with a project without the participation and tutelage of its original developer.
In the case of the existing HB icon, it is synonymous of HB's lineage and although you can argue its artistic mertis, it has a sort of "quirky" place among the flood of photo-realistic mac app icons.
But, I am just one developer and am in no power to make any decisions like that.
More ironic still is that the version of x264 we incorporated into this rev. was checked into the svn over at the x264 website by none other than our beloved titer towards the end of November ! So, he is obviously involved in some projects still. Personally, I dont know if HB is his ugly stepchild, or what. But, that is his prerogative I guess, so hopefully, until he returns and takes over again, we can try to move ahead without him.p.s. I thought that maybe titer had died or something but I went to check the forums for his Transmission project (same m0k.org) and he just posted on Dec 18!
I suggest that we not use the SVN revision when discussing release builds. Every time we check a change in, the revision is going to increment. With 4 or 5 of us commiting changes, this revision will increase fairly rapidly.
We should probably follow the release versions previously used in HB. Does anyone know the current convention for versioning releases?
Looks like the current is 0.7.1....next is 0.7.2?
We should probably follow the release versions previously used in HB. Does anyone know the current convention for versioning releases?
Looks like the current is 0.7.1....next is 0.7.2?