Talk:Optical disc drive

From ArchWiki
Jump to navigation Jump to search

Command line order

I don't know what ArchLinux is about, but this page was a very nice reference for growisofs. However, according to the man page for growisofs, all options for growisofs should come before the -[Z|M] /dev/dvd-device. The synopsis is:

growisofs [-dry-run] [-dvd-compat] [-overburn] [-speed=1] -[Z|M] /dev/dvd <mkisofs-options>

so this line:

growisofs -Z /dev/cdrw -v -l -dry-run -iso-level 3 -R -J -speed=2 -joliet-long -graft-points /Magazines/=/home/citral/books/mags/

should rather be:

growisofs -dry-run -speed=2 -Z /dev/cdrw -v -l -iso-level 3 -R -J -joliet-long -graft-points /Magazines/=/home/citral/books/mags/

since -dry-run and -speed=N are options for growisofs and not mkisofs. I'm guessing growisofs figures that out for itself though, but for the sake of consistency, I feel the order should be changed... - (Reep 15:24, 4 April 2006 (EDT))

Sounds very logical to me. Since it is your discovery, would you mind updating the page yourself? --citral 14:24, 16 July 2006 (PDT)
The disputed growisofs command fell victim to the recent overhaul. The new growisofs command examples follow the sequence of man growisofs.
Nevertheless it has to be noted that the source code of growisofs does not indicate the need for putting -Z resp. -M exactly between growisofs-specific options and mkisofs options. (See dvd+rw-tools-7.1, growisofs.c, line 2990 ff.)
Scdbackup (talk) 11:51, 9 September 2013 (UTC)

DVD Ripping - mplayer -dumpstream

hey, I normaly just do

mplayer -dumpstream

and write it to a .vob file.

So the actual command could look like:

mplayer dvd://1 -v -dumpstream -dumpfile film.vob

Of course I get really big files this way. (3-8 gigabyte) But I think it's definitely the best quality, isn't it? And you can easily compress the vob-file anyway later if you want to.

I don't really have much knowledge about mplayer and video in general, so I didn't just write it in the article. I only adopted it from [1] (german language)

If anyone knows a better method (for example make mplayer read the dvd more carefully, if quality matters more than time) please write.

--Advocatusdiaboli 15:40, 10 November 2009 (EST)


Maybe some of these links have useful info? [2] [3] [4]

special burning options ?

Have think about burning following CD :

-bootable CD 
-contains audio track ( for CD player ) , any position is OK

Is such CD ( technically ) possible to burn ?

Burning files/directories throught genisoimage

make the .iso file:

# genisoimage -r -J -o cd_image.iso /directory

The -r and -J ensures long file names work for Unix (using Rock Ridge) and Windows (using Joliet extensions) respectively.

This has been taken into respect by the recent overhaul. - Scdbackup (talk) 11:55, 9 September 2013 (UTC)

A big merge

This page is the result of the merger of pages:

A one page to describe how to use an optical disc drive: CD burning; burning, ripping and playing DVD, inherent troubleshooting.

For all wiki's translators:, simple read the "history" tab for how to merge all page in your language. For more detail see Veleno (talk) 15:31, 22 July 2013 (UTC)

How to contribute as upstream developer ?

Being the developer of libburn i see that you are consolidating the knowledge about CD, DVD, and BD. Now i feel the urge to propose some corrections.

Would it be welcome if i make substantial changes, or would it be better to leave the wiki work to a person who is not involved in the competing burn software for archlinux ? (I have no experience with this wiki software. Beware.)

What i would change:

  1. Clean out burn war rethorics (mainly cdrkit vs. cdrtools)
  2. Move ISO 9660 stuff before burning stuff
  3. Add my own packages libburn, libisofs, libisoburn to the list
  4. Unify the command names used in examples
  5. Clarify some technical facts

I have a more detailed list of change proposals. 150 lines. Shall i post it here ? Scdbackup (talk) 12:48, 26 July 2013 (UTC)

