Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #165403 > unrolled thread

blu ray burning with samsung se506cb in debian jessie

Back to article view | Back to linux.debian.user

Contents

  blu ray burning with samsung se506cb in debian jessie Jan Gregor <gregor.jan@gmail.com> - 2016-03-15 08:00 +0100
    Re: blu ray burning with samsung se506cb in debian jessie "Thomas Schmitt" <scdbackup@gmx.net> - 2016-03-15 08:30 +0100
      Re: blu ray burning with samsung se506cb in debian jessie Jan Gregor <gregor.jan@gmail.com> - 2016-03-15 10:40 +0100
        Re: blu ray burning with samsung se506cb in debian jessie "Thomas Schmitt" <scdbackup@gmx.net> - 2016-03-15 11:40 +0100
    Re: blu ray burning with samsung se506cb in debian jessie Dominique Dumont <dod@debian.org> - 2016-03-15 08:40 +0100
      Re: blu ray burning with samsung se506cb in debian jessie jdd <jdd@dodin.org> - 2016-03-15 09:10 +0100
        Re: blu ray burning with samsung se506cb in debian jessie "Thomas Schmitt" <scdbackup@gmx.net> - 2016-03-15 09:30 +0100
      Re: blu ray burning with samsung se506cb in debian jessie Jan Gregor <gregor.jan@gmail.com> - 2016-03-15 10:50 +0100
        Re: blu ray burning with samsung se506cb in debian jessie jdd <jdd@dodin.org> - 2016-03-15 13:20 +0100
        Re: blu ray burning with samsung se506cb in debian jessie Dominique Dumont <dod@debian.org> - 2016-03-15 20:00 +0100
          Re: blu ray burning with samsung se506cb in debian jessie "Thomas Schmitt" <scdbackup@gmx.net> - 2016-03-15 20:50 +0100
            Re: blu ray burning with samsung se506cb in debian jessie Jan Gregor <gregor.jan@gmail.com> - 2016-03-18 14:00 +0100
              Re: blu ray burning with samsung se506cb in debian jessie "Thomas Schmitt" <scdbackup@gmx.net> - 2016-03-18 15:10 +0100

#165403 — blu ray burning with samsung se506cb in debian jessie

[Multipart message — attachments visible in raw view] — view raw

Hello,

  does anybody uses this burner in debian jessie ?  So far I was succesful
with burning to bd-re medium and failed with bd-r medium with i/o error
after start of burning - probably caused by default 6x speed compared to 1x
speed of bd-re but the drive should have buffer underrun protection.

For burning I used growisofs with -Z /dev/sr0=image argument only. Can you
recommend arguments to growisofs or some configuration to the drive to
minimize number of wasted bd-r media ?

Thanks,
Jan

[toc] | [next] | [standalone]

#165405

Hi,

Jan Gregor wrote:
> does anybody uses this burner in debian jessie ?

I don't have this burner, but i am interested in such problems in general.


> So far I was succesful with burning to bd-re medium

This means its blue laser lens is not blind.

> failed with bd-r medium with i/o error after start of burning

Did it show three hex numbers in "SK=.../ASC=.../ACQ=..." ?
If so, please share these numbers. They are the SCSI error code
received from the burner.

> the drive should have buffer underrun protection.

Buffer underrun is not an issue with BD-R. Only with CD-R[W] and DVD-R[W].

> Can you recommend arguments to growisofs or some configuration to the
> drive to minimize number of wasted bd-r media ?

You may reduce speed by option.
  -speed=1

But depending on the SCSI error code your problem might have other
reasons.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#165413

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 15, 2016 at 8:25 AM Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> Jan Gregor wrote:
> > does anybody uses this burner in debian jessie ?
>
> I don't have this burner, but i am interested in such problems in general.
>
>
> > So far I was succesful with burning to bd-re medium
>
> This means its blue laser lens is not blind.
>
> > failed with bd-r medium with i/o error after start of burning
>
> Did it show three hex numbers in "SK=.../ASC=.../ACQ=..." ?
> If so, please share these numbers. They are the SCSI error code
> received from the burner.
>

I think no, but I will check it and in future I'll care of it.
After message about formatting of the media I saw about 10 lines of write
buffer with very high estimate followed by error message
WRITE@LBA Input/output error


> > the drive should have buffer underrun protection.
>
> Buffer underrun is not an issue with BD-R. Only with CD-R[W] and DVD-R[W].
>

Well, I'm not sure. In my case is default write speed is 6x and my burner
uses USB2 port. I found some posts about recommended speed.


> > Can you recommend arguments to growisofs or some configuration to the
> > drive to minimize number of wasted bd-r media ?
>
> You may reduce speed by option.
>   -speed=1
>

I'll definitely check it.


>
> But depending on the SCSI error code your problem might have other
> reasons.
>
>
> Have a nice day :)
>
> Thomas
>
>

[toc] | [prev] | [next] | [standalone]

#165416

Hi,

