Videos seeking to 80 seconds on first read

vvvv beta bug
1

Hello everybody, i have a project on beta 23.
on first read, certain video are are seeked at exactly 80 seconds position, thn played normally.

nothing inside the debug TTY
the seek is manually setted or on change of the file name (string).

video being affected by this strange behaviour are:
WMV 1280720 xbr8g8b8 , mipmapcount 1, 608.3 length
WMV 14401080 xbr8g8b8 , mipmapcount 1, 1264.6 length

could it be the length responsible of it ?
as this happens on just those 2 videos.

file is selected > i m doing play > the two files will seek at the first read, then play again from beginning, until the end, without seek. I can ask for play there will be no trouble after if i stay on the same file:
once the video has seeked unfortunatly to beginning, its no more seeking at 80 seconds.

if i change files in the video player the file to play, the two files will seek again at same position, 80 seconds, then play without troubles

this happens without calling any other part of the project, just on read of videos.
i have past my day to test everything, and this happens despite anything else is loaded.

here is the subpatch handling video player. is there something hidden inside ? or a big mistake somewhere ?

sub_lecteur_video_7.v4p (39.2 kB)

2

helo karistouf,

strange thing again. never heard of, no idea what would cause this. but since it consistently seems to happen to you it should be possible for you to debug this down to a patch that consists of only a few nodes.

you know: reduce the patch…remove node by node and see if the problem still appears. do this until you can no longer simplify the patch, or the problem goes away. if you have a dead-simple patch that shows the problem with a specific video you could upload patch and video for me to check.

3

hi joreg. i got the computer back before its going on tour again.

i have setted in my different patch some index, to retrace whats going on: a togedge + a tooggle to see if there was any seek order coming from the 2 different commands of seek ( midi key on + mouse on gui)

unfortunately its not at all coming from Seek programmation.( i was hopping in a certain error of mine, helas helas helas).

setted the video player directly in Main folder ( i dont like at all string nodes, a LikeUncleKalleBadFeeling about them) to see if framedelay could affect the name of the file. not that.

I changed also the change(string) to seek to beginning to a change(value) of the index. it not that.

what is interresting in this file:

-file 1. 1230 sec Loop ON
-file 2. 80 sec Loop OFF
-file 3. 608 sec Loop ON
-file 4. 344 sec Loop ON
-file 5. 211 sec Loop OFF
-file 6. 298 sec Loop OFF
etc…

This *****ing bug arrives only for file 1 and 3, and at the time of file 2 duration.

This time is used with a framedelay to set the loop to endpoint.

I changed the LOOP OFF to LOOP ON and its seems no more to bug. But its giving me a file in loop to deal with ( making a stop manually)

In my patch, the duration time from filestream1 is corresponding.
I dont understand why it happens, surely it will make a kind of sense for you in your crusade.
surely something with a memory leak somewhere.

Actualy in the TTY i just have one warning on all the patch when calling different function, wich is related to my rj45 patch “cant draw geometry at once, switching to slicewise rendering”. Thats the only thing giving bad advice.

I know that my texture are not in dds, and mainly a mix of JPG and PNG. i m quite sur that the leak is coming from this non classical/clean way to handle textures.
Actually i didn t arrived to export any texture in DDS. rrrr’s texture converter in contribution doesnt seems to do it ( or where does it exports ?).

Voilà for the bug report Joreg ! ;-)