This patch changes the handling of albums to represent albums
as directories containing the files for each track. It also lists
albums as sub directories of each artist.
Better display of album contents
Logged In: YES
We still need to keep around an m3u-style file that lists
the album's contents. I'll take a look to see how to
accomplish this on top of this patch.
Ok, I do like this patch, but losing the text file of album
contents is a feature regression. And it happens to be a
feature I use myself.
What would you think of adding a file in
njb:/albums/AlbumName/AlbumName.m3u that contains the data
which was formerly generated by getAlbum()? Alternately, we
could put the m3u file in just njb:/albums.
Logged In: YES
I've reworked the patch to keep the text listing of the album as
AlbumName.m3u in the album directory.
A couple of issues remain though:
- Reporting the size of the m3u as the total size of the album
may not be a good idea - what if the client allocates a buffer or
temporary storage based on that size, or expects to receive that
- We should match track names by artist and album where
possible. It's likely that "Artist - Title" will produce more than one
match if you have remix or live albums or tracks titled 'Intro'.
Revised album handling patch
Thanks for the changes.
> Reporting the size of the m3u as the total size of the
album may not be a good idea
Agree. It would be better to calculate the size of the m3u
> It's likely that "Artist - Title" will produce more than
Agree. I hate this about kionjb. Will copying files into
njb:/albums alleviate this?
Ok, this is in. And I made the suggested change to report
the size of the m3u file correctly.
My only complaint is that deleting
njb:/artists/MyArtistName/* is no longer supported, but it's
only a minor complaint. I worked around it in the tests.