Area
Import / Collection Import
Description
I'd like to propose reconsidering the user experience and architecture of Mylar3 migration independently of the specific bugs reported in:
[BUG ISSUE URL]
I think there are two separate concerns here:
- Migrating an existing library from Mylar3 into Pullbox
- Validating, refreshing, and enriching that library against ComicVine
At the moment those appear to be part of the same critical-path workflow.
As a result, a user can provide Pullbox with an established Mylar database containing known ComicVine identities, Pullbox can successfully identify those series, but the user still cannot complete the migration until extensive remote issue-level reconciliation has taken place.
That creates a difficult migration experience for a substantial existing library.
In my case, all 463 series were identified successfully from their Mylar ComicVine IDs in approximately 13 seconds. The subsequent issue/file reconciliation then ran for hours, made hundreds of ComicVine requests, encountered HTTP 420 responses, and paused.
I resumed after the first provider-degraded pause. Pullbox then spent approximately another 67.5 minutes processing only 4 additional series and 106 files before entering provider_degraded again. Almost all of that time was spent building issue target indexes rather than evaluating the files themselves, and many of the same failed ComicVine lookups were retried.
After approximately 10 hours of processing, Pullbox was still estimating approximately another 32 hours to completion. At that point I stopped the migration because I was not down with a multi-day import.
I consider the performance problem in the linked issue a bug, but I think the larger question deserves separate UX/product-design consideration.
Even if the current matching process were made substantially faster and the rate-limit handling were fixed, I'm not sure that blocking migration on metadata reconciliation is the right experience.
Use Case
The distinction for me as a user is between importing an unknown folder of comic files and migrating an established library from another comic manager.
If I choose "Scan a folder", I expect Pullbox to need to determine what those files are.
If I choose "Import from Mylar3", I am providing an existing database whose purpose includes maintaining those identities and relationships.
My expectation as a migrating user is therefore approximately:
- Pullbox reads the existing Mylar state.
- Pullbox tells me what it was able to import confidently.
- I approve the migration.
- My library becomes available in Pullbox.
- Pullbox refreshes or validates metadata in the background.
- Genuine exceptions are surfaced for me to resolve later.
Instead, the present experience is closer to:
- Read Mylar.
- Correctly identify the existing library.
- Begin a potentially very long remote reconciliation operation.
- Block migration while that work happens.
- Potentially pause because the remote metadata provider is unavailable.
- Require the user to manually resume and potentially enter the same provider-bound reconciliation cycle again.
- Require the user to wait before they can actually use the migrated library.
This is particularly frustrating because the first part demonstrates that Pullbox already knows a great deal about the source library.
For an established collection, I don't need every piece of external metadata to be freshly validated before I can start using Pullbox.
I would rather have a usable migrated library with:
"17 files need review"
"Metadata refresh in progress"
than wait hours for a migration whose primary work is already known.
In my actual migration, I stopped the process after approximately 10 hours because Pullbox was still estimating approximately 32 additional hours. I therefore never reached the point where I could actually evaluate Pullbox with my migrated library.
Proposed Solution
I don't want to prescribe a particular implementation, but I think the UX would benefit from separating migration from reconciliation.
One possible model:
PHASE 1 — MIGRATE KNOWN STATE
- Read Mylar series and issue identities.
- Preserve known ComicVine IDs and file relationships.
- Show any genuinely unresolved source records.
- Allow the user to approve the migration.
- Copy/import the files.
- Make the Pullbox library usable.
This phase should depend primarily on local source data and filesystem access, not on continuous availability of ComicVine.
PHASE 2 — BACKGROUND METADATA RECONCILIATION
After the library exists in Pullbox:
- Refresh metadata from ComicVine asynchronously.
- Respect ComicVine rate limits without delaying library availability.
- Retry transient provider errors in the background.
- Apply safe metadata updates automatically.
- Preserve source/provenance information so Pullbox knows whether an identity came from Mylar, ComicVine verification, filename inference, etc.
PHASE 3 — EXCEPTION / REVIEW QUEUE
Only cases genuinely requiring user judgment should interrupt the user:
- an imported ComicVine ID no longer resolves
- conflicting identities
- ambiguous files
- Annuals/specials that cannot be assigned automatically
- files with no usable identity
- other metadata discrepancies
These could appear in a persistent review queue that the user can resolve on their own time.
Importantly, an unresolved individual file should not make an otherwise correctly imported series unusable.
A possible UI might look something like:
Ready to import
463 series identified
3,8xx comic files found
17 files need review
[Import Library]
[x] Refresh ComicVine metadata after import
After import:
Migration complete
463 series imported
17 files need review
ComicVine metadata refresh
1,291 / 3,842 complete
Running in background
[Browse Library] [Review Issues]
Ultimately, the important bit about the UX is that optional or recoverable metadata work should not prevent the user from completing the primary task they initiated: migrating their existing library.
Alternatives Considered
- Keep the current workflow but improve ComicVine rate limiting/retries.
This would reduce the immediate pain, but it would still make migration time and availability dependent on an external service. A large migration could still take a very long time even if every request succeeds.
The repeated pause/resume behavior in my migration also suggests that better retry handling alone would not necessarily solve the underlying experience. After resuming, Pullbox spent another hour in provider-backed reconciliation and then paused again.
- Increase concurrency.
ComicVine itself is rate limited, so increased local concurrency does not solve the underlying UX problem and could make provider throttling worse.
- Add a "skip ComicVine validation" advanced option.
This would help, but I think it exposes an implementation detail rather than addressing the user workflow. A migrating user should not need to understand why a metadata API is blocking the transfer of known local state.
- Keep strict pre-import validation as an optional mode.
There may absolutely be users who prefer:
"Validate everything before importing"
That could remain available.
My suggestion is simply that it should not be the only migration model. For most migration use cases, I think "import first, reconcile afterward" provides a much more resilient and understandable experience.
Area
Import / Collection Import
Description
I'd like to propose reconsidering the user experience and architecture of Mylar3 migration independently of the specific bugs reported in:
[BUG ISSUE URL]
I think there are two separate concerns here:
At the moment those appear to be part of the same critical-path workflow.
As a result, a user can provide Pullbox with an established Mylar database containing known ComicVine identities, Pullbox can successfully identify those series, but the user still cannot complete the migration until extensive remote issue-level reconciliation has taken place.
That creates a difficult migration experience for a substantial existing library.
In my case, all 463 series were identified successfully from their Mylar ComicVine IDs in approximately 13 seconds. The subsequent issue/file reconciliation then ran for hours, made hundreds of ComicVine requests, encountered HTTP 420 responses, and paused.
I resumed after the first provider-degraded pause. Pullbox then spent approximately another 67.5 minutes processing only 4 additional series and 106 files before entering provider_degraded again. Almost all of that time was spent building issue target indexes rather than evaluating the files themselves, and many of the same failed ComicVine lookups were retried.
After approximately 10 hours of processing, Pullbox was still estimating approximately another 32 hours to completion. At that point I stopped the migration because I was not down with a multi-day import.
I consider the performance problem in the linked issue a bug, but I think the larger question deserves separate UX/product-design consideration.
Even if the current matching process were made substantially faster and the rate-limit handling were fixed, I'm not sure that blocking migration on metadata reconciliation is the right experience.
Use Case
The distinction for me as a user is between importing an unknown folder of comic files and migrating an established library from another comic manager.
If I choose "Scan a folder", I expect Pullbox to need to determine what those files are.
If I choose "Import from Mylar3", I am providing an existing database whose purpose includes maintaining those identities and relationships.
My expectation as a migrating user is therefore approximately:
Instead, the present experience is closer to:
This is particularly frustrating because the first part demonstrates that Pullbox already knows a great deal about the source library.
For an established collection, I don't need every piece of external metadata to be freshly validated before I can start using Pullbox.
I would rather have a usable migrated library with:
than wait hours for a migration whose primary work is already known.
In my actual migration, I stopped the process after approximately 10 hours because Pullbox was still estimating approximately 32 additional hours. I therefore never reached the point where I could actually evaluate Pullbox with my migrated library.
Proposed Solution
I don't want to prescribe a particular implementation, but I think the UX would benefit from separating migration from reconciliation.
One possible model:
PHASE 1 — MIGRATE KNOWN STATE
This phase should depend primarily on local source data and filesystem access, not on continuous availability of ComicVine.
PHASE 2 — BACKGROUND METADATA RECONCILIATION
After the library exists in Pullbox:
PHASE 3 — EXCEPTION / REVIEW QUEUE
Only cases genuinely requiring user judgment should interrupt the user:
These could appear in a persistent review queue that the user can resolve on their own time.
Importantly, an unresolved individual file should not make an otherwise correctly imported series unusable.
A possible UI might look something like:
After import:
Ultimately, the important bit about the UX is that optional or recoverable metadata work should not prevent the user from completing the primary task they initiated: migrating their existing library.
Alternatives Considered
This would reduce the immediate pain, but it would still make migration time and availability dependent on an external service. A large migration could still take a very long time even if every request succeeds.
The repeated pause/resume behavior in my migration also suggests that better retry handling alone would not necessarily solve the underlying experience. After resuming, Pullbox spent another hour in provider-backed reconciliation and then paused again.
ComicVine itself is rate limited, so increased local concurrency does not solve the underlying UX problem and could make provider throttling worse.
This would help, but I think it exposes an implementation detail rather than addressing the user workflow. A migrating user should not need to understand why a metadata API is blocking the transfer of known local state.
There may absolutely be users who prefer:
That could remain available.
My suggestion is simply that it should not be the only migration model. For most migration use cases, I think "import first, reconcile afterward" provides a much more resilient and understandable experience.