Do a bit of clarity between cdrkit and cdrtools would be a pleasant thing. As well as any technical clarifications. At present I see that your packages are only used by Xfburn front-end, and from Brasero as a alternative back-end (on Arch Linux). Mainly others use a combination cdrkit/dvd+rw-tools. I'm ignorant on the subject, but if you want to clarify everything, it must be done in a simple and explanatory. In practice: "there are three ways to burn cd/dvd on Arch linux, using packages cdrkit, cdrtools or libburnia." Explain the use of all in a comprehensive way (in the case should be reviewed throughout the page) but, consider that the main front-end using the packages described above. It is interesting to your proposal, but I do not have the technical means to be able to help in this regard.Veleno (talk) 15:39, 26 July 2013 (UTC)
I take your answer as encouragement to post the long list of proposals.
(I am not doing well with wiki formatting here. Some experienced polishing seems needed.)
Install CD-burning utilities
  • I would clean out the burn war rethorics, and rather list the known free programs and their packages in alphabetic order. Further i would put the description of dvd+rw-tools here and change the title to: "Install fundamental burning utilities for CD, DVD, and BD". I would explain that from the following lists one needs at least one program for creating ISO 9660 filesystem images and one program for burning data to the desired media type.
  • The list of known free programs for ISO 9660 creation:
genisoimage from package cdrkit
isomaster from package isomaster (with gtk2 GUI)
mkisofs from package cdrtools
xorriso from package libisoburn
xorrisofs from package libisoburn
  • The list of known free programs for CD, DVD, BD burning:
cdrdao from package cdrdao (CD only, .cue files only)
cdrecord from package cdrtools
cdrskin from package libburn
growisofs from package dvd+rw-tools (DVD and BD only)
wodim from package cdrkit (CD only, DVD deprecated)
xorriso from package libisoburn (no audio CD)
xorrecord from package libisoburn (no audio CD)
  • The free GUI programs for CD, DVD, BD burning depend on at least one of the above packages.
Modifying the CD-RW
  • I would mention that cdrecord, wodim, cdrskin all support the shown options for CD manipulation, wheras cdrdao has its own option set.
  • I would clean out the traces of cdrtools/cdrkit quarrel. If it is deemed necessary at all, then a general advise would be appropriate, to try one of the listed alternatives in case of trouble.
  • (One could open a new paragraph about multi-session. xorriso would look very good there. :))
Making an ISO image from an existing CD
This part should come before burning CDs (but after creating ISO images from disk files).
  • I would use dd bs=2048 rather than readcd or readom, which may or may not be good for reading non-data CD. (The statement that dd and cat "provide no error checking" is wrong, because you do get an i/o error if a block is unreadable or non-data. dd works nicely on auto-mounted CD. So the "Note:" box about umount can be shifted to the topic CD burning.)
Making an ISO image from existing files on hard disk
This part should come before burning CDs (and before extracting ISO images from CD).
  • I would mention that mkisofs, genisoimage, xorrisofs all support the shown options for ISO image creation. (The longish example with growisofs should be shown here. Without the growisofs aspects.)
DVD burning
  • I would widen the chapter to "DVD and BD".
  • I would state that cdrdao and wodim are not suitable for DVD or BD. (Although wodim works with some DVD types, it is not worth the hassle.)
  • The packages cdrtools, dvd+rw-tools, and libburn+libisofs+libisoburn are suitable for DVD and BD burning. (Although i think that cdrecord does various DVD things wrong.)
  • The already mentioned programs for producing ISO 9660 filesystems are suitable for DVD and BD, too. The standards for video on DVD and BD demand UDF filesystems. genisoimage and mkisofs can produce the format prescribed for DVD. (I am clueless about how to produce a UDF 2.50 for BD. Typically only the oldest players do not read plain ISO 9660. So possibly nobody cares about the specs.)
  • growisofs has a bug with BD-R. One can work around it by formatting the BD-R with dvd+rw-format before giving it to growisofs, or by using growisofs option -use-the-force-luke=spare:none if one does not want formatting and slow Defect Management.
  • ( archlinux should consider to repair the known growisofs BD-R bug by applying the single-line patch proposed in )
  • I would remove the "Note:" about dvdrtools and completeness of cdrtools. (dvdrtools is not capable of all DVD types. I deem growisofs and libburn better suited for DVD than cdrecord. So there is reason to install one of these two.)
  • I would add program xfburn to the "Tip:" about k3b and brasero. (And maybe xorriso-tcltk.)
  • The first two growisofs examples run a mkisofs compatible helper program. Default is "mkisofs", but one can switch to other program names by executing before the growisofs run: export MKISOFS="genisoimage" or export MKISOFS="xorrisofs" . (xorrisofs cannot produce UDF images. UDF is not required by the existing -dvd-video example, but possibly should be.)
  • For image extraction from DVD and BD, i would propose dd bs=2048, rather than readcd or readom.
  • The explanation of mkisofs options with the fifth growisofs example should be merged with the paragraph "Making an ISO image from existing files on hard disk"
  • Rather than to "Note: growisofs is basically just a front-end to mkisofs" one should state that nearly all mkisofs options may be used with a growisofs run.(-o is not allowed and -C should only be used if one wants to override the expert opinion of growisofs about the state of the DVD.)
  • cdrecord, cdrskin, and xorrecord burn DVD and BD with about the same options as with CD burning. xorriso has its own command set. I would translate the growisofs examples into additional examples for cdrecord and for xorriso. (Actually the growisofs -M example should be expanded to a paragraph about multi-session.)
