Bug 73657 - Play order is `wrong' when adding a directory with sub-directories to the playlist
Summary: Play order is `wrong' when adding a directory with sub-directories to the pla...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: noatun
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Charles Samuels
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-28 02:22 UTC by Nathaniel Taylor
Modified: 2012-07-02 16:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
recursively list dirs in natural order (2.37 KB, patch)
2004-10-25 22:56 UTC, Stefan Gehn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathaniel Taylor 2004-01-28 02:22:14 UTC
Version:           2.4.0 (using KDE 3.2.0 RC1, compiled sources)
Compiler:          gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice)
OS:          Linux (i686) release 2.4.20-gentoo-r8

When adding files from a tree more than one directory deep to the playlist, the order in which the contained audio files appear in the playlist is often not the obvious order of going through the tree according to the filename order of subdirectories.

Note that the order of files immediately within any directory _is_ correct as far as I can see; it is just the ordering of directories that is wrong.

______________________________________________

CAUSE:  I believe the cause may be that noatun uses simple system calls to find and add sub-directories, and therefore adds them in the order in which their entries in the parent directory were created.

WHY A PROBLEM:  It is very often the case that someone rips a set of several cds, keeping directory names and filenames numbered in the hope that they will play in the right order.  This should work even if the order of ripping is not the same as of the CDs, or if some file moving/copying done later changes timestamps and directory entry order.

SUGGESTION:  recurse directory trees strictly by subdirectory name. 
Use preferably non-ascii order, i.e. AaBb etc rather than A-Za-z , as I guess this is how most users would prefer an alphabetical but case-sensitive ordering to work.
Start at the top directory, and play all music files in it in this name order.  Then take the sub-directories (if any) in the same name order, and repeat the same rules for each of these.
For what I have seen as common music file trees, this would give the most desirable ordering.

EXAMPLE:

#  Make clearly ordered directories, but in strange 
# creation order. Add music files to directories.
mkdir cd_{1,3,2}
cp ~/test.ogg cd_1/1st_cd.ogg
cp ~/test.ogg cd_3/3rd_cd.ogg
cp ~/test.ogg cd_2/2nd_cd.ogg

# Use `find' to show the directory entry order
find . -type f
./cd_1/1st_cd.ogg
./cd_3/3rd_cd.ogg
./cd_2/2nd_cd.ogg
## NOATUN ADDS TO PLAYLIST IN THIS SAME ORDER


# Now do same thing for creating cd_{1,3,2}
# but create files in normal order.
cd ..; mkdir new; cd new
mkdir cd_{1,3,2}
cp ~/test.ogg cd_1/1st_cd.ogg
cp ~/test.ogg cd_2/2nd_cd.ogg
cp ~/test.ogg cd_3/3rd_cd.ogg
## SAME RESULT AS ABOVE, FOR FIND AND FOR NOATUN
## Suggests it is listing of subdirectories in parent
## rather than creation times of files that is used 
## for ordering

# Finally, add more files in the above tree, in yet another order:
cp ~/test.ogg cd_3/3rd_cd__a.ogg
cp ~/test.ogg cd_2/2nd_cd__a.ogg
cp ~/test.ogg cd_1/1st_cd__a.ogg

find . -type f
./cd_1/1st_cd.ogg
./cd_1/1st_cd__a.ogg
./cd_3/3rd_cd.ogg
./cd_3/3rd_cd__a.ogg
./cd_2/2nd_cd.ogg
./cd_2/2nd_cd__a.ogg
## Noatun does exactly the same as `find' here too


The sensible order is given by 
echo */* | xargs -n1
cd_1/1st_cd.ogg
cd_1/1st_cd__a.ogg
cd_2/2nd_cd.ogg
cd_2/2nd_cd__a.ogg
cd_3/3rd_cd.ogg
cd_3/3rd_cd__a.ogg


Finally:  I rather wonder if some random play effect is used by default, as I have just tried this same test-directory in noatun with a different result from last time.  If this is part of the problem, I suggest it should be turned off by default, as it is confusing.  I deleted my noatunrc file just in case I had sometime set such a thing.
Comment 1 Stefan Gehn 2004-10-25 20:32:00 UTC
Yes, this bug does exist, I don't know yet if I can fix it but I'm surely interested in doing so. Will come back here as soon as I have new facts (or a fix, whatever comes first).
Comment 2 Stefan Gehn 2004-10-25 22:44:04 UTC
I think I have fixed it locally, right now my code adds files like this:

topfile1
topfile2
dirA/file1
dirA/file2
dirA/subdirX/sfile44
dirA/subdirX/sfile55
dirA/subdirY/sfile88
dirB/file3
dirB/file4


Is that what one would expect? I think it looks logical now (but now the code looks insane) :)
Comment 3 Nathaniel Taylor 2004-10-25 22:52:44 UTC
Yes -- that looks fine.
Thanks!

Nathaniel
Comment 4 Stefan Gehn 2004-10-25 22:56:04 UTC
Created attachment 8032 [details]
recursively list dirs in natural order
Comment 5 Stefan Gehn 2004-10-25 22:58:20 UTC
And that's the patch (against HEAD) for it. If it's ok I'd be glad to commit this soon. FlexPlaylist (my own playlist) of course will be updated as well if the patch works out.
Comment 6 Stefan Gehn 2005-01-27 20:20:03 UTC
Somebody please try out that patch.
Comment 7 Nathaniel Taylor 2005-01-28 00:10:15 UTC
I'm not familiar with matters other than compiling proper releases of KDE.
What I have just done is to untar the kdemultimedia-3.3.2 tarball on a system with all the components already in /usr/kde/3.3 , then compile the multimedia package with your patch applied to the two files, then run the resultant notaun program (which would then use the old system libraries)
So, you must say whether this is a proper test or whether I should copy some further files to /usr/

When I compared the old and patched programs it initially looked good, but then I found that the order in which subdirectories are added to the playlist actually changes each time!  So, try adding  a directory with subdirectories, then clear the file list, then click to add a directory again and click ok to accept the same as before:  for me, with both versions, this sometimes changes!

I have tried looking in the "configure noatun" menu in case there's some sort of randomisation, but I see nothing that looks relevant to the problem.

Any ideas?   Should I test another way?
Comment 8 Stefan Gehn 2005-01-28 00:17:25 UTC
After patching and compiling you have to run "make install" inside noatun subdir. Starting noatun from source-dir does not (this won't work with kde-applications in general).
Comment 9 Nathaniel Taylor 2005-01-28 10:36:29 UTC
OK -- I installed the whole patched notaun (from kdemultimedia-3.3.2) properly, and have tested on many trees of directories:  it worked perfectly for all I tried.

Thanks!
Comment 10 Christoph Feck 2012-07-02 16:25:23 UTC
noatun has not been part of the KDE 4 release and is no longer maintained.

KDE now offers Dragon as a video player and JuK as a music player. Additionally, other popular KDE players have been ported to KDE 4, such as Amarok or Kaffeine.

If this issue is still applicable to KDE 4 applications, please add a comment or file a new report.

For more information, see http://websvn.kde.org/?view=revision&revision=718046