Opened 11 years ago
Closed 9 years ago
#10099 closed bug (fixed)
With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a18 for all builds
Reported by: | Giova84 | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/Command Line Tools | Version: | R1/Development |
Keywords: | Haiku PM cdrecord scanbus no longer able to see my burner device | Cc: | |
Blocked By: | Blocking: | #11257 | |
Platform: | x86 |
Description
hrev46198 cdrtools-3.01~a07 on Haiku without PM, was able to see and use my burner device. But now on Haiku PM, is no longer able to see my device.
cdrecord --scanbus
will result in:
Cdrecord-ProDVD-ProBD-Clone 3.01a07 (i586-pc-haiku) Copyright (C) 1995-2012 Joerg Schilling Using libscg version 'schily-0.9'. cdrecord: No target found.
Unfortunately the syslog doesn't show anything about this issue.
Attachments (1)
Change History (43)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 11 years ago
Can you try using this .hpkg on a Haiku hrev46203 or newer? http://ports-space.haiku-files.org/packages-to-test/cdrtools-3.01%7Ea17-1-x86_gcc2.hpkg
comment:4 by , 11 years ago
Hi Scott, This revision http://ports-space.haiku-files.org/packages-to-test/cdrtools-3.01%7Ea17-1-x86_gcc2.hpkg works as expected.
Thank you.
comment:5 by , 11 years ago
But.. There is a typo in the package name? Is reported as 3.01a17 but in terminal i read, instead, "3.01a16".
comment:6 by , 11 years ago
try using haikuporter to build the a18 version and see if that works and reports the correct version on the command line.
comment:7 by , 11 years ago
All fine with a18 version. So can you officially replace, on Haiku, the current a07 with a18?
comment:8 by , 11 years ago
Thanks for the feedback. If no one else beats me to it, I'll try to get it added within the next week. I need to put together a fresh partition to use for making Haiku builds, I've been working in a VM lately.
comment:9 by , 11 years ago
Hi, I see that the newer revision (a18) of cdrecord is applied in hrev46403, when the this nightly build will be available (i don't see new nightlies since days) i will send you a feedback.
follow-up: 26 comment:10 by , 11 years ago
ok. let's keep the ticket open until I get the gcc4 and x86_64 hpkg files added as well.
comment:12 by , 10 years ago
comment:13 by , 10 years ago
Summary: | With Haiku PM, cdrecord is no longer able to see my device. → With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a18 for all builds |
---|
comment:14 by , 10 years ago
Summary: | With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a18 for all builds → With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a25 (or newer) |
---|
comment:15 by , 10 years ago
Summary: | With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a25 (or newer) → With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a18 for all builds |
---|
See ticket #11257 for related issue.
comment:17 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
The gcc2 image is fine now, so moving out of R1 milestone.
comment:18 by , 10 years ago
hrev49020 x86_64 nightly fails to see the optical device. Alpha 4.1 and 32 bit nightly share the same hard drive on different partitions, and both detect it OK.
follow-up: 22 comment:19 by , 10 years ago
That's pretty much to be expected, as cdrecord on x86_64 is still the old version (3.01a07).
comment:22 by , 10 years ago
Replying to anevilyak:
That's pretty much to be expected, as cdrecord on x86_64 is still the old version (3.01a07).
Alpha 4.1 is also using 3.01a07 and it detects the drive no problem. Do you recall which hrev immediately preceded PM? I'd like to be sure that the 64 bit CDRecord wasn't broken before PM.
comment:23 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
comment:24 by , 10 years ago
Blocked By: | 11970 added |
---|
comment:26 by , 9 years ago
Replying to scottmc:
ok. let's keep the ticket open until I get the gcc4 and x86_64 hpkg files added as well.
Replying to pulkomandy:
I think this is solved now?
hrev49286 x86_64 is still using old 3.01a07 revision, and still cannot detect the optical drives in either of my PC's. So, not solved yet.
comment:27 by , 9 years ago
All optical devices are now being detected on 64 bit builds with hrev49287. Problem solved. Thanks!
Will the 3.01a29 version of CDRTools be made available for 32 bit builds as well? Currently it is still using 3.01a25, which had some issues.
comment:28 by , 9 years ago
Tested CD disk burning with hrev49292 x86_gcc2 and x86_64.
x86_gcc2 (cdrecord version 3.01a25) - fail due to FIFO error (see attached cdrecord_session1)
x86_64 (cdrecord version 3.01a29) - successful!
32 bit Haiku needs to be updated to working cdrtools revision 3.01a29.
by , 9 years ago
Attachment: | CDRecord_session1 added |
---|
comment:29 by , 9 years ago
Just a question: Is there any reason why 32 bit Haiku builds are still using the broken cdrtools (3.01a25), while 64 bit has already been updated to a working version (3.01a29)?
comment:30 by , 9 years ago
Probably because no one bothered to update the package. doing so is a very boring task, which is why we have waddlesplash working in a paid contract to automate it. Once that is done, submitting a pull request to haikuports will be the only thing needed to get an updated package, and the developers won't have to worry about rebuilding packages for all 3 architectures and upload them, each time a bug pops in.
comment:31 by , 9 years ago
CDRTools in 32 bit versions has been broken for nearly 2 years now. Trying to test any of the CD recording apps such as BurnItNow is pointless until this is fixed first. If it is too boring for the developers to upgrade this package and others like it, then imagine the frustration of the end user who has no working apps.
comment:32 by , 9 years ago
If it is too boring for the developers to upgrade this package and others like it, then imagine the frustration of the end user who has no working apps.
See #10893 -- this is the whole point of the contract I'm currently on. :p
comment:33 by , 9 years ago
I updated the cdrtools package for gcc2 with hrev49443. gcc4 fails to build. 64bit complains that the declared files "settings/cdrecord" and "settings/rscsi" aren't included in the package. When building for gcc2 there is no such policy error...
comment:34 by , 9 years ago
Humdinger, 64 bit builds already had the updated (working) 3.01a29 Cdrtools, so the 3.01a30 package is not really necessary now. Only the 32 bit package was broken in current nightlies. Thanks for the update.
comment:36 by , 9 years ago
I won't be able to test this until I get home from work later tonight. I'll let you know as soon as I have finished testing.
comment:37 by , 9 years ago
CDrecord appears to be working again. This ticket can be closed. Blanking CDRW brings up an error message which indicates a possible hardware compatability issue. Where are these kind of non-Haiku related reports to be sent?
comment:38 by , 9 years ago
Assuming that behavior can be duplicated on Linux, i.e. can definitely be shown to not be a quirk of the Haiku port, that would entail filing a bug with the cdrtools project, which is maintained at http://sourceforge.net/projects/cdrtools/ as far as I'm aware.
comment:39 by , 9 years ago
Ok. Maybe keep the ticket open until I can determine whether it is a hardware issue or not. I have 3 additional DVD burners and 2 more PC's I can test with.
comment:40 by , 9 years ago
This ticket can be closed for the error described in the ticket. Blanking of RW media still is an issue. I'll open another ticket for that.
comment:41 by , 9 years ago
Blocked By: | 11970 removed |
---|
comment:42 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
I have built cdrtools-3.01~a08 and this new compiled version is able to see my burner device.