STUDIO B12  Büro für digitale Kommunikation  T  0531 28 853 78 0  E  info@studio-b12.de

Bug: Nach NetStream.seekTo() kommt NetStream.Seek.Notify zu früh

Update:
Seit gerade eben ist das Ticket zumindest schonmal einem Mitarbeiter zugeordnet, es geht voran! Fleissig dafür voten, und hoffentlich sind wir bald dieses Problem los.

Es gibt schon eine ganze Weile eine lästige Unart des NetStream-Objekts von AS3:

Wenn man NetStream.seekTo() aufruft, wird anschließend ja ein NetStatusEvent.NET_STATUS dispatched, das im info-Objekt den code NETSTREAM_SEEK_NOTIFY aufweist (vorausgesetzt, es konnte zu dieser Stelle des Videos gesprungen werden).
Wenn man sich nun eine Applikation vorstellt, die nach dem Spulen überprüfen muss an welche Zeit NetStream nun eigentlich gespult hat (denn dies kann ja vom übergebenen Wert in seekTo() abweichen, da Flash nur zu I-Frames springen kann), liegt es nur nahe genau auf dieses NetStatusEvent zu warten und dann NetStream.time auszulesen. Denn NETSTREAM_SEEK_NOTIFY wird lt. Adobe aufgerufen, wenn das seeking beendet wurde.

Leider wird man schnell feststellen, dass die NetStream.time Eigenschaft immernoch dem alten Wert (vor dem seekTo()-Aufruf) entspricht. Den einzigen workaround den ich bisher finden konnte ist, das entsprechende NetStatusEvent erstmal zurückzuhalten und einen Timer anlaufen zu lassen. Jetzt kann man so lang NetStream.time überprüfen, bis sich die Eigenschaft wirklich geändert hat. Erst danach wird das entsprechende NetStatusEvent nach “draußen” gelassen.

Wenn Euch diese Eigenheit auch nervt, dann meldet Euch in der Bugbase von Adobe an und voted für das entsprechende Ticket.

Bookmark and Share

Dein Kommentar