Re: [Kionjb-devel] Releasing 0.2.4

[ace j. <ac...@ho...>]

Ok, 0.2.4 is out now.  There were quite a sizable number of changes from
the previous release:

* Works with libnjb 2.2
* Displays albums as directories containing the files for each track. It also lists albums as sub directories of each artist.
* Supports id3 v2 tags
* Calculates lengths of MP3 files more accurately
* Support for data file folders
* Only disconnect from the njb if the device has not been accessed for 5 seconds.  A more stable way to interact with libnjb
* Better handling of uploads from a remote source (e.g. ftp)
* Properly handles "/" characters in playlist names
* Various code clean-ups and stability enhancements
* Hopefully fixed "can't find -lkio" compile problem on some distros 

On Wed, 2005-07-06 at 14:37, Rob Walker wrote:
> There's one bug I've just picked up on - listing albums under artists fails if 
> there's a trailing slash (e.g. njb:/artists/foo/bar/).  The attached patch 
> fixes this.  It also removes the test against a filename of "*" in listAlbum 
> as this wouldn't filter out anything (and may even cause listAlbum to handle 
> other dirs such as /etc).

I committed this, thanks.

> In the long term, we should improve the way we match against the file names. 
> The current file name of 'Artist - Song Title.mp3' doesn't work very well 
> when you have live or remix albums by the same artist (and also if the artist 
> reuses track names e.g. Intro).  Listing all tracks causes such entries to 
> appear to be repeated and deletion may delete any such track, even if you're 
> browsing in njb:/artists/Artist/Album/.  Making the filenames 
> 'Artist - Album - Song Title.mp3' will go some way to solving this and we can 
> also use the artist or album names in the path.

Yes, this really annoys me also.  The problem is, Artist - Song
Title.mp3 is pretty standard.  Another solution might be to reorganize
the file structure.  Get rid if /all, and create an 'all' under
/artists/Artist, so you'd have:

/artist	
	/Artist1
		/all
			Artist1-Song1
			Artist1-Song2
			Artist1-Song3
			Artist1-Song4
		/Album1
			Artist1-Song1
			Artist1-Song2
		/Album2
			Artist1-Song3
			Artist1-Song4
	/Artist2
		...
/album
	/Album1
		Artist1-Song1
		Artist1-Song2
	/Album2
		...

Thus the only problem is if you copy files into or delete files from
/artist/Artist/all when there are duplicates.

And certainly deleting from njb:/artists/Artist/Album even right now,
it's silly for the program to allow this problem to occur.  delTrack()
has enough information to know you're deleting from 'Album', so it
should include that in the search when looking for what track to delete.

> Also, creating directory listings is quite inefficient as we scan all the 
> tracks to see what should be in the directory and then for each file search 
> through the list again to get the size etc.  Maybe we should have a 
> createUDSFileEntry function that takes a file size taken from the initial 
> scan of the tracks.

Sounds like a good idea to me.

</Ace>