Out of curiosity, I downloaded and compiled the rewrite of BurnItNow from GitHub. I really like the new GUI! It is far more intuitive than the original version, which I never really liked. Now, if we can get CDRTools working again on Haiku, we might have a good thing going into Beta 1.
Is this the version you were talking about? https://github.com/HaikuArchives/BurnItNow
There should be an older version of CDRtools in HaikuDepot:
https://depot.haiku-os.org/#/pkg/cdrtools/3/01/-/a18/1/x86_gcc2?bcguid=bc2-OOCH
A newer version of CDRtools will come available in HaikuDepot soon:
https://bitbucket.org/haikuports/haikuports/commits/6211bc60f66a2e63e161c314e45a1930e8c0a41d
Yes. That’s the version of BurnItNow! I tried out.
CDRTools 3.01a18 is the version that is in the current x86_gcc2 nightlies, and 3.01a07 in the x86_64 builds. The nightlies have been broken for a long time now (having tested them on four different PC’s with different CD\DVD burners). Only the alpha4.1 version is working (using 3.01a07).
I already have a ticket open in bug tracker for this issue.
If you burn a anyboot image on CD/DVD it is working!
Only the .zip versions of the nighties doesnt seem to work if burned to CD!?
I opened a ticket as well last month…
https://dev.haiku-os.org/ticket/11435
Is there any word on when we might expect to see the rewrite of BurnItNow2 completed and an update to the long-time-broken CDRTools? I recall that CDRTools 3.0.1a25 was a GSOC 2014 project that was completed.
You could try ask Diver and Humdinger to work on it.
They are currently working on the system cleaner app FilWip, but I am sure they would be happy to have a look afterwards.
BurnItNow and cdrtools-3.01~a27 are in haikuports and are building. I can upload those packages to HaikuDepot, but cannot test them, because I don’t have an optical drive. I’d also investigate if there’s a reason that the older version a18 in HaikuDepot hasn’t been updated with a27 yet.
Regards,
Humdinger
Thanks Humdinger. I haven’t had a working version of CDRTools on the nightly builds since the introduction of Package Management. Alpha 4.1 appears to work OK, but none of the nighty’s have worked for quite some time, even though all Haiku versions are sharing the same hardware. I have three different Haiku PC’s for testing, and several different optical drives.
Is the version of BurnItNow you’re uploading to Haiku Depot the rewrite (BurnItNow2) that Waddlesplash was working on, or the original version as can be found on Haikuware and BeBits?
The BurnItNow in haikuports is built from the waddlesplash’s import to HaikuArchives.
Meanwhile, I’ve spoken to waddlsplash and he tries to test things in the next days/weeks. But since it’s so easy to build the stuff yourself with haikuporter, why not give it a try? Since you have different hardware to test, it makes all the more sense. See the Get Started wiki at haikuports.
Regards,
Humdinger
I may give your suggestion a try over the weekend, and build these applications myself. These applications have been broken for almost two years now. Aside from testing hardware and filing tickets in bug tracker, what other steps can I take to help Haiku make progress on getting these working again?
I’d still recommend looking into building with haikuporter - fixing, improving, creating recipes is a nice way to improve the software environment, even if you’re not a coder. That said, I uploaded BurnItNow and an updated cdrtools to HaikuDepot with hrev49014. On IRC the majority was of the opinion that it’s better to put out those packages and get feedback from people trying it.
So, anyone testing that stuff (and other packages, of course), be invited to create an account within HaikuDepot and leave your ratings and comments!
Thanks,
Humdinger
If you file tickets, make sure to report them to those app’s bugtrackers, not Haiku’s. But that’s about it, short of finding a developer that’ll actively work on them. Right now, they are only barely maintained, i.e. should somebody notice a build breakage those might get fixed etc.
Regards,
Humdinger
I had a look at the IRC chat for that day…interesting.
Sometimes I feel like I’m the only one still using an optical drive, and “complaining” when it doesn’t work. 
Anyhow, here’s my setup. I have three PC’s, each one has a single hard drive with three Haiku partitions - Alpha 4.1, x86_gcc2, and x86_64. Only the boot partition is mounted. That’s how all my testing is done.
I did a quick test of CDRTools and BurnItNow, using the latest build (hrev49015 x86_gcc2) on one PC last night after work. I swapped in three different optical drives, and tried blanking a CDRW and burning a CDR using both command line and BurnItNow. Sorry to say it, but it still isn’t working.
I’ll try the other PC’s this weekend to see if changing the hardware platform makes a difference. I’ll post the results in the appropriate bug tracker.
Thanks!
I have posted on these social media groups asking for extra testers for BurnItNow:
https://plus.google.com/110289314930207973642/posts/RRdxaQuNvoq
Until cdrecord gets fixed, it really doesn’t make any sense testing BurnItNow, which is just a front end anyway.
Tonight I did a fresh install of Alpha 4.1, hrev49020 x86_gcc2, and hrev49020 x86_64 on their own partitions,so all would be sharing the exact same hardware. I then downloaded and copied the latest haiku-nightly.iso (hrev49020 x86_gcc2) to each partition. I used the exact same command line from the terminal to test whether cdrecord would write the iso file to a blank CD-R - “cdrecord dev=0,1,0 -dao /boot/home/haiku-nightly.iso”
The result: Alpha 4.1 burns the disk correctly; x86_gcc2 “cdrecord: Panic FIFO addr”, then counts down to 0 and does nothing, while x86_64 doesn’t even detect my optical drive “cdrecord: No target found.”
One other oddity. If the “-eject” flag is added into the command line, the nightly will eject the disc BEFORE the countdown to burn. Alpha 4.1 does what it is supposed to do - eject the disc after completion.
I found a couple of tickets in bug tracker which describe these same issues #8830 and #9201 - both 3 years old. I have attached the results of my testing to my currently open ticket #11257.
The problem lies in the FIFO buffer. If you record from the command line and set fs=16 CDRecord works. However, if you try to specify that value in the CDRecord settings file, it is ignored and returns “panic FIFO address.”. Apparently it is a known bug.
The way around it is to enter a value in the settings file in bytes, say 65536, in which case CDRecord will turn FIFO off and burn the disk.
I have just tried to burn the alpha 4.1 iso on a recent nightly - hrev49031
cdrecord was already present, BurnotNow2 was installed from HaikuDepot
The CD drive is identified as TSSTcorpCDDVDW SH-224DB (9,0,0)
The burning starts, then it shows a message:
Track 01: Total bytes read/written: 615106560/615106560 (300345 sectors).
The CD/DVD drive continues to spin and does not stop. Interestingly the image is still written, so manualy ejecting the CD stops the spinning of the drive.
So it is almost perfect…
Did you burn the image from the command line or from the GUI?
In my instance, I could not burn a CD until I used the following settings in the command line:
cdrecord dev=0,1,0 -dao fs=16 /boot/home/haiku-nightly.iso
Unless I specified FIFO size (e.g. fs=16), I would get “panic fifo addr.” error, and no burn. If no fs= option is present, cdrecord will try to get the FIFO size value from the CDR_FIFOSIZE environment. However, CDRecord appears to panic on any default FIFO settings greater than 128k in the cdrecord.config file for some reason. Entering CDR_FIFOSIZE=65536, for example, will cause cdrecord to determine that FIFO is too small, disable FIFO, and then it will use the cdrecord.config settings to successfully burn a disk.
I used the BurnItNow2 GUI from HaikuDepot.
The only thing I modified before the successful burn is changed the FIFO size in cdrecord.config to 65536 to disable it.
We shouldn’t have to disable FIFO to get it to work. The command line FIFO setting appears to work, but the configure file default FIFO settings are being ignored. This is what is broken. Have you tried 64 bit? In my case, 64 bit doesn’t detect the optical drive, even though it is sharing another partition on the same hardware.
Have you tried blanking a CDRW? I have tried both “fast” and “all” to no avail.
Can you please summarize the results of your testing in ticket #11257?
Thanks!