Two known bugs in the current Dolphin Viewer 3

The current Dolphin Viewer 3, 3.4.1.26336 has two known issues that are being handled right now:

  • Using texture refresh on objects with sculpted prims can cause the viewer to crash. This is fixed in the current beta, and that fix will be in the next release.
  • Child prims that are moved by scripts sometimes fail to move properly if they also have a hovertext that changes at the same time (e.g. the boom on MLCC boats). There is a fix for it that I’m trying to hunt down right now. For a workaround you can configure the MLCC boats to use a different childprim for hovertext. For this consult the notecards that come with the boats.

 

Serious bug: the file requester freezes the viewer in Ubuntu 12.04

It seems that this previously announced bug on Ubuntu 12.04 is more serious than initially assumed, and also is still not fixed.

From reports on the FireStorm bug tracker it seems that it is based on a packaging bug in Ubuntu itself, and affects everything in the viewer that opens a “open file” requester … snapshots, uploads, etc.

Do not update to Ubuntu 12.04 yet.

Bug warning for linux users: do not update to Ubuntu 12.04

This JIRA just came to my attention: https://jira.secondlife.com/browse/VWR-28846. According to it, current viewers (including the Dolphin viewer) crash on Ubuntu 12.04 when you try to take a snapshot.

I do not use Ubuntu, so cannot verify, but suggest that you do not update your Linux installation to Ubuntu 12.04 until this issue has been resolved.

 

Known bug in Dolphin Viewer 3.1

There is a bug in all versions of Dolphin Viewer 3.1 that makes the viewer crash whenever you import an AO notecard by dropping it on the AO Floater.

As a workaround you can set up the AO manually. I’m working on a fix but it is slow going right now, for reasons outlined as follows:

As some of you might know I use the openSUSE build service to work on the Dolphin Viewer.

With the recent release of openSUSE 12.1, the build service is so totally swamped with everybody scrambling to get last fixes in their projects, that it currently takes about two days to build a viewer there. Whereas before, it used to take two hours. Just a little example: a package of the latest firestorm that I was trying to buid took twelve hours to go from 76% to 90%…

With such turnaround times there’s not much I can do right now.

Since I have a couple of to do items that I have to address before I can release the next Dolphin Viewer 3 (which will be based on 3.2 sources and Marine Kelley’s latest RLV, and have a couple of other shiny things that you will like a lot), I’ll postpone the next releases until the build service has a bit more breathing room.

Besides, I gotta update mine and Lapis’ laptops to 12.1 first anyway.

Why am I not building at home you ask?

My linux build environment at home is a Debian 5 in a VirtualBox VM on a Mac Mini. Good enough to crunch out release packages over night, but for a development cycle? Forget it.

So stay tuned.

Bug in Dolphin Viewer 3 – Settings not saved

There is a nasty bug in the most recent Dolphin Viewer 3: 3.0.9.20496 that has the effect that Preferences are not saved at all. This only happens on completely new installs of the Dolphin Viewer 3.

If you are experiencing this issue,  please install Dolphin Viewer 3 version 3.0.8, change a setting, quit Dolphin Viewer 3 3.0.8, and update to 3.0.9.

I will be releasing a 3.0.10 as soon as I have a fix for this – most likely within 24 hours.

Here are the download links for 3.0.8:

DolphinViewer3-i686-Windows-3.0.8.20470.exe

DolphinViewer3-i686-linux-3.0.8.20470.tar.bz2

DolphinViewer3-i686-Darwin-3.0.8.20470.dmg

Update: 3.0.10.20499, which fixes this bug, has been out for a week now. These download links are not needed anymore.

Known issues with Dolphin Viewer 3

I have to report three bugs in Dolphin Viewer 3.

  1. The performance on Windows can be abysmally slow, i.e. one third of what you’re used to (inherited from original 3.0 code).
  2. Replacing a saved outfit that contains more than one of any one wearable type (two or more tattoo layers) does not take off all of those layers (e.g. one tattoo stays behind but does not show in “Current Outfit”)
    (reproduces in original RLV 2.7).
  3. Sending teleport offers to more than one person through selecting them on your friends list makes the viewer crash (Reproduces in original RLV 2.7)

Be assured that 2. and 3. are being worked on. Number 1. is in the hand of Linden Labs.

What’s even worse is that 3. is also present in Dolphin Viewer 2 … and because I don’t have another spare PC I can’t maintain DV2 anymore, unless someone makes it build ok on Visual Studio 2010.

Ogg Security hole, status update on next version

I’m aware of the security hole in the ogg libraries used in the current dolphin viewer.

Unfortunately I’m about 6000 miles away from my computer with the build environment right now, and will be until at least the end of may… so i can’t do anything.

Luckily enough the security flaw has not been exploited for any shady things as of now.

As soon as I’m back home I’ll build a 2.5.6.1 with the fixed libraries. In the meantime, switch off media playing if you are concerned about possible exploits.

After that I’ll start on integrating my patches, RLV 2.7.0.1, and 2.6.3 into the next real version.

 

Startup problems with Windows XP

It has been brought to my attention that on some Windows installations, Dolphin Viewer won’t start properly, giving you a message that “A reinstall might fix this”.

That is not quite correct.

The problem is that on older Windows Versions (e.g. Windows XP), the MS VC 2008 runtime libraries that the Growl libraries require are not installed by default.

On newer Windows systems like Vista or Windows 7, they are.

There is no known workaround for this yet, but in the next relase of Dolphin Viewer will be fixed as I’ll be rebuilding the Growl libraries against VS2005 for this reason.

Thanks to richie Aura for bringing this to my attention.

Known issues with 1.5.35.3627

Hi guys,

there are two bugs in 1.5.35.3627 that I know of:

  • The HTTP texture corruption bug mentioned in an earlier post and on the forum.
  • The Wear/Add inventory action bug (basically, Wear on an attachment in your inventory does the same as Add, where it should actually replace the attachment, the same way as “Wear items” on a whole folder in your inventory does).

The workaround for the HTTP texture corruption bug is to turn HTTP Texture fetching off, in Preferences -> Advanced -> Graphics Tuning; after doing so please clear cache and relog.

The Wear/Add bug will be fixed in the next release.