How to handle 20000 files (of music)

As people learned that handling 20000 music files in a hierarchical filesystem is not a practical solution, music player were developed which do search for all mp3 files in a filesystem, read the metadata of all found music files and store the data in its own database.

The content of the database is presented in lists which can be FILTERED.
Rhythmbox is an example of such a multidiaplayer.

So music-players are a good example of how to handle a large number of files without a directory structure: by defining FILTERS

But the handling and definition of FILTERS in Rhythmbox could be improved.

Advertisements
Posted in Uncategorized | Leave a comment

A good example of how to handle long lists (of fonts)

Scribus did implement a good dialog for selecting a font by using a FILTER.

But it could be improved by adding additional filters

Posted in Uncategorized | Leave a comment

How to identify the correct file in a large directory?

I made another video to demonstrate that a powerfull FILTER interface within an import dialog would make live much easier.

Posted in Uncategorized | Leave a comment

directories with lots of content are difficult to handle

I made a video how you can load a video clip from a directory into kdenlive.

We can see that handling long lists (of files) is problematic.

“FILTERING by file-attributes” would improve that situation a lot.

The only filter which is available in that inport dialog is that of “supported file formats” which even does’nt recognize all file formats supported by Kdenlive.

Rearranging the files in different directories so that only a limited number of
files would be in one directory would create a different problem.

Posted in Uncategorized | Leave a comment

Semantic desktop? Might it be usefull?

Much development efford was put into the development of the Nepomuk technology.

http://nepomuk.kde.org/node/1

But is seems as very few are using it.
It seems as Nepomuk is a huge and excellent chunk of techology which is only used by few end user as very few enduser application makes use of it.

So what is the problem with Nepomuk?

If smart technology is not used by users (or programmers),
there might one or several reasons for it:

1) The smart technology does try to solve a nonexisting problem
2) The smart technology is usefull, but not enough to justify the risk and effort of a change
3) The smart technology is very usefull, but is not understood by those who could use it
4) The smart technology is just not yet ready for general use.

So lets start with 4)

Postings like http://amarok.kde.org/blog/categories/24-danielw suggest that even when people do understand that Nepomuk might be a good solution, it is not up to the task. That was 2008. The main author of Nepomuk assured me that Nepomuk
today  can handle all requirements of media players and actually http://bangarangkde.wordpress.com/ is using Nepomuk as its Metadata backend.

But as Amarok is still using its MySQL backend, there is currently no sufficient advantage for the Amarok team to start using Nepomuk instead of MySQL.

So we can see that Nepomuk for now is not a better solution for everything and
point 2 is true for Amarok.

But we might learn something from Amarok for other use cases:

The usage of MySQL within Amarok also demonstrates that managing playlists by navigating the filesystem and selecting individual MP3 files by filenames is not sufficient.

Amarok enables a user to find the music files he is interested very fast.
How does Amarok achieve this?

FILTERING!!

It seem to be that filtering is a very powerfull method to find those files people are interested. Filtering uses  the characteristics files do have. With MP3 music files, this characteristics are mainly stored in ID3 tags included into the mp3 files itself.

So the user can filter all his mp3s for containing ABBA music.
The resulting 2343 mp3 files containing an ABBA song then can be filtered by year or by any other attribute (=tag) attached to the mp3 files, like bitrage, genre,….

Amarok is very good in extracting attributes from an mp3 file and storing all this metainformation in its database. Even when no attributes are found within the music file, amarok can find out this infos by fingerprinting the musik itself and looking up the attributes in a central database.

With mp3s managed by Amarok we see that:

1) the filename of the mp3 files is no longer important to the user once Amarok has taken over
2) the filepath is no longer important to the user once Amarok has taken over

Amarok programmers did implement a very efficient way for handling large number of files by using “FILTERING by attributes”.

So at least we can say that Nepomuk does solve an existing problem!

In future postings I will demonstrate how the concept of FILTERING is much more powerfull than the concept of “navigating a file-tree” and where the conepct of FILTERING might be very usefull.

But we still can not answer the question for what usecases
Nepomuk is usefull enough to justify its usage!


Posted in Uncategorized | Leave a comment

Hello world!

This blog will contain my thoughts about document handling.

It will reflect my thoughts from a user perspective. I intend to post a little bit of history, a little bit of thoughts about what I would love to have available to me to be more productive.

This blog will contain a lot of complaints about the features of software and hardware products and how other people see things different from how I see things.

Nothing of what I write is meant to be an insult to anyone, but rather an invitation for discussion about the issue.

I do have strong believes of how things might work better, and I am old enought to know that I was very often right. But beeing of a certain age also means that I experienced  very often that I was wrong.

So lets start the rumbling.

Posted in Uncategorized | Leave a comment