Re-writable DVDs
  • I would not mention explicit formatting for DVD+RW (or BD-RE), because all burn programs apply default formatting if needed.
  • I would rather mention that DVD-RW can be used unformatted which makes them very similar to DVD-R. But unformatted written DVD-RW need to be blanked before re-use. Fast blanking deprives them of their multi-session capability.
  • Full blanking lasts long. Better is to format DVD-RW, so that they behave much like DVD+RW: dvd+rw-format -force /dev/cdrw or cdrskin -v dev=/dev/cdrw blank=format_overwrite or xorriso -outdev /dev/cdrw -format as_needed
BD Defect Management
  • This new paragraph would explain why BD-RE and formatted BD-R are written much slower than their nominal speed. It is due to checkreading and bad block replacement, which can be disabled to achieve full nominal speed.
Scdbackup (talk) 21:52, 26 July 2013 (UTC)
As an example of how i would implement my proposals, i have now added an overview of available burn tools and a note about the workaround for the BD-R bug of growisofs. (Sorry for not giving an appropriate summary with the change of 09:46, 27 July 2013.) I hope not to have deleted any valuable information from that section. Please confirm that i shall go on. Scdbackup (talk) 09:59, 27 July 2013 (UTC)
Please do not make too many changes in the same post (except for corrections of form and syntax), this could possibly create problems for those who follow the message. This is a very big change! I can not say if everything is correct, but I can express my thoughts. I believe that greater clarity and cleanliness can be good, currently there are six main sections:
  1. CD burning
  2. DVD burning
  3. DVD playing
  4. Burning CD/DVD with a GUI
  5. DVD ripping
  6. Troubleshooting