Jan Gregor wrote:
> After message about formatting of the media I saw about 10 lines of write
> buffer with very high estimate followed by error message 
> WRITE@LBA Input/output error  

So for now the best guess is that the drive does not like the medium.


> > Buffer underrun is not an issue with BD-R.

> Well, I'm not sure. In my case is default write speed is 6x and my burner
> uses USB2 port. I found some posts about recommended speed. 

The specs say that DVD+R and BD-R can have more than one track
open for writing. This implies that the tracks can stand it
when writing pauses on the one track, while the other track is
being written.

> > > the drive should have buffer underrun protection.

They all have since years. But it gets into effect only if the
burn program sends a data structure called "mode page 05".
This is appropriate only for CD and DVD-. The specs say that
the drive shall ignore it with any other media type.
(They obviously obey, because last time i looked into the -V
 output of cdrecord, it still sent mode page 05 to DVD+RW.)

If the BD-R is formatted and checkreading is not disabled (which
growisofs does not do) then the drive will pause with writing after
about half of a drive buffer (e.g. 1 MB) and checkread that piece
of freshly written data.
This reduces effective speed to less than half nominal speed.
Especially it would not work if buffer underruns would be an issue.


> my burner uses USB2 port.

This outrules the USB 3 timeout problems, which seem to happen with
some drives and some kernels.
Other operating system spacific problems are not known to me currently.


> >  -speed=1
> I'll definitely check it.

If it helps, then it is not about a buffer underrun but rather
about the physical quality of the laser and the media dye.

(I am still curious why Dominque reduces his drive's speed regularly.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#165407

On Tuesday 15 March 2016 06:56:11 Jan Gregor wrote:
> For burning I used growisofs with -Z /dev/sr0=image argument only. Can you
> recommend arguments to growisofs or some configuration to the drive to
> minimize number of wasted bd-r media ?

try with -speed=1

This option is the only way for me to burn reliably with my old BR drive (~ 5 
years)

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

[toc] | [prev] | [next] | [standalone]

#165410

Le 15/03/2016 08:25, Dominique Dumont a écrit :

> This option is the only way for me to burn reliably with my old BR drive (~ 5
> years)

you may also try the original cdrecord by joerg 
(http://cdrtools.sourceforge.net/private/cdrecord.html) which is *much* 
faster on BD write, but I don't know how to install it on debian

jdd

[toc] | [prev] | [next] | [standalone]

#165411

Hi,

jdd wrote:
> you may also try the original cdrecord by joerg
> which is *much* faster on BD write

The speed advantage on BD-R is because cdrecord does not format
the medium by default (as do my xorriso and cdrskin, too).

With growisofs you can achieve this behavior by option

  -use-the-force-luke=spare=none


> I don't know how to install it on debian

I recently had reason to make a cdrecord for an Ubuntu user to
demonstrate a bug fix.
(German language:
  https://forum.ubuntuusers.de/topic/k3b-brennt-keine-audio-cd-2/4/
)

The resulting binary is still online:

  https://media-cdn.ubuntu-de.org/forum/attachments/00/01/8001663-cdrecord-fubude-3.gz

Get it and do

  gunzip 8001663-cdrecord-fubude-3.gz
  mv 8001663-cdrecord-fubude-3 cdrecord-fubude-3
  chmod u+x cdrecord-fubude-3
  mv cdrecord-fubude-3 ...where it can be found by the shell...
  
I produced cdrecord by:

  wget http://sourceforge.net/projects/cdrtools/files/alpha/cdrtools-3.02a05.tar.gz/download
  tar xzf cdrtools-3.02a05.tar.gz
  cd cdrtools-3.02
  view README.compile
  make

Test whether you got a binary (maybe in a differnet directory than
.../x86_64-linux-cc/...):

  ./cdrecord/OBJ/x86_64-linux-cc/cdrecord -version


Again, put the file ./cdrecord/OBJ/x86_64-linux-cc/cdrecord to
a place where the shell can find it.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#165414

[Multipart message — attachments visible in raw view] — view raw

Did you experienced same also on other OS or you can write reliably at
higher speed outside linux ?

Thanks,
Jan

On Tue, Mar 15, 2016 at 8:31 AM Dominique Dumont <dod@debian.org> wrote:

> On Tuesday 15 March 2016 06:56:11 Jan Gregor wrote:
> > For burning I used growisofs with -Z /dev/sr0=image argument only. Can
> you
> > recommend arguments to growisofs or some configuration to the drive to
> > minimize number of wasted bd-r media ?
>
> try with -speed=1
>
> This option is the only way for me to burn reliably with my old BR drive
> (~ 5
> years)
>
> HTH
>
> --
>  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
> http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org
>
>

[toc] | [prev] | [next] | [standalone]

#165417

Le 15/03/2016 10:43, Jan Gregor a écrit :
> Did you experienced same also on other OS or you can write reliably at
> higher speed outside linux ?

the standard cdrecord I use (but not on debian) checks the speed and low 
it if necessary - I use usb blu-ray writer for 5 years now

jdd

[toc] | [prev] | [next] | [standalone]

#165428

On Tuesday 15 March 2016 09:43:24 Jan Gregor wrote:
> Did you experienced same also on other OS or you can write reliably at
> higher speed outside linux ?

I've not tried outside of Debian/unstable. 

All the best
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

[toc] | [prev] | [next] | [standalone]

#165434

Hi,

Dominique Dumont wrote:
> # problem with plextor writer: io error on last files on DL DVD

To my own experience, DVD+R DL are the first media to fail when the
DVD laser begins to go blind. Unformatted DVD-RW are next.

> # note: plextor's slowest speed on Prodye ix 4x, which is too fast
> #       only pionneer and LG report a 2.5 writing speed

  xorriso -outdev /dev/srX -list_speeds

shows what the drive is offering for the loaded medium.
The results differ from drive to drive.


> I had similiar issue on BR, but I don't remember the error message.
> I'll have to sacrifice a disk if you need more details.

It would be for the sake of science. :))

