Seek-Funktionen... synchron... asynchron... ?

  • vom aufruf her hat man ja den eindruck, dass seek funktionen wie z.b. doSeekRelative synchron ausgeführt werden, d.h. die funktion returned, wenn der sprung durchgefuehrt ist.

    dem ist aber nach meiner beobachtung nicht so. wenn direkt nach dem aufruf ein getPosition macht, dann wird die position vor dem seek zurueckgegeben.

    das waere ja alles nicht so schlimm, aber wenn man beim abspielen einer laufenden aufnahme ans ende springt, dann verheddert sich ab und zu das seek und ein rueckwaertssprung mit doSeekRelative(-xyz) funktioniert nicht mehr. doSeek(pos) gehen dann auch nicht.

    meine frage: gibt es eine moeglichkeit, abzufragen wann ein seek ausgefuehrt worden ist? ein callback oder so scheint es ja nicht zu geben.

    danke.

  • da mir keiner hilft :face_with_tongue: , habe ich ein bisschen weitergewurstelt...

    das doSeekRelative soll ja am fileende zur position 1s vor ende springen (wenn ich den code richtig verstanden habe). das scheint auch meistens zu funktionieren, aber anscheinend nicht immer. ich vermute, dass bei einer laufenden aufnahme, das ende nicht immer richtig bestimmt wird und es dann zu komischen effekten kommt.

    ich habe jetzt mal nach jeder seek op eine 1s blockade eingebaut, bevor die naechste seek operation ausgefuehrt wird.

    das scheint die sache zu verbessern, aber ob der wuergaround 100%ig funktioniert muss sich erst noch erweisen.....

  • also das self.doSeekRelative funktioniert bei mir nicht richtig...

    deswegen teste ich jetzt mal direkt mit self.getSeek().seekRelative(direction, distance).

    mal sehen...

  • Nutzt du das bei Aufnahmen, die von einem mount kommen oder lokal von der HDD?


    Ich hatte das auch sehr unzuverlässig auf der One (teilweise bei einem kleinen Sprung plötzlich am Filmende...). Dabei hat die One per nfs auf die HDD der 920 zugegriffen.

    Ich musste dann aber die One mal neu flashen und den mount mit default-Werten neu einrichten.

    Danach hatte ich die Probleme nicht mehr.

    Also vermute ich, dass die damals manuell angepassten Optionen in der fstab doch nicht so gut waren.

    Gruß Sven (aka Dreamy)


    DM920 mit unstable OE2.5 DP
    One mit unstable OE2.6 DP

  • wie befuerchtet, geht self.getSeek().seekRelative auch nicht richtig... denn doSeekRelative ruft ja auch nur self.getSeek().seekRelative auf.


    habe auch festgestellt, dass 2 seeks hintereinander nicht funktionieren... wenn man ca. 1 sekunde zwischen den seeks wartet, scheint es zu funktionieren...

    ist aber irgendwie unschoen.

  • funktioniert leider auch nicht...

    habe hier mal ein log... vielleicht konnen Reichi oder Ghost mal einen blick draufwerfen... danke.

  • ich kann schon verstehen, warum keiner der experten antwortet... :winking_face:

    nach meiner analyse auf oe2.5 werden beim abspielen von laufenden aufnahmen die position und/oder die aufnahmelaenge ab und zu nicht richtig bestimmt. das fuehrt dann dazu, dass spruenge hinter eof landen. bei relativen sprüngen verharkt sich die sache, und es funktionieren keine sprünge mehr.

    deswegen habe ich jetzt absolute spruenge verwendet. wenn bei den absoluten spruengen der sprung hinter eof landet, dann wird doEoFInternal aufgerufen, und man kann einen workaround machen... z.b. stopService() + playService... damit landet man am anfang der aufnahme und kann wieder ans ende springen. weitere spruenge funktionieren dann wieder.


    bei oe2.6 funktioniert das nicht, da man mit stopService() + playService() nicht am anfang der aufnahme landet sondern das die aufnahme weiter verharkt ist. mit playService() und einem kleinen relativen sprung rueckwaerts kann man jedoch das abspielen fortsetzen.


    alles irgendwie schraeg :wacko:

    Einmal editiert, zuletzt von alpha ()