The noauto/mount in rc.local does work, and that is how I am currently
working around the issue.
However, this is a workaround and NOT a solution. There is no reason
mounting network shares in fstab should not work, and it worked fine in
Breezy. Upgrading from Breezy gives the impression that Dapp
I am also experiencing this bug, using the k7 kernel on an nForce 4
mobo. Changing the mount option from smbfs to cifs works as a stopgap
measure.
Is someone working on this?
--
auto smbfs mount in /etc/fstab causes hald hang at boot
https://launchpad.net/bugs/44874
--
desktop-bugs mailing list
Sorry for the late reply.
This isn't a problem with a specific video, or even one batch of
encodings. I've tried dozens of .avi files, encoded with xvid, divx and
ffmpeg.
On closer inspection, neither "square", which is detected by default,
nor 4:3 produce the right aspect ratio. Both produce vid
Public bug reported:
Affects: nautilus (Ubuntu)
Severity: Normal
Priority: (none set)
Status: Unconfirmed
Description:
Hi,
I'm running AMD64 Dapper, up to date.
When I'm downloading a longer video using bittorrent (bittornado
client), gnome-video-thumbnailer tries, again
Public bug reported:
Affects: totem totem-gstreamer (Ubuntu)
Severity: Normal
Priority: (none set)
Status: Unconfirmed
Description:
Using totem-gstreamer in an up to date Dapper system, the aspect ratio
seems to default to "square" for all videos. The correct aspect ratio