When reading ’The Snowman’ DVD from 2004, I get this output:

jani@saegusa:DVD$ dvdbackup -i /dev/sr0 -M
libdvdread: Using libdvdcss version 1.2.12 for DVD access

libdvdread: Attempting to retrieve all CSS keys
libdvdread: This can take a _long_ time, please be patient

libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x0000015a
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_0.VOB at 0x000001c1
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x00023749
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_0.VOB at 0x000241f0
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_02_1.VOB at 0x0002423d
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_0.VOB at 0x00024f03
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_03_1.VOB at 0x00024f50
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_0.VOB at 0x00025d8f
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_04_1.VOB at 0x00025ddc
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_0.VOB at 0x000e2c65
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_05_1.VOB at 0x000e2cb2
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_0.VOB at 0x000eb4df
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_06_1.VOB at 0x000eb52c
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_0.VOB at 0x000f7617
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_07_1.VOB at 0x000f7664
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_0.VOB at 0x00128eb1
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_08_1.VOB at 0x00128efe
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_09_0.VOB at 0x001da296
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_09_1.VOB at 0x001da2e3
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_0.VOB at 0x001e3856
libdvdread: Elapsed time 0
libdvdread: Get key for /VIDEO_TS/VTS_10_1.VOB at 0x001e38a3
libdvdread: Elapsed time 0
libdvdread: Found 10 VTS’s
libdvdread: Elapsed time 0
*** Zero check failed in /build/buildd/libdvdread-4.2.0/src/ifo_read.c:904
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in /build/buildd/libdvdread-4.2.0/src/ifo_read.c:904
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in /build/buildd/libdvdread-4.2.0/src/ifo_read.c:904
for pgc->subp_control[i] = 0x00000001

This doesn’t prevent dvdbackup from finishing up, and the resulting copy looks to be fine (on cursory inspection). While dvdbackup is running, the issue also doesn’t cause an OOM as in Bug #377414. Still, I tested libdvdread4_4.2.0+20130428-0ubuntu0~bryce~precise1_amd64.deb from Bryce Harrington’s PPA [1], but it just slightly changed the ”Zero check failed” output:

*** Zero check failed in ifo_read.c:904
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in ifo_read.c:904
for pgc->subp_control[i] = 0x00000001
*** Zero check failed in ifo_read.c:904
for pgc->subp_control[i] = 0x00000001

This DVD is the only one I’ve come across manifesting this, and I’ve backed up some 40 DVDs so far on this same setup.

*[1] https://launchpad.net/~bryce/+archive/lp377414/+build/4542681

RH #851762 [1] and Gnome #649722 [2] also describe very similar, but not entirely identical issues.

*[1] https://bugzilla.redhat.com/show_bug.cgi?id=851762
*[2] https://bugzilla.gnome.org/show_bug.cgi?id=649722

Steps to reproduce:

1. Start Sound Juicer.
2. Insert a CD, one known not to have MusicBrainz data for it available.
3. Eject CD.
4. Insert same CD, or another CD with no MusicBrainz data for it.

What happens:
A dialog pops up saying ”Cannot access CD: Error while getting peer-to-peer dbus connection: The name :1.395 was not provided by any .service files” (the number varies). Data from CD TOC isn’t filled into Sound Juicer’s main interface.

What I expect to happen:
No dialogs to pop up, data from CD TOC read into Sound Juicer’s main interface just as it was after step #2.

Workaround:
After step #4, shut down Sound Juicer and then start it again. You’ll have one working read, and again failure on successive reads.

Other info:
Bug #977335 is similar, but without the MusicBrainz connection. I’m unable to reproduce #977335 with CDs that do have MusicBrainz data available for them.

Sebastien, I think this may be related to the patch applied to fix Bug #1085320: the Gnome folks have since reverted (at least parts of) it (see Gnome bug 688808 [1]) because it caused custom icons to be shown as thumbnails, hence the borders reported in this LP bug. I tested this by applying the changes in [2] to current Nautilus in Raring (1:3.6.3-0ubuntu16), and the borders around my customized icons went away. Also, though I didn’t test very extensively, this didn’t result in desktop files again having borders as originally reported in #1085320.

