BTW, I was thinking on the road... I left that track bug with a note how I'm
looking into it. I can't quite figure out what to do to solve it.
It's actually pretty dire. Tracks 1-10, you delete track 3, so there's no
more 3. You can't add a new track ever again after that, and you get to Core
Dump Junction pretty quick if you try. It's no simple matter to hand edit
the XML either, because segments are associated with track IDs, and there is
a lot to sort out to repair a corrupted file. It leaves the file pretty
fucked, and it's extremely easy to run into this land mine. It's probably
dire enough to demand holding off 1.0.
All I can think of is to tackle it at the add-new-track side. Have it skip
over the hole and add a new track past the last ID. It seems shuffling the
IDs to avoid the hole in the first place is much harder.
This is probably too serious to wait until I can figure it out. I haven't
even had a chance to look into the code.
Michael McIntyre ---- Silvan <dmmcintyr@...>
Linux fanatic, and certified Geek; registered Linux user #243621
From: Chris Cannam <cannam@al...> - 2004-11-24 16:42:04
On Tuesday 23 Nov 2004 03:06, Silvan wrote:
> It's actually pretty dire. Tracks 1-10, you delete track 3, so
> there's no more 3. You can't add a new track ever again after that
You're right, that's nasty.
What confuses me is that although the Add New Track appears on the undo
list, there's nothing at all created and saved in the XML -- it's not
just a refresh problem, it actually fails silently. It doesn't seem
possible for it to do that; on first glance at the implementation of
the command, it should either succeed or throw an exception.
From: Chris Cannam <cannam@al...> - 2004-11-24 16:46:31
On Wednesday 24 Nov 2004 16:53, Chris Cannam wrote:
> it actually fails silently. [...] on first glance at the
> implementation of the command, it should either succeed or throw an
Duh, the exception throw() is commented out.