Archive number not calculated correctly

[Срђан Хрњак]

First disk I tried to index with Basenji had difficulties during readig and kept crashing app, but Archive number counter inceased even the indexing process wasn't finished, and folders was created in .config/Basenji/dbdata
I tried to delete those folders but it didn't help. The counter is still off by 4 (I tried to index corrupted disk 4 times).
When I manually change archive number, the number in folder name remains the same. Also, there is no restrictions for using same archive number for different volumes.

[Patrick Ulbrich (pulb)]

The archive number is just a number (or a label) a user can assign to a disks so the disk can be found quickly in a cd rack (http://www.comparestoreprices.co.uk/images/oa/oak-solid-oak-dual-cd-rack.jpg)
By default this archive number is a copy of the internal disk id. When a disk is deleted (or scanning failed), this counter will not be decremented. You can give a disk any archive number, you can even leave it blank, it will never conflict with the internal id.

Regarding the crash, please run Basenji from the commandline with the --debug option and post the output here. My guess it's again a libextractor issue. libextractor it the current metadata backend and will be replaced by taglib in the next release (there is a bzr branch already).

[Срђан Хрњак (srdjan-hrnjak)]

I already reported bug for that crash.
The annoying thing about this Counter is that I have to manually change it on every volume instead of some kind of button or option to reset counter or renumber volumes based on current sorting in list.

[Patrick Ulbrich (pulb)]

Oh, that was you :-)
Yeah, thats a libextractor problem. Since you're building from source anyway I'd recommend building from the new taglib-branch. I'll merge the new 0.8 features into this branch tomorrow and point you to the bzr location.

I'm not sure about the archive number thing though. It is not meant to be a counter, it's just an id to identify the disk in an archive rack. Do you mind leaving the IDs as they were proposed? What about adding a settings option to show this field blank by default?

[Срђан Хрњак (srdjan-hrnjak)]

It's rather convenient option since my disks are numbered and it would be easier with proper counter. Could you implement something like volume name template with customizable counter instead? All my music disks have "MP3" for label and I have to manually edit Volume name in basenji. I think of something like {name template} {counter} with options to set default name template that will be used and "start from" and "number of digits" for counter options. That way I could name my volumes {MP3 Albums #} {01,02,03...} and easily change to {MP3 Compilations #} {01,02,03...} regardless of archive number ID.

[Patrick Ulbrich (pulb)]

Your usecase is a typical automatisation / batch processing scenario, so I think this option would be better implemented in the volumedb-scanner-daemon. This stuff is too complicated for the Basenji GUI which should be as simple as possible.
All the your other feature requests you reported look quite interesting, the problem is I am the only developer and have other tasks with higher priority (like the taglib-sharp migration) on my TODO list. So I simply mark your reports as "wishlist" for now.

Speaking of taglib, the basenji-taglib branch is ready now. Its far more stable as the current libextractor branch. You shouldn't get any more crashes using this branch. You can check it out via "bzr branch lp:~pulb/basenji/basenji-taglib" and compile it as usual.

[Срђан Хрњак (srdjan-hrnjak)]

Sorry if I'm annoying :) I just found this program, and it is something I looked for very long time. It's OK if some of my suggestions are never to be implemeted, I just wanted to share my opinion. This app is very useful as it is now.
I have almost completed indexing my disks, none of my requests are important, wishlist is just fine.
Today I installed Natty on my laptop, so it should be easier to track changes on daily PPA without need for compiling.

[Patrick Ulbrich (pulb)]

You're surely not anoying me, I'ts always great to get some user feedback.
I just wanted to point out that implementing features could take some time :-)