soulsync/tests/imports
Broque Thomas 486116c34f Honor lossy_copy.delete_original after successful conversion
Reported case (CAL): with lossy_copy.enabled=True,
lossy_copy.delete_original=True, and codec=mp3, every download left
both the original FLAC AND the converted MP3 in the target folder.
Users opting into a lossy-only library ended up dual-format on
every import.

Root cause: ``core/imports/file_ops.py:create_lossy_copy`` reads
``lossy_copy.codec`` and ``lossy_copy.bitrate`` from config but never
reads ``lossy_copy.delete_original``. The setting is only consulted
by the pre-move source-vanished check at
``core/imports/pipeline.py:651`` (so the pipeline knows to look for
a lossy variant when the FLAC has already moved on), but no code
path actually deletes the source after conversion.

Fix: after ffmpeg returns success and the QUALITY tag is written,
check ``lossy_copy.delete_original`` and ``os.remove`` the original
when enabled. Belt-and-suspenders:

- Same-path guard (``os.path.normpath(out_path) != os.path.normpath(final_path)``)
  prevents accidentally wiping the just-converted file if a future
  codec choice somehow resolves out_path to the source path.
- ``FileNotFoundError`` is treated as success (concurrent worker /
  dedup cleanup got there first).
- Other ``OSError`` (permission denied, locked file) is logged but
  doesn't propagate — the conversion already succeeded, the user just
  has to clean up the original manually.

Failure paths skip the delete:
- ffmpeg returns non-zero → returns None, original stays
- lossy_copy.enabled=False → early return before conversion runs
- delete_original=False (default) → original stays

7 regression tests cover honored-when-enabled, kept-when-disabled,
default-keep, ffmpeg-failure-path, lossy-disabled-path, racing-delete,
and locked-file paths. Full pytest 1563 passed; ruff clean.

Note: this PR does NOT address the second bug CAL mentioned (track
re-downloaded despite already existing on disk). That symptom is
caused by stale album metadata on the user's existing files — the
library DB has the track tagged on a different album than the
metadata source reports — combined with wishlist.allow_duplicate_tracks
defaulting to True. Same class of issue partially addressed in PR
fix/watchlist-redownload-and-duplicate-detection but compilation-
album drift is the only currently-handled case. Tracking separately.
2026-05-02 14:26:46 -07:00
..
test_dedup_orphan_cleanup.py Prune slskd dedup orphans after import 2026-05-01 09:35:08 -07:00
test_import_album.py Rehome import helpers into core/imports 2026-04-27 19:54:44 +03:00
test_import_context.py Fix Spotify source ID fallback 2026-05-02 22:02:01 +03:00
test_import_file_ops.py Broaden import and metadata test coverage 2026-04-27 19:55:07 +03:00
test_import_filename.py Rehome import helpers into core/imports 2026-04-27 19:54:44 +03:00
test_import_guards.py Rehome import helpers into core/imports 2026-04-27 19:54:44 +03:00
test_import_paths.py fix: substitute \$cdnum in download paths and skip auto disc folder when template uses it 2026-04-28 21:32:24 -07:00
test_import_pipeline.py Move single-track resolver; fix wishlist cleanup 2026-04-27 19:55:06 +03:00
test_import_resolution_single_track_context.py Move metadata helpers into package modules 2026-04-29 11:28:42 +03:00
test_import_side_effects.py Fix Spotify source ID fallback 2026-05-02 22:02:01 +03:00
test_import_singles_route_through_album_path.py Route imported singles/EPs through album_path template 2026-04-30 21:33:09 -07:00
test_import_staging.py Rehome import helpers into core/imports 2026-04-27 19:54:44 +03:00
test_lossy_copy_delete_original.py Honor lossy_copy.delete_original after successful conversion 2026-05-02 14:26:46 -07:00