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)

CDRecord_session1 (3.0 KB ) - added by vidrep 9 years ago.

Download all attachments as: .zip

Change History (43)

comment:1 by Giova84, 11 years ago

I have built cdrtools-3.01~a08 and this new compiled version is able to see my burner device.

comment:2 by scottmc, 11 years ago

Owner: changed from nobody to scottmc
Status: newassigned

comment:5 by Giova84, 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 scottmc, 10 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 Giova84, 10 years ago

All fine with a18 version. So can you officially replace, on Haiku, the current a07 with a18?

comment:8 by scottmc, 10 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 Giova84, 10 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.

comment:10 by scottmc, 10 years ago

ok. let's keep the ticket open until I get the gcc4 and x86_64 hpkg files added as well.

comment:11 by scottmc, 9 years ago

Is this working for you now?

comment:12 by Giova84, 9 years ago

Hi, as I've said on comment:7 and in comment:9 with a18 version (which is now present by default) all is fine.

comment:13 by scottmc, 9 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 scottmc, 9 years ago

Summary: With Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a18 for all buildsWith Haiku PM, cdrecord is no longer able to see my device. Need to update cdrecord to 3.01a25 (or newer)

comment:15 by vidrep, 9 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:16 by scottmc, 9 years ago

Blocking: 11257 added

(In #11257) Related to #10099. cdrecord needs to be updated, and that will probably fix this issue.

Last edited 9 years ago by pulkomandy (previous) (diff)

comment:17 by pulkomandy, 9 years ago

Milestone: R1Unscheduled

The gcc2 image is fine now, so moving out of R1 milestone.

comment:18 by vidrep, 9 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.

comment:19 by anevilyak, 9 years ago

That's pretty much to be expected, as cdrecord on x86_64 is still the old version (3.01a07).

comment:20 by vidrep, 9 years ago

Last edited 9 years ago by vidrep (previous) (diff)

in reply to:  20 comment:21 by vidrep, 9 years ago

Replying to vidrep:

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 application wasn't broken before PM.

Version 0, edited 9 years ago by vidrep (next)

in reply to:  19 comment:22 by vidrep, 9 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 pulkomandy, 9 years ago

Owner: changed from scottmc to pulkomandy
Status: assignedin-progress

comment:24 by pulkomandy, 9 years ago

Blocked By: 11970 added

comment:25 by pulkomandy, 9 years ago

I think this is solved now?

in reply to:  10 comment:26 by vidrep, 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 vidrep, 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 vidrep, 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 vidrep, 9 years ago

Attachment: CDRecord_session1 added

comment:29 by vidrep, 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 pulkomandy, 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 vidrep, 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 waddlesplash, 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 humdinger, 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 vidrep, 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:35 by pulkomandy, 9 years ago

Can we close this then?

comment:36 by vidrep, 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 vidrep, 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 anevilyak, 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 vidrep, 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 vidrep, 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 diver, 9 years ago

Blocked By: 11970 removed

comment:42 by diver, 9 years ago

Resolution: fixed
Status: in-progressclosed
Note: See TracTickets for help on using tickets.