(The commit log entry of [2] refers to [3], but I think it should refer to [4] instead.)

*[1] https://bugzilla.gnome.org/show_bug.cgi?id=688808#short_desc_nonedit_display
*[2] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=f69e472263b0bf6e1cc60c0eeaf7874fc7931f8d
*[3] https://git.gnome.org/browse/nautilus/commit/?id=d9ef715ea11e92917414d5d7bddd4dd1487fac1b
*[4] https://git.gnome.org/browse/nautilus/commit/?h=gnome-3-6&id=6cde4c5a6d639c85df09b8992a307f91d6b056a6

On 12.04 at least, the target is governed by cupsd’s AppArmor profile (see bug #147551) and trying to circumvent it using symlinks fails irrespective of whether the target is on another filesystem or not (”failed to set file mode for PDF file” in /var/log/cups/cups-pdf_log).

As per bug #147551, when the default target directory is changed in cups-pdf.conf, cups-pdf silently fails to print anything until a corresponding change is made in the usr.sbin.cupsd AppArmor profile. The ”Out” key in cups-pdf.conf is preceded by commented notes about the usage, but the AppArmor requisition goes unmentioned, apparently causing confusion among users. I suggest something like the attached patch be applied to cups-pdf.conf to document this.

Just making a note about similarity between this and bug #939301; latter perhaps a duplicate?

umount.crypt doesn’t support lazy unmounting:

jani@saegusa:~$ sudo mount .Backup
Password:
jani@saegusa:~$ grep Backup /etc/mtab
/dev/sdc1 /home/jani/.Backup crypt rw,nosuid,nodev,noauto 0 0
jani@saegusa:~$ sudo umount -l .Backup
Unknown option: -l
Usage: umount.crypt [-fnrv] [-?|–help] [–usage]
Unknown option: -l
Usage: umount.crypt [-fnrv] [-?|–help] [–usage]

The usefulness of -l is documented in umount(8).

Strangely, the Debian BTS claims this feature has already been implemented ages ago [1].

*[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370526

As a workaround for 12.04, here’s a command that replaces the settings file with an unwritable empty one that seems to prevent the issue from occurring:

$ rm -f ~/.openyahtzee && touch ~/.openyahtzee && chmod -w ~/.openyahtzee

This obviously prevents you from saving any settings, but then again you can’t utilize saved settings with the buggy version anyway.

To revert the workaround, remove the unwritable dummy file with:

$ rm -f ~/.openyahtzee

Steps to reproduce:

1. Load a playlist of N files in VLC
2. Set playback to Random
3. Play or jump (with ”Next” button) the playlist forward for N files and observe the playing order
4. GOTO step 3

What happens:
The order in which the files are played in step 3 always repeats itself.

What I expect to happen:
For the files to be played back in a truly random order, without any perpetually repeating pattern.

Further info:
The playing order seems to get shuffled only at the start, so the playlist isn’t played in order, but the once-shuffled order is repeated over and over. To reshuffle the playlist, VLC has to be restarted, but still then it just plays the newly-shuffled playlist over and over.

To be fair, in practice instead of true randomness I suspect most people prefer something from the way the ”Random” now works: that each file on the playlist is played once and once only in every N plays. AFAICT it is not mutually exclusive with reshuffling the playlist between those N plays; just make sure that the two transitional files (last file of shuffled-playlist-1 vs. first file of shuffled-playlist-2) aren’t the same.

I for one though would still prefer even true random over what it currently is.

Of the half a dozen or so randomness-related bugs in VLC’s tracker I was able to find, Ticket #5730 (”New Feature Request: Shuffle & Random for Playlists”) [1] came closest to what I’m reporting here. In fact, it’s a superset of this one and I’d prefer to have it fixed over just mine.

*[1] http://trac.videolan.org/vlc/ticket/5730#trac-ticket-title