From cb8c23ed5a65904fd7066b9d13db6ab2c4a3ade6 Mon Sep 17 00:00:00 2001 From: Thomas Schmitt Date: Sun, 6 Dec 2009 07:32:38 +0000 Subject: [PATCH] Some clarifications about the GH22LS30 problem --- cdrskin/cdrskin_timestamp.h | 2 +- libburn/mmc.c | 19 +++++++++++++------ 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/cdrskin/cdrskin_timestamp.h b/cdrskin/cdrskin_timestamp.h index 82cbf40..6566549 100644 --- a/cdrskin/cdrskin_timestamp.h +++ b/cdrskin/cdrskin_timestamp.h @@ -1 +1 @@ -#define Cdrskin_timestamP "2009.12.05.143707" +#define Cdrskin_timestamP "2009.12.06.073404" diff --git a/libburn/mmc.c b/libburn/mmc.c index 1028b2c..7069acf 100644 --- a/libburn/mmc.c +++ b/libburn/mmc.c @@ -4069,12 +4069,19 @@ int mmc_read_disc_structure(struct burn_drive *d, msg, 0, 0); ret = 0; -/* LG GH22LS30 revision 1.00 returns for DVD-R an allocation - length of 4 (= 0 payload). A MS-Windows tool can inquire - media code "RITEKF1", though. - This macro causes a try to unconditionally read the desired - payload bytes. -#define Libburn_enforce_structure_code_0x0E 1 +/* ts A91205 + LG GH22LS30 revision 1.00 returns for DVD-R format + code 0x0E an allocation length of 4 (= 0 payload). + A MS-Windows tool can inquire media code "RITEKF1", + though. + This macro causes a try to unconditionally read the + desired payload bytes. The drive then returns 35 + bytes as requested and the media id is "RITEKF1". + Nevertheless this is not a generally usable gesture + because older Linux USB dislikes requests to fetch + more bytes than the drive will deliver. + + # define Libburn_enforce_structure_code_0x0E 1 */ #ifdef Libburn_enforce_structure_code_0x0E