Problem:
- PlaylistSource reads cached files faster than FlacCacheSink writes them
- FLAC decoder encounters EOF and stops playback prematurely
- First track doesn't play completely (stops at prebuffer point ~600ms)
- Needed to differentiate:
* Temporary EOF: file still being written (wait and retry)
* Real EOF: file completely written (stop decoding)
Solution:
1. Added Cache::is_download_complete() method (pmocache/src/cache.rs:735)
- Checks for existence of completion marker (.complete file)
- Marker created only when file is fully written and closed
- Fast synchronous check (no async overhead)
2. Modified decode_and_emit_track() (playlist_source.rs:337)
- On EOF: check if completion marker exists
- If no marker: file still being written → wait 50ms and retry read
- If marker exists: file complete → finish decoding
- Reduced wait from 100ms to 50ms for better responsiveness
Benefits:
✅ First track now plays completely (not just prebuffer portion)
✅ Progressive caching still works (playback starts at ~600ms)
✅ Proper EOF handling (no premature stops)
✅ Efficient polling (50ms retry interval)
✅ Works for both fresh downloads and cached files
Tested:
- Fresh download: EOF retries visible in logs every ~50ms
- File plays until completion marker created
- No premature track termination
Related to previous optimization (commit d8594e7) that made
prebuffer→playlist push immediate (76ms instead of 19s).
Critical Bug Fixed:
Files between 512 and 1024 bytes (e.g., small images) were incorrectly
handled. The condition `header.len() > 512` would skip the first 512
bytes even for small files, using only a tiny portion for pk calculation.
Example Bug:
- PNG image of 700 bytes
- header.len() = 700
- 700 > 512 = TRUE
- Used &header[512..] = only 188 bytes (octets 512-700)
- SKIPPED important PNG header and image data!
Solution:
Changed condition from `> 512` to `>= 1024`:
- Files < 1024 bytes → use ALL content (correct for images)
- Files >= 1024 bytes → skip first 512 bytes (correct for FLAC)
Impact:
- pmocovers cache now works correctly with small images
- No more data loss for files between 512-1024 bytes
- FLAC behavior unchanged (still skips header correctly)
Problem Analysis:
- All FLAC files had the same pk (071c5713d5cf485ca688832207bef0f9)
- Root cause: read() can return < 1024 bytes on first call
- If read returned only 400 bytes:
* header.len() = 400
* 400 > 512 = false
* Used header[..] (first 400 bytes = FLAC header)
* All FLAC files have identical headers → same pk!
Solution:
- Added read_exact_or_eof() that loops until 1024 bytes read (or EOF)
- Guarantees we skip FLAC header and use actual audio content
- Works for small files (< 512 bytes) and large files (>= 1024 bytes)
Additional Feature:
- Added AudioSink::with_null_output() for testing without audio device
- Added --null-audio flag to play_and_cache example
- Allows testing in containerized environments
Changes:
1. pmocache/src/download.rs: Added read_exact_or_eof()
2. pmocache/src/cache.rs: Use read_exact_or_eof() for pk calculation
3. pmoaudio/src/nodes/audio_sink.rs: Added null output mode
4. pmoparadise/examples/play_and_cache.rs: Added --null-audio flag
Test Results:
- New pk: 83702c1cbca72074ebf7c123336786ea (was 071c...)
- Null audio output works correctly
- Ready for full testing
Simplified the FLAC pk collision fix to work uniformly for all files:
- Always read up to 1024 bytes (or whatever is available)
- Use at most the last 512 bytes for pk calculation
This approach works correctly for:
- Small files (< 512 bytes, e.g., tiny images): uses all content
- Medium files (512-1024 bytes): uses bytes after 512
- Large files (>= 1024 bytes, e.g., FLAC): uses bytes 512-1024
No special detection needed - the algorithm adapts automatically.
Fixes potential issues with small images in pmocovers cache.
Problem: All FLAC files with the same format (44.1kHz, stereo, 16-bit)
had identical headers and thus the same pk (071c5713d5cf485ca688832207bef0f9).
This caused the cache to think all tracks were the same file, regardless
of channel selection or actual content.
Solution: Skip the FLAC header (first 512 bytes) and calculate the pk
from bytes 512-1024 (actual audio content) instead. This ensures each
track gets a unique pk based on its actual audio data, not just its
format header.
Changes:
- Modified add_from_reader_with_pk() to read 1024 bytes instead of 512
- Use bytes 512-1024 for pk calculation when explicit_pk is None
- This works even with poor metadata (empty artist/title)
- Maintains backward compatibility with explicit_pk parameter
Fixes the issue where changing radio channel played the same song.
- Add .complete marker files to track completed downloads
- Check marker instead of file size for completion detection
- Drain segments when file already in cache to avoid pipeline errors
- Consolidate() now removes incomplete files without markers
- Add new_cache_with_consolidation() for automatic cleanup on startup
## Corrections de bugs
- **CRITIQUE**: Correction du bug SQL dans `pmocache/src/db.rs:get_oldest()`
- La requête référençait des colonnes inexistantes (`source_url`, `metadata_json`)
- Corrigé pour utiliser les bonnes colonnes de la table `asset` (`id`)
## Refactoring et simplifications
- **Factorisation majeure** dans `pmocache/src/cache.rs`:
- Extraction de 3 méthodes helpers pour éliminer ~90 lignes de code dupliqué
entre `add_from_url()` et `add_from_reader()`:
- `check_cached_and_complete()`: vérification cache et intégrité
- `check_ongoing_download()`: gestion des téléchargements en cours
- `finalize_download()`: finalisation avec prébuffering et nettoyage
- Les deux méthodes sont maintenant beaucoup plus lisibles et maintenables
- **Simplification** de `enforce_limit()`:
- Utilisation de `get_file_paths()` au lieu d'itérations manuelles complexes
- Suppression des boucles imbriquées pour une logique plus claire
- **Correction** d'import manquant: ajout de `AsyncReadExt` dans `cache.rs`
## Tests complets ajoutés
### pmocache (27 tests)
- `tests/test_db.rs`: 24 tests couvrant toutes les opérations DB
- CRUD de base (add, get, delete, purge)
- Gestion des métadonnées (tous types JSON)
- Collections (get_by_collection, delete_collection)
- LRU et éviction (get_oldest, count)
- URLs d'origine (set_origin_url, get_origin_url)
- Indexation par (collection, id)
- `tests/test_cache.rs`: 16 tests d'intégration du cache
- Ajout depuis fichier, reader, URL
- Déduplication basée sur contenu
- Collections et gestion
- Éviction LRU automatique
- Purge et consolidation
- Métadonnées et touch
- Prébuffering et téléchargements
### pmoaudiocache (4 tests)
- `tests/test_cache.rs`: Tests spécifiques audio
- Création et configuration
- Collections d'albums
- Éviction LRU avec limite
### pmocovers (6 tests)
- `tests/test_cache.rs`: Tests de cache d'images
- Conversion WebP automatique
- Déduplication d'images identiques
- Gestion de collections
- Éviction LRU
- `tests/test_webp.rs`: Tests du module WebP
- Encodage WebP depuis différents formats
- Redimensionnement carré avec préservation du ratio
- Génération et mise en cache de variantes
- Tests avec différentes tailles (portrait, landscape, carré)
## Améliorations de la couverture
- Passage de **0 test** à **37 tests** au total
- Ajout de `tempfile = "3"` comme dev-dependency dans `pmocache/Cargo.toml`
- Couverture des cas nominaux et des cas limites
- Tests d'intégration et unitaires
## Préservation des APIs
- ✅ Aucune API publique n'a été modifiée ou cassée
- ✅ Toutes les fonctions helpers sont privées (non exposées)
- ✅ Les signatures publiques restent identiques
- ✅ Rétrocompatibilité totale garantie
Problème :
Les fichiers déjà en cache (d'exécutions précédentes interrompues) étaient
considérés comme valides même s'ils étaient incomplets. Cela causait des
erreurs "FLAC decode error: Expected one more byte" lors de la lecture.
Solution :
Vérifier la taille du fichier en cache et la comparer avec min_prebuffer_size.
Si le fichier est trop petit (< 512 KB), il est supprimé et sera re-téléchargé/
ré-ingéré avec le bon prébuffering.
Changements :
- add_from_url() : vérifie file_size >= min_prebuffer_size pour les fichiers
déjà en cache
- add_from_reader() : même vérification
- Si fichier trop petit : suppression et re-download/re-ingest
- Log warning explicite quand un fichier incomplet est détecté
Résultat :
✓ Les fichiers incomplets en cache sont détectés et re-téléchargés
✓ Garantit que les fichiers ont au minimum 512 KB (environ 5 secondes)
✓ Évite les erreurs de décodage sur des fichiers partiels
Problème :
Après la correction de la race condition précédente, les fichiers étaient créés
sur disque mais la lecture commençait immédiatement, avant qu'il y ait
suffisamment de données. Cela causait des erreurs FLAC "Expected one more byte"
car le décodeur essayait de lire un fichier incomplet.
Solution - Prébuffering :
Attendre qu'une quantité minimale de données (512 KB par défaut, ~5 secondes de
FLAC) soit téléchargée avant que add_from_url() et add_from_reader() retournent
le pk. Cela permet au cache progressif de fonctionner correctement : le fichier
a suffisamment de données pour commencer la lecture pendant que le téléchargement
continue en arrière-plan.
Changements :
- Ajout d'un champ min_prebuffer_size dans Cache<C> (défaut: 512 KB)
- Ajout de méthodes set_prebuffer_size() et get_prebuffer_size()
- Ajout de la constante DEFAULT_PREBUFFER_SIZE (512 KB)
- Modification de add_from_url() : utilise wait_until_min_size()
- Modification de add_from_reader() : utilise wait_until_min_size()
- Cas où download déjà en cours : attend également le prébuffering
Résultat testé :
✓ L'exemple play_and_cache fonctionne sans erreur FLAC
✓ Le prébuffering garantit suffisamment de données avant la lecture
✓ Le cache progressif fonctionne : lecture pendant le téléchargement
✓ Configurable : peut être ajusté selon les besoins (0 = désactivé)
Problème :
Les fonctions add_from_url() et add_from_reader() retournaient le pk
immédiatement après avoir lancé l'ingestion en arrière-plan, mais AVANT
que le fichier soit créé sur disque. Cela causait une erreur "Cache entry
not found" quand la playlist appelait is_valid_pk() qui vérifie que le
fichier existe.
Solution :
Attendre (jusqu'à 5 secondes max) que le fichier soit créé sur disque
avant de retourner le pk. Cela permet au cache progressif de fonctionner
correctement : le fichier existe et peut commencer à être lu pendant que
le téléchargement continue en arrière-plan.
Changements :
- add_from_url() : attente de la création du fichier avant retour
- add_from_reader() : attente de la création du fichier avant retour
- Cas où download déjà en cours : attente également de la création du fichier
Résultat testé :
✓ L'exemple play_and_cache fonctionne maintenant sans erreur
✓ Le pipeline de download se termine avec succès
✓ Les pistes sont correctement ajoutées à la playlist
