[vlc-devel] [RFC] Directory access: use a decent insertion order

[Antoine Cellerier]

On Sun, Feb 14, 2010, Rémi Denis-Courmont wrote:
> Le dimanche 14 février 2010 00:04:28 Antoine Cellerier, vous avez écrit :
> > I'd like to modify the directory access to make it insert
> > file in alphabetical order instead of the current "random"
> > order (well, natural sort order, not really alphabtical.
> 
> AFAICT, unless you've randomized the playlist, the order is whatever the 
> filesystem uses (which is not random). At least mpg123 and ogg123 exhibit the 
> same order.

Which isn't to say that it's the right order from a human user's point
of view. The filesystem ordering scheme isn't random but it's still
completely illogical when all you consider is the filename. All software
which list files in directories, like your nautils (or kde equivalent),
explorer, finder, rythmbox, firefox, etc always sort it decently by
default.

> > See
> > http://svn.rockbox.org/viewvc.cgi/trunk/firmware/common/strnatcmp.c?view=ma
> > rkup for rockbox's implementation of the comparison function.
> 
> That code looks either way too complicated (just to get alphanumeric order) or 
> way too simple (to get proper Unicode ordering).

man strverscmp (a gnu extension) explains it a bit better. The end
result is the same.

> 
> > To make things short, it basically considers numbers as a single
> > character so that "2 - something" would come before
> > "10 - something else")
> > 
> > Would anyone oppose such a move?
> 
> The current code which has almost constant memory consumption(*) and strictly 
> bound I/O and CPU usage in every Block() call. As such, you can still use VLC 
> while it is loading a large file system tree of any size. To preserve bound 
> I/O while sorting would involve major changes to access_t, which I definitely 
> don't want to do before 1.1 is branched. Therefore I against any change for 
> the next release series.

Sorting of the directory nodes wouldn't add any significant overhead (it
could even be coded to reduce the numper of asprintf psz_xspf_extension
string concatenations and thus probably reduce the total runtime).
Sorting of the items would probably be possible fairly easily too. All
you need to sort is the <extension> tree structure bit. I'll code a
small prototype tomorrow.

> (*) The guy who designed the tree structure inside VLC extension to XSPF 
> probably did not understand how XML works. This is completely brain damaged.

Agreed ... but then you have to consider all the XSPF related
constraints (like needing a flat playlist since your .xspf file needs
to be compatible with other parsers which don't implement the VLC
extensions). You could always ask Yoann :-)

-- 
Antoine Cellerier
dionoea