Cool VL Viewer forum

Hello,

I am using the Linux version of Cool VL Viewer 1.26.8 (19). The viewer freezes sometimes in a opensim world when on a parcel the Audio music url is changed. This happens sometimes, not always.

Operating system I am using is Xubuntu 12.04.2 LTS.

Dunnow if the hardware details are important, so I add them here:

- Fujitsu-Siemens Amilo Pi 1536 notebook, Intel Core Duo T2300 @ 1.66 GHz, Hard Drive: Fujitsu 100GB SATA with NCQ 5400 rpm, RAM: 1024 MB DDR2 533 MHz, Max 3 GB, Graphics: ATI Radeon Mobility X1400 128 MB (512MB Hypermemory).

I have not been able to find my soundcard details, it only says this in the specs I found: 7.1 SPDIF

Greetings,
Michel Farrell

This happens when the domain name in the music URL doesn't have a reverse DNS entry and therefore resolves to IP 0.0.0.0, which may be the case with some domain redirection services (dyns & Co, for example). This is explained in the tool tip for the "Lookup IP address for filtered domains" in the Preferences floater, "Audio & Media" tab. If the pauses annoy you, you can un-check this setting.

Oh, yes, I forgot to mentioned that, I have not enabled voice option, and also not enabled "Media and audio stream filtering" + not enabled "Mute audio control when window minimized", with these settings it still freezes.

I can't diagnose an issue without proper logs. However, I doubt it's anything viewer-related (I would have noticed it myself already): probably a slow DNS on your side...

Ok, I will see what I can do, when it freezes it freezes completely, I need task manager from Xubuntu to kill cool vl viewer in order to restart it again.

File a proper bug report, then, and see here how to run the viewer from gdb to get a backtrace.

This has been happening to Mistress and me regularly at live shows with the last several versions of Cool VL Viewer including the latest as of this writing (1.26.9.19). She runs 32 bit Ubuntu and I run 64 bit Debian sid Linux. I've been waiting to be able to reproduce it 100% before writing up the bug report. I've installed Mixxx and got a shoutcast stream to debug it and came up with this:

To cause the freeze:
1. Listen to a Shoutcast parcel stream.
2. The server (the one streaming to the Shoutcast server) disconnects.
3. Wait a few moments for the queue to empty.
4. Either:
. a. Change parcel streams.
. b. Click the box to stop the player.
5. The viewer will freeze until either:
. a. The streaming server reconnects to the original Shoutcast server.
. b. The viewer is kill -9'd.

The back trace: (while hung)

Program received signal SIGINT, Interrupt.
Reading in symbols for ../sysdeps/unix/syscall-template.S...done.
0xf7fdc430 in __kernel_vsyscall ()
(gdb) bt
Reading in symbols for ../sysdeps/unix/sysv/linux/usleep.c...done.
Reading in symbols for libc-start.c...done.
#0 0xf7fdc430 in __kernel_vsyscall ()
#1 0xf67dec36 in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#2 0xf680dbbd in usleep (useconds=2000) at ../sysdeps/unix/sysv/linux/usleep.c:32
#3 0xf744566f in ?? () from /u1/CoolVLViewers/CoolVLViewer-Linux_i686-1.26.9.18/lib/libfmodex.so
#4 0xf73bcb8c in ?? () from /u1/CoolVLViewers/CoolVLViewer-Linux_i686-1.26.9.18/lib/libfmodex.so
#5 0xf743462b in FMOD::Sound::release() () from /u1/CoolVLViewers/CoolVLViewer-Linux_i686-1.26.9.18/lib/libfmodex.so
#6 0x08ff7edc in LLAudioStreamManagerFMODEX::stopStream() ()
#7 0x08ff8ac7 in LLStreamingAudio_FMODEX::stop() ()
#8 0x08d3fa34 in LLViewerParcelMgr::processParcelProperties(LLMessageSystem*, void**) ()
#9 0x09109f6d in LLMessageSystem::callHandler(char const*, bool, LLMessageSystem*) ()
#10 0x09114b20 in LLMessageHandlerBridge::post(LLPointer<LLHTTPNode::Response>, LLSD const&, LLSD const&) const ()
#11 0x09112b09 in LLMessageSystem::dispatch(std::string const&, LLSD const&, LLPointer<LLHTTPNode::Response>) ()
#12 0x09112f0c in LLMessageSystem::dispatch(std::string const&, LLSD const&) ()
#13 0x08267180 in (anonymous namespace)::LLEventPollResponder::result(LLSD const&) ()
#14 0x090ae7cf in LLCurl::Responder::completedRaw(unsigned int, std::string const&, LLChannelDescriptors const&, boost::shared_ptr<LLBufferArray> const&) ()
#15 0x0826349a in (anonymous namespace)::LLEventPollResponder::completedRaw(unsigned int, std::string const&, LLChannelDescriptors const&, boost::shared_ptr<LLBufferArray> const&) ()
#16 0x090c69c3 in (anonymous namespace)::LLHTTPClientURLAdaptor::complete(LLChannelDescriptors const&, boost::shared_ptr<LLBufferArray> const&) ()
#17 0x090fabc6 in LLURLRequestComplete::process_impl(LLChannelDescriptors const&, boost::shared_ptr<LLBufferArray>&, bool&, LLSD&, LLPumpIO*) ()
#18 0x090eb6a2 in LLPumpIO::processChain(LLPumpIO::LLChainInfo&) ()
#19 0x090ece88 in LLPumpIO::callback() ()
#20 0x081b8d38 in LLAppViewer::mainLoop() ()
#21 0x08f9518a in main ()

There is nothing written to the log when the freeze happens, nor when the server reconnects and the viewer un-freezes.

log attached.

Hope this helps. If you need to try to reproduce on your system, let me know and I'll toggle a stream for you.

It looks like a FMOD Ex bug (the freeze happens inside a call to the FMOD Ex library). Try switching to OpenAL (edit the corresponding cool_vl_viewer script lines to disable FMOD and enable OpenAL) till the next FMOD Ex release comes out (they got a pretty high release rate).

I couldn't so far reproduce such freezes (but I'm not a fan of streaming music, so I usually keep it off and tested it infrequently) but it would be interesting to know which (type of) stream causes this bug to get triggered: is there a specific place where this kind of freezes happens often ?

They must have forgot a timeout in there somewhere. Thanks.

Since it only (and always) happens when a stream server drops the stream, it tends to happen a lot at the end of live events, where the performer drops his stream before the host switches back to the house stream or to the next performer's stream. And everything is fine as long as I remember to turn off sound before they actually drop the stream.

I have switched to OpenAl and that doesn't freeze the viewer when the music url changes. A good alternative for the time being I would say.