in a recent project we used the Stride ImagePlayer to play a Sequence of DDS Images.
While testing on the target machine we noticed, that the playback started at a random frame in the middle of our sequence. After trying to rename our sequence and checking the dds files manually, we tried with the png sequence where the behaviour didn’t happen.
After starting gamma with editable packages, we noticed that the Spread of Paths inside the ImagePlayer wasnt sorted alphabetically and fixed this temporarily by implementing a Sorting. Building the exe afterwards was rather tricky, as it seemed that the build always used the precompiled dll without our fixes so we ended up making a copy of the Imageplayer and loaded it from a different .vl file.
The Screenshot is not from the deployed machine. Its just to highlight where we found the problem in our case.
Is it possible to force the GetFiles Node to sort the Paths?
The deploy machine is not the fastest one out there and it seems its a combination of a large number of files in combination with huge filesizes. After the path list got sorted, everything was fine.
Could reproduce with a slower disk and still bigger files:
Not sure if that helps but saw similar behavior in the past when the padding of the filenames was not consistent. For instance, if have something like :
ImagePlayer will be confused. You have to make sure you have enough leading zeros, so previous example shall rather be
For such renaming tasks, AntRenamer has been there forever and works great.
Padding was correct.
Dir Node also gets an unsorted result. Can reproduce the behaviour at the office.
Well, broken down to the most simple example - Dir and GetFiles return a unsorted Spread.
Does it also happen if you leave the search pattern as
can confirm. oddly the wrong sorting is consistent
The remarks on the official docs confirm that:
The order of the returned file names is not guaranteed; use the Sort method if a specific sort order is required.
you probably just get the order of the index table of the file system.
That is of course an oversight in the implementation of the ImagePlayer.
GetFiles is using
public Spread<Path> GetFiles(
string searchPattern = "*.*",
bool includeSubdirectories = false,
bool includeHidden = false)
return this.DirectoryInfo != null ? this.DirectoryInfo.EnumerateFiles(searchPattern, includeSubdirectories ? SearchOption.AllDirectories : SearchOption.TopDirectoryOnly).Where<FileInfo>((Func<FileInfo, bool>) (i => includeHidden || !i.Attributes.HasFlag((Enum) FileAttributes.Hidden))).Select<FileInfo, Path>((Func<FileInfo, Path>) (i => new Path(this, (FileSystemInfo) i))).ToSpread<Path>() : Spread<Path>.Empty;
The documentation of
EnumerateFiles doesn’t have that specific remark but I guess it applies anyways.
both might use this Win32 API:
The order in which the search returns the files, such as alphabetical order, is not guaranteed, and is dependent on the file system. If the data must be sorted, the application must do the ordering after obtaining all the results.
The order in which this function returns the file names is dependent on the file system type. With the NTFS file system and CDFS file systems, the names are usually returned in alphabetical order. With FAT file systems, the names are usually returned in the order the files were written to the disk, which may or may not be in alphabetical order. However, as stated previously, these behaviors are not guaranteed.
good find, thanks for pointing this out. fixed in latest preview (also for the skia imageplayer!)