On Sep 16, 2006, at 2:25 AM, Sivakatirswami wrote:
But obviously QT--Windows is having trouble with this.
So perhaps we need a better, more "graceful"
implementation that Windows is happy with.
Are there other things we need to be thinking about?
Possibly:
1) delete previous URL for the stopped media from the Rev Cached URL's
The URL won't be in Rev's cached URLs unless you were downloading it
yourself first. QT deals with the URL exclusively and handles
caching when you load URLs in a player object.
2) Maybe have two players? if Player1 is running, stop it,
and assign the next selection to Player2, start it up, meanwhile
"clean up" player1 (set filename of player1 to "") then on next
selection.
Stop player2 and assign latest selection to Player1 and clean up
Player2?
This way one is not trying to stop, reset filename, re-initialize
the socket, start streaming
again... all in one player object...
I'll give that a try.
Any more bright ideas?
The one player approach should work out but you never know.
I have one app that loads lots of QT movies throughout a session.
Each step in a lesson (e-learning) can have up to three QT movies on
screen at one time. I actually delete all players and create new
ones as needed each time the screen changes (part of a template
system) and this has worked well for us. Maybe something to try if
you continue to see problems.
Trevor
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