For example make a backup of your most prescious data:

  xorriso -abort_on FATAL \
          -for_backup -disk_dev_ino on \
          -assert_volid 'BACKUP_*' \
          -dev /dev/sr0 \
          -volid BACKUP_"$(date '+%Y_%m_%d_%H%M%S')" \
          -not_leaf '*.o' -not_leaf '*.swp' \
          -update_r /directory/on/hard/disk /path/in/ISO \
          ... \
          ... more -update_r commands for more directory trees ... \
          ... \
          -stream_recording on \
          -commit -toc -check_md5 FAILURE -- -eject all

This run will write the backup at high speed and checkread the
data when everything is written. So failure should become obvious.
(Note: The sequence of arguments matters much here.)

If you put this xorriso run into a script and if the BD-R has space left
after a successful first burn run, then you may repeat the script run
some time later to update the BD-R by the changed file content and a
new directory tree.
So hopefully the medium is not totally wasted.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#165571

[Multipart message — attachments visible in raw view] — view raw

Hello,

  I tried to burn data to rest of  the blu ray disc, that failed and use
speed=2.
At first it failed with original 25GB image, it was solved by excluding
some files and burn only 24GB.

Executing 'builtin_dd if=mybluray-disc.udf of=/dev/sr0 obs=32k seek=0'

:-( /dev/sr0: 12088320 blocks are free, 12207031 to be written!

 Output with speed=2 was at first same as in my original try with specified
speed, zero data written, zero speed unknown remaining time
 ... but after some seconds the burner started to write the image. Until
8GB the speed varied between 1.0 and 1.5x, between 8GB and 24GB
it significantly dropped so average speed was 0.2x. Next try with new media
and maybe different speed is needed to deduce some conclusion.

Executing 'builtin_dd if=mybluray-disc2.udf of=/dev/sr0 obs=32k seek=0'
/dev/sr0: "Current Write Speed" is 2.0x4390KBps.
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
          0/24000000000 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU   0.0%
    1769472/24000000000 ( 0.0%) @0.1x, remaining 10397:48 RBU 100.0% UBU  17.2%
    1769472/24000000000 ( 0.0%) @0.0x, remaining 11301:58 RBU 100.0% UBU 100.0%
    1769472/24000000000 ( 0.0%) @0.0x, remaining 11980:05 RBU 100.0% UBU 100.0%
    2031616/24000000000 ( 0.0%) @0.0x, remaining 11024:46 RBU 100.0% UBU 100.0%
    2031616/24000000000 ( 0.0%) @0.0x, remaining 11812:15 RBU 100.0% UBU 100.0%
    2097152/24000000000 ( 0.0%) @0.0x, remaining 12015:14 RBU 100.0% UBU 100.0%
   14286848/24000000000 ( 0.1%) @0.8x, remaining 1846:45 RBU 100.0% UBU  35.9%
   30539776/24000000000 ( 0.1%) @1.1x, remaining 915:40 RBU 100.0% UBU  42.2%
   46792704/24000000000 ( 0.2%) @1.1x, remaining 622:48 RBU 100.0% UBU  51.6%

[toc] | [prev] | [next] | [standalone]

#165578

Hi,

Jan Gregor wrote:
> Until 8GB the speed varied between 1.0 and 1.5x, between 8GB and 24GB
> it significantly dropped so average speed was 0.2x.

This is a typical effect of checkreading while writing. 1.0x with 2x
nominal speed indicates a good relationship between drive and medium.
0.2x is rather bad.

Checkreading is normally done if the BD-R is formatted. growisofs
does not offer to disable checkreading, but it offers to leave out
automatic formatting of unused BD-R if you add option:

  -use-the-force-luke=spare=none 

This will also increase the media capacity to 12219392 blocks.

You should of course checkread the resulting medium by own means.
("should" meant as obtrusive advise)


Have a nice day :)

Thomas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web