Hi James,
we've had a similar headline back in late 2012 during a merge operation done by Robby Pählig (http://forums.qrecall.com/posts/list/429.page#2023).
Now I'm encountering this message while trying to run a capture item. I'm unsure if the two problems are related but wanted to point it out in case it might help your analysis.

It makes no difference if I start the action through the scheduler or on the command line, or type a direct command mimicking the capture action's actions. --deep and/or --nodedup don't make a difference, too. The target archive has been successfully verified last weekend, it has never been merged or compacted because it's still trying to finish for the first time. (The capture action is set to stop after ten hours so it's done before the NFS lease expires)

It will only say "Starting", "Opening archive", "Stopping" and abort saying
"* capture process failed: -[NSConcreteMutableData filter]: unrecognized selector sent to instance 0x?"

I've sent a report, hoping I've put enough info there and here so you can link the two.

Norbert,

The problem is pretty obscure, and appears to be either legacy or corrupted data in your archive's settings file.

Specifically, the data that describes which items should always be excluded can't be decoded for some reason (the log isn't that detailed).

This should fix it:

Open the archive.

To go to the Archive > Settings, select and delete all of the excluded items. Save the changes.

Open Archive > Settings again, and add back in all of the items you want excluded. Save the changes.

The capture should now run.

If any of that didn't work (the same bug might cause the settings dialog to malfunction), you can fix the problem surgically, following these instructions.

Close the archive.

Using a plain text editor (from the Terminal if you're comfortable with that, or something like BBEdit or TextWrangler), open the settings.plist file inside your archive package. In it, you'll see a definition for your excluded items that will look like this:

<key>ExcludeFilter</key>

<data>

YnBsaXN0MDDUAQIDBAUGWFlYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3AS

AAGGoK8QFQcIERUcICQrMDM2OTxAREVLTE1OUlUkbnVsbNQJCgsMDQ4PEFdmaWx0ZXJz

...

XA18DY8NoQ2kDakAAAAAAAACAQAAAAAAAABcAAAAAAAAAAAAAAAAAAANqw==

</data>

Delete these lines, save the file, and return to the previous instructions to add your excluded items back to the archive.

Here I am again, sorry for having taken my time.
I've removed any ExcludeFilter settings from all my archives and switched to use 'qrecall captureprefs exclude [?]' instead of setting exclusions inside the archives for all exclusions on my own volumes.

It kind of worked, yet, still didn't? Anyhow, this looks increasingly strange?

After deleting the exclusion data I could access the archive again which is a good thing. I was able to perform a couple of captures, a rolling merge, another couple of captures, and after the next compact action the archive wouldn't verify anymore. It was easy (if lengthy) to repair, but ever since the state of things has been the same: captures and merges work fine, compact actions will reliably cause the next verify to fail and mark the archive as broken, even though without running a verify action I can keep capturing, merging and compacting without any trouble. To phrase the same thing from a different angle: after a repair the archive will verify fine until the first compact action is run. After that, it can be used without issue as long as no verify action is run as that will flag the archive as broken. I'm not sure if compact actually breaks something that nobody but verify cares about, if verify is over-zealous about something it shouldn't concern itself with, or if each of the two is doing right but they just don't have the same understanding of how an archive should look like.

I have tried moving my volume history to a new archive using a repair action, but the "curse" was copied over as well.

Here's what I do on the example of a short-term dev repository:

qrecall repair work.medium.quanta --recover work.repaired.quanta -o noautorepair -o lostfiles --monitor

|-        -|

mv work.repaired.quanta/ work.medium.quanta

vi work.medium.quanta/settings.plist # remove any ExcludeFilter entries possibly present

qrecall capture work.medium.quanta/ --deep --monitor /Volumes/work/

|-        -|

qrecall verify work.medium.quanta # will be fine

|-        -|

qrecall merge work.medium.quanta --monitor --layers keep=30d

|-        -|

qrecall verify work.medium.quanta # will be fine

|-        -|

qrecall compact work.medium.quanta --monitor

|-        -|

qrecall verify work.medium.quanta --monitor # this is going to fail

|-        -|

* verify process failed: unhashed data package missing from index

I can live with remembering to always run a verify-repair loop after ever compact action, I do them only once in three months anyway. Even this I could speed up by just "repair --recover"ing, deleting the old and renaming the new archive so it reads through the whole thing only once.

What bugs me the most is that this is only affecting two of my archives. All the others behave just fine. I can't find the difference between these two and the rest for the dear life of me. Am I to leave these archives dormant and start new ones with the same settings, splitting volume history over two repositories? Or should I turn to use repair actions instead of verify actions?

Any ideas?

little follow-up.

I've noticed while checking the settings dialogs that for all of my archives data redundancy was disabled. I'm very sure that I've always had this set to 1:16, and I take that confidence from the fact that upon creation of a new archive 1:8 is recommended as the default and I always manually lowered it to be 1:16 instead.
Is it possible that the same upgrade that thrashed the exclude filters in the settings.plist's also clobbered the correction code level? I've re-set the redundancy option everywhere and had QRecall re-create the data, then retried going through the motions. No effect. The two "cursed" archives are still being flagged as broken every time they're verified if a compact action had been performed after the last repair, even if that compact action didn't actually do anything.

Don't know if that piece of info is worth anything, but I didn't want to risk having found some clue and and not sharing it.

Norbert Karls wrote:

qrecall verify work.medium.quanta --monitor # this is going to fail

|-        -|

* verify process failed: unhashed data package missing from index

OK, there's probably a bug in the compact action. I'm not sure what, but I need to start with the details so please send a diagnostic report (in the QRecall app choose Help > Send Report). I might need more info later, but I need that to get started.

From what you've posted, I can at least tell you what's going wrong, even though I don't know why. The "unhashed data package missing from index" error means that you have an un-de-duplicated data quanta that has been captured but not yet de-duplicated (using the "defer de-duplication" capture option). But for some reason, that data record is not included in the un-hashed quanta index table. That's very weird, because the repair should fix that and any subsequent compact should then de-dup the quanta in that table. But clearly something is going wrong here, so the diagnostic will help me start an investigation.

So this probably explains why this only happens on some archives because you only have some capture actions which defer de-duplication.

For there record, this is a fairly benign problem[1]. It just means that the next compact action won't know to de-duplicate some of the capture data, which means your archive might contain duplicate quanta. The only side effect of this is that your archive may be larger than it needs to be.

The capture and merge actions still work because they don't touch un-de-duplicated data (that's been set aside of the compact to deal with). As a rule, specific actions verify only the data records and indexes they need to accomplish their task. The verify action verifies everything. That's why capture and merge still work, even when verify fails.

[1] QRecall has an extremely low tolerance for any kind of inconsistency. It might be a curse when dealing with seemingly trivial issues like this, but I prefer the "better correct than sorry" philosophy.

Norbert Karls wrote:Is it possible that the same upgrade that thrashed the exclude filters in the settings.plist's also clobbered the correction code level?

Not likely. While it's true that the redundancy preference is stored in a property file, QRecall refers to the actual redundancy companion files when determining if redundancy is available and how much. So once the redundant data files are created, it doesn't really matter what the settings file says they should be.

Conversely, if the data redundancy files are missing or malformed somehow, QRecall may determine that redundant data isn't available and will run with that assumption, even if the settings disagree.