This layout is derived from the combination of multiple pages (see discussion above), and there is no reason to improve their formatting. Now this page is aptly titled "Optical Disc Drive" because it contains generically any existing optical drive, past and future. (cd, dvd, bluray disc), then it is possible to recast the sections on the basis of this principle. But there is a feature to be taken into account, namely that the first part describes the tools you need and how to use the command line. An exception is the chapter "Burning CD/DVD with a GUI" as this comes from another page List of Applications/Multimedia, and I think it should remain the same (you can possibly change the title). . For example:
  • Create a new primary section Install burning utilities (which contains all the tools to burn CD/DVD/BD, merge #CD burning and #DVD burning)
  • Create a new secondary section ODD Playing (or similar), which includes all references to playing CD/DVD/BD (to replace #DVD playing)
  • Create a new thirdy section ODD ripping (or similar), which includes all references to ripping CD/DVD/BD (to replace #DVD ripping)
  • Preserve #Burning CD/DVD with a GUI (this must be a list of GUI), enventually changed the title in best ones, example Graphics Interface
  • Preserve #Troubleshooting, to include all trouble in a single sections.
These could be major changes sensible: E for everyone decide the content. Each operation must be done patiently, without changing everything at once. What do you think?Veleno (talk) 10:32, 27 July 2013 (UTC)
Sorry for the size of my proposal and the perky change of the wiki. The latter should be harmless because it just lists the known free programs and leads the user to those programs which are mentioned in the following sections.
It is desirable to unify the description of burning of CD, DVD, BD. The existing sections overlap by us other programmers intruding into the realm of growisofs. :))
Ripping of CD, DVD, and BD is mostly out of my scope. But i know that the challenges with CD differ significantly from those with DVD and BD.
I have no user experience with the GUI programs. Mostly i know them from troubleshooting their backend programs.
The troubleshooting section is currently totally missing my kind of trouble: write errors, speed problems, limitations of media types, ... Is there a bug database where to fish for such reports ?
On a side note: Why does the query not find ? How to create a link in the wiki ?
Scdbackup (talk) 12:00, 27 July 2013 (UTC)
Wow sorry for delaying my answer but it took me ages to go through all this thread :) Welcome to the ArchWiki! Let's begin:
>>Would it be welcome if i make substantial changes, or would it be better to leave the wiki work to a person who is not involved in the competing burn software for archlinux ?
Yes it would be more than welcome, as long as you split your changes in several edits, not only a single (nor just a few) big one. Each edit must be accompanied by a proper Edit Summary, see also Help:Style#Edit summary.
>>(I have no experience with this wiki software. Beware.)
I think you're doing well until now, wiki markup is designed to be easy to use; you may find some useful guidelines in Help:Editing and related.
Regarding the changes that you want to apply to this article, I think that overall they are going to be a huge improvement: you show a high degree of competence on the subject (obviously, being the developer of an optical media management library), so I think you can do a very good job. I can't really judge the correctness of the information you're going to add, but this is a wiki, so as long as you write in an objective, unbiased way, you can go and share your knowledge with the community, which will be thankful for that ;)
>>The troubleshooting section is currently totally missing my kind of trouble: write errors, speed problems, limitations of media types, ... Is there a bug database where to fish for such reports ?
Are you talking about upstream bugs? I don't think so because being a developer you know that they must be reported upstream ^^ If they're bugs specific to the Arch versions of the affected packages, you should use Otherwise if they are just issues that must be solved on a per-user basis, just use the Troubleshooting section of this article.
>>On a side note: Why does the query not find ? How to create a link in the wiki ?
That query doesn't work because isomasterAUR is a package in the AUR, not in the official repositories: if you're not familiar with the Arch Linux repository system, you can start reading those two articles. In order to link to packages, you should use Template:Pkg or Template:AUR (follow those links for usage guidelines), e.g. isomasterAUR. About links, see Help:Editing#Links.
-- Kynikos (talk) 05:42, 28 July 2013 (UTC)
hi, kinikos. The user has raised issues to improve the entire section on the creation of images and burning. This leads to a big change of the whole part for CD burnig and DVD burning, which no longer need to exist separated, and therefore is a complete review of all that section. It's a big change, and I do not have much technical expertise to check everything on Arch Linux system. I have now done via email to work on his page to a draft (, as the changes are radical. He is doing a magnificent job, the problem and how to apply it step by step in the wiki. As you know this type of job, extra-translation, i are not yet accustomed. If you need you can also contact me via email.Veleno (talk) 07:13, 28 July 2013 (UTC)
We are going to apply the changes discussed here. We will carry out a fusion of the first two chapters CD burning and DVD burning in one section called Burning (at maximum you could then rename it to ODD burning, you accept tips). Then the section Burning CD/DVD with a GUI will be included in the new section as a sub-section. Veleno (talk) 10:10, 30 July 2013 (UTC)
I have now transfered the first three sections. Please have a look at my Summary notes, whether they are ok. Ping me by email when i shall go on.
I plan to first transfer all new sections, overwriting those sections which match 1:1. The big section "DVD burning" will stay until all replacements are done. Then it will be obsolete and i will delete it.
Finally i want to re-arrange the new options to the sequence that is shown in my template.
Correct me if this plan is not good.
Scdbackup (talk) 11:35, 30 July 2013 (UTC)
Small change of plan: I will put the updated sections to the places where they finally shall end up. So the step about re-arranging them is not needed.
Scdbackup (talk) 12:59, 30 July 2013 (UTC)
As no opposition to this restructuring has been shown in this discussion since it was started, I'd say you can go on more liberally with your changes, without the need for introducing each of them here, as long as you keep accompanying your edits with proper edit Summaries (thank you for your diligence in doing it btw). -- Kynikos (talk) 15:16, 31 July 2013 (UTC)
I have now copied the new and updated sections into the wiki page.
Regrettably i messed up the change log at a few occasions:
  • 15:41, 31 July 2013 : I removed the wrong old section.
  • 15:52, 31 July 2013 : Removes the surviving old section of 15:41 but the summary should say "This should have been done *three* changes before"
  • 16:01, 31 July 2013 : Copied in the wrong new section.
  • 16:02, 31 July 2013 : Put the right new section to the wrong new place.
