Rockbox

This works well for me - a very nice feature.

Sync, sorta.. I just manually edited the patch for that slight change in tagnavi.config and got rid of those pesky trailing CRs.

   yearalbum-20071104.patch (12 KiB)

Thanks for the cant-do-without patch, I love it!

I went ahead and synced this, hope you don't mind me butting in. I love this patch as do many of the people that use my build.

   yearalbum-20080108.patch (12.1 KiB)

A few minor changes caused this not to build, here is a synced version

   yearalbum-20090122.patch (11.7 KiB)

I'm using this patch for a while and it works perfectly, with my personal tagnavi_custom.config, and it works very nice.
Why it can't be submitted to svn? It's a shame to have to rebuild the database if I want to try some other patch cleanly or if I must switch to a daily build.
Is there some bug or something that prevents it to be submitted?
Anyway, thanks for this patch.

Just another update for the latest head.

   yearalbum-20090312.patch (11.7 KiB)

I don't think this patch is a good idea for SVN inclusion. It increases database size in RAM for people who don't use it, and at most saves you a single keypress during navigation over simply having a Year filter before having an Album filter. I don't think its RAM cost is worth it for a single keypress, especially since the sort tags patch could allow you to have your albums in year order anyway.

This should be done solely using the tagnavi imo.
Currently, it seems that there's a limitation so that only the track views can be formatted. This limitation should be resolved, so that a fomatted album name like
"%format "fmt_album" "(%4d) %s" year album" works too. This would be a nice implementation of year album, which also adds the possiblity to combine everything with everything.

This can't be done with the current implementation of the database as it would require the equivalent of an Sql group-by clause. There is some discussion in the forum post (linked to in the FS entry) about it.

The problem with this patch is it passes the cost of adding this feature entirely on to users who don't use it by inflating the database size. Some other solution needs to be found, because otherwise its cost is a good deal larger than what it offers, in a practical sense. People can already organize their filetree this way, and their database can *nearly* be accessed this way (by filtering year, then album, meaning this only really simplifies the display). It's just really not a good "cost vs gain" at all.

I am not arguing for svn inclusion (I don't use it myself and only did it as a favour to someone at the forums). I am only pointing out that the idea to do it via the tagnavi, as appealing as it might seem to the user, requires some redesigning of how the database works internally and is not just a matter of adding a format string.

Ah, well if this patch isn't a candidate for SVN inclusion, it should be closed as per tracker policy.

Hence I said the limitation should be resolved.

Thanks Paul for your clarification about svn inclusion for this patch.

I wonder if another tracker could be set up for patches like this one that people use, but are not candidates for SVN (the "ignore the" patch also comes to mind).

You don't need to post the same message more than once.

If you want to start your own unofficial tracker, nobody's stopping you.