Is this bad enough to roll back and do it again ? Elsewise i would be done now.
Scdbackup (talk) 17:18, 31 July 2013 (UTC)
Eheh that's not bad at all, if only everybody documented all the changes like you've done... ;) -- Kynikos (talk) 13:51, 2 August 2013 (UTC)
About the upstream bugs: It is rare that a distro does not stockpile them in its own bug tracker. Me upstream usually googles to find them. (Of course package maintainers are invited to forward them.)
I want to thank you guys for the friendly and tolerant reception here. :))
Scdbackup (talk) 12:33, 30 July 2013 (UTC)
Arch Linux's official bug tracker is
Thank you for choosing to contribute to our wiki: your work will not only be useful to Arch users, but very likely to many users of other distributions, just like I can assume you are ^^
-- Kynikos (talk) 15:16, 31 July 2013 (UTC)
I am using a very old installation of a german distro. But as upstream i take care to stay neutral. I took Veleno's effort as opportunity to clean out urban legends which annoy me at least once per month.
Although today i got a report that cdrecord burns 6x BD-R faster than cdrskin (only at 4x). If i don't find a plausible explanation soon, then a new legend is born.
Scdbackup (talk) 15:33, 31 July 2013 (UTC)
I merged Burning CD/DVD/BD with a GUI into main section Burning, because the programs listed are used to burning.You are welcome in the arch wiki system and thanks for your technical support. Now this page is more cleaned and comprehensible. Remember to follow the page to stay informed of any changes. More developers should take your example and participate in the drafting of the main wiki (Debian. gentoo, slackware and Arch). Users do what they can, but a contribution of the developer can be enlightening in many cases (my personal thought). Again, thank you for choosing the Arch wiki and especially for your objectivity in proposing changes. (this is what you need for a documentation). In the future, feel free to prepare minor changes to the page (also concerning the other sections if you want), while substantial changes can always discuss here. I think this discussion is now complete.Veleno (talk) 10:27, 1 August 2013 (UTC)
Well then: Good bye for now. My mail address is in my user profile. Just in case there is need to clarify my statements or to describe new technical aspects (holo disc is still only at the far horizon).
Scdbackup (talk) 12:08, 1 August 2013 (UTC)
Bye bye, good job Scdbackup and Veleno! Closed. -- Kynikos (talk) 13:51, 2 August 2013 (UTC)

Verifying the burnt ISO image

Although the part with getting the md5sum of the previously created ISO image is quite obvious, the part with verifying the actual contents of the burnt disc seems to be somewhat inaccurate.

As soon as you have an alias like alias ls='ls-hF --color=auto' in your .profile, which could come in handy, the mentioned method for getting the block count is wrong:

$ blocks=$(expr $(ls -l isoimage.iso | awk '{print $5}') / 2048)

To make sure the calculated block count is valid for various user defined environments I would recommend the use of du -b:

$ blocks=$(expr $(du -b isoimage.iso | awk '{print $1}') / 2048)

That's what I just stumbled upon while trying to verify my burnt image.

I did not think of such aliases. My ~/.bashrc has: alias ls=ls
Your proposed du seems less prone to aliasing. Option -b is promised to be safe from pitfalls of sparse files. So i will put it into the wiki.
I wonder, though, whether stat(1) would be ubiquitous enough in archlinux:
$ blocks=$(expr $(stat -c '%s' isoimage.iso) / 2048)
Scdbackup (talk) 15:42, 29 August 2013 (UTC)
General thoughts:
alias is an arbitrary nasty problem with shell commands, of course. One cannot avoid it by alias ls=ls in a sub shell. man 1 bash is merciless in that aspect. Inquiring alias manually, unaliasing, executing size determination, re-aliasing ... is much too complicated. Should we bet on the existence of /bin/ls or /bin/du ? Any other ideas to surely prevent alias evaluation in an interactive command ? Scdbackup (talk) 16:09, 29 August 2013 (UTC)
Research: and promise the existence of /bin/ls . du is not listed there. So /bin/ls is currently my best bet to prevent alias evaluation.
I will wait a few days for objections or better ideas before changing the size command in the wiki page again. Please keep me from doing stupid things. Scdbackup (talk) 16:27, 29 August 2013 (UTC)
Of course there's no way to find a one-size-fits-all solution, maybe it's just worth to quickly mention the problem and propose the ls method as an alternative. I'd keep du as the main method because it's indeed less likely to be aliased. About its existence on all systems, this is the wiki for Arch Linux, whose basic, default installation includes coreutils, where both ls and du are provided. -- Kynikos (talk) 03:55, 31 August 2013 (UTC)
du -b seems quite robust. I tried to fool it by alias definitions like du='du --human-readable'. But an explict option -b overrides it properly. I still get the byte count. (Sequence matters. du -b --human-readable would show e.g. "590M"). My doubts about availability are rather about stat(1). It would be more appealing than du, because du's main job is to report disk usage, not the addressable byte size.
One of the problems i feared is demonstrated by :
dd if=/dev/zero bs=1 count=1 seek=10000000 of=/tmp/sparse_test ; ls -l /tmp/sparse_test ; du /tmp/sparse_test ; du -b /tmp/sparse_test
On my machine i get a file of adressable 10000001 bytes which uses only 12 disk blocks of 1 KB. But du -b does it right. So for now i postpone my plan to change the size determination once again. Scdbackup (talk) 09:30, 31 August 2013 (UTC)

Unfortunate re-introduction of cdrtools war aspects

I am unhappy with changes

03:52, 22 December 2013 Fleetwood

04:04, 22 December 2013 Fleetwood

which add "mkisofs" to explanations which apply to all three compatible programs and not specifically to mkisofs.

Firstly, this unnecessarily refers to unpleasant discussions about who is right with optical drives and software licenses.

Secondly, if "or mkisofs" gets sprinkled all over the text, then i would feel discriminated, if it would not become "or mkisofs or xorrisofs". (I am the developer of the latter.)

How should i proceed ? Is there a way to contact Fleetwood about this issue ? We seem to have technical interests in common.

Scdbackup (talk) 16:39, 28 December 2013 (UTC)

You can try to send him an email, but I think you should see this report first: ArchWiki_talk:Reports#cdrtools_page.
I'm not acquainted with any of these tools, but I have the impression that the previous wording was better - especially with regard to the example commands.
-- Lahwaacz (talk) 17:50, 28 December 2013 (UTC)
Ahum ... so my gut feeling was right: Beginning quarrel. The next traditional step of escalation would be hostile editing, accusation, counter-accusation, and finally mutual declaration of being clueless.
Reading the diff since my last visit:
i would say that the larger changes are not better or worse than what was stated before. No false claims. Just more words.
But i uphold my warning that the two mentioned changesets begin to revert my efforts of last summer. See above:
Was Fleetwood already contacted about this issue ?
Scdbackup (talk) 19:08, 28 December 2013 (UTC)
I did not try to contact him except for several posts on talk pages. And don't worry, your effort will certainly not come in vain ;)
Perhaps this "war" thing is the reason why his edits were not accepted on Wikipedia? This quarrel you described might have happened there before, and their approach might be the best (relative to maintenance).
One more thing: the original questionable edits by Fleetwood (see [5]) were amended by Fengchao and Kynikos ([6], [7], [8] and [9]), but they were style changes only and are irrelevant to the real problem (perfect style is useless without good content).
-- Lahwaacz (talk) 20:41, 28 December 2013 (UTC)
I wrote a mail meanwhile, asking for consent to remove the newly introduced explicit mentionings of mkisofs.
The war thing is based on a longstanding feud between Joerg Schilling on one side and Linux kernel developers plus distro packers on the other side. Since then, discussions about optical drive burning and ISO 9660 production are synonyms for "flame war".
In 2006 it resulted in forking of Debian's cdrkit from Joerg's cdrtools. At the same time, i joined the libburnia project to beef up libburn to a competitive level. My main motivation is to free the topics from the eternal quarrel. (Still working on that :))
My plan for correcting the changes is to just remove the surplus occurences of mkisofs. I am not a native speaker of english, and also somewhat too much involved in the technical entrails. So Fleetwood's other changes might well be appropriate, language-wise. As said: technically they are not wrong.
Scdbackup (talk) 20:58, 28 December 2013 (UTC)
(Just adding that Fleetwood seems active on his User page, maybe a message in User talk:Fleetwood could be effective.) -- Kynikos (talk) 03:43, 29 December 2013 (UTC)