Remove .serena folder from tracking and add to .gitignore

This commit is contained in:
Benjamin Slingo 2025-08-19 20:57:56 -04:00
parent 0c06e159bb
commit b150e08163
7 changed files with 3 additions and 413 deletions

3
.gitignore vendored
View file

@ -63,3 +63,6 @@ debug_*.sql
# Service files
*.service
# Serena AI assistant files
.serena/

View file

@ -1,82 +0,0 @@
# Church API Code Style & Conventions
## Rust Code Style
### Naming Conventions
- **Functions**: `snake_case` (e.g., `get_video_duration_direct`, `transcode_hls_segment_ffmpeg`)
- **Types/Structs**: `PascalCase` (e.g., `StreamingTranscodingService`, `ChunkStreamingService`)
- **Constants**: `SCREAMING_SNAKE_CASE` (e.g., `TS_PACKET_SIZE`, `NUM_PACKETS`)
- **Variables**: `snake_case` (e.g., `source_path`, `media_item_id`)
- **Modules**: `snake_case` (e.g., `streaming_transcoding`, `chunk_streaming`)
### File Organization
- **Handlers**: `src/handlers/*.rs` - HTTP request handling
- **Services**: `src/services/*.rs` - Business logic layer
- **Models**: `src/models/*.rs` - Data models and database entities
- **Utils**: `src/utils/*.rs` - Shared utility functions
- **DB**: `src/db/*.rs` - Database access layer
### Error Handling
- Uses custom `ApiError` type with `Result<T>` return type
- Comprehensive error mapping with `.map_err()` for external errors
- Structured error messages with context
### Logging Style
```rust
// Informational with emoji indicators
tracing::info!("🚀 Using CLI ffmpeg with Intel QSV AV1 hardware decoding");
tracing::info!("✅ Segment {} transcoded successfully", segment_index);
// Warnings
tracing::warn!("⚠️ Creating placeholder segment {}", segment_index);
// Errors
tracing::error!("❌ Failed to transcode segment {}: {:?}", segment_index, e);
// Debug information
tracing::debug!("🎬 FFmpeg command: {:?}", cmd);
```
### Async/Await Patterns
- Extensive use of `async`/`await` with Tokio runtime
- Proper error propagation with `?` operator
- Background task spawning with `tokio::spawn()`
### Documentation
- Function-level documentation for public APIs
- Inline comments for complex logic
- TODO comments for known improvements needed
## Architecture Patterns
### Service Layer Pattern
- Services handle business logic
- Handlers are thin and focus on HTTP concerns only
- Clear separation between web layer and business logic
### Error Handling Strategy
```rust
// Convert external errors to ApiError
.map_err(|e| ApiError::Internal(format!("Failed to run ffmpeg: {}", e)))?
```
### Resource Management
- Use of `Arc<RwLock<>>` for shared mutable state
- Semaphores for limiting concurrent operations
- Proper cleanup in GStreamer pipelines
### Configuration
- Environment variables used extensively (`std::env::var`)
- Sensible defaults provided
- Hardware acceleration detection and fallbacks
## Performance Considerations
- Hardware acceleration preferred (VA-API, Intel QSV)
- Chunked/streaming processing for large media files
- Caching of transcoded segments
- Concurrent processing limits to prevent resource exhaustion
## Dependencies Management
- Clear separation of concerns in Cargo.toml
- Comments explaining dependency purposes
- Both FFmpeg and GStreamer maintained during transition period

View file

@ -1,41 +0,0 @@
# Church API Project Overview
## Purpose
The Church API is a Rust-based web service designed for church media management and streaming. The primary functionality includes:
- **Media Management**: Upload, organize, and manage church sermons and media content
- **Video Streaming**: Provide intelligent video streaming with adaptive codec support (AV1, HEVC, H.264)
- **User Authentication**: JWT-based authentication system
- **Database Integration**: PostgreSQL database with SQLx for data persistence
- **Email Services**: Automated email functionality for church communications
## Tech Stack
- **Language**: Rust (2021 edition)
- **Web Framework**: Axum 0.7 with async/await (Tokio runtime)
- **Database**: PostgreSQL with SQLx 0.7
- **Media Processing**:
- GStreamer bindings (0.22) for high-performance streaming
- FFmpeg bindings (ffmpeg-next 7.0) - being replaced with GStreamer
- **Authentication**: JWT (jsonwebtoken) + bcrypt for password hashing
- **Logging**: tracing + tracing-subscriber for structured logging
- **Testing**: Built-in Rust testing framework
## Key Features
1. **Smart Video Streaming**: Detects client capabilities and serves optimal codec (AV1 direct, HEVC, or H.264 with transcoding)
2. **Hardware Acceleration**: Uses Intel QSV and VA-API for efficient video processing
3. **Chunk-based Streaming**: Netflix-style 10-second segments for smooth playback
4. **Caching System**: Intelligent caching of transcoded video segments
5. **HLS Support**: HTTP Live Streaming for maximum compatibility
## Architecture
- **Services Layer**: Business logic for transcoding, streaming, media scanning
- **Handlers Layer**: HTTP request handlers using Axum
- **Models Layer**: Data models and database entities
- **Utils Layer**: Shared utilities (codec detection, validation, etc.)
## Current Performance Focus
The project is actively migrating from FFmpeg CLI calls to native GStreamer bindings to:
- Eliminate subprocess overhead
- Reduce buffering and latency
- Improve hardware acceleration utilization
- Enable better error handling and resource management

View file

@ -1,114 +0,0 @@
# Church API Development Commands
## Core Development Commands
### Building & Testing
```bash
# Build the project
cargo build
# Build with release optimizations
cargo build --release
# Run tests
cargo test
# Run specific test module with output
cargo test images::tests -- --nocapture
# Check code without building
cargo check
# Format code
cargo fmt
# Run clippy linter
cargo clippy
```
### Running the Application
```bash
# Run in development mode (from src/main.rs)
cargo run
# Run the named binary
cargo run --bin church-api
# Run with environment variables
RUST_LOG=debug cargo run
```
### Database Management
```bash
# The project uses SQLx with PostgreSQL
# Migration files are likely in the migrations/ directory
# Check for database setup in .env files
```
### System Integration
```bash
# The project includes systemd service management
sudo systemctl restart church-api
sudo systemctl status church-api
# Logs can be viewed with
journalctl -fu church-api
```
### Media Processing
```bash
# The project uses both FFmpeg and GStreamer
# Check Intel Media Stack environment:
export LIBVA_DRIVER_NAME=iHD
export LIBVA_DRIVERS_PATH=/opt/intel/media/lib64
# Check hardware acceleration support
vainfo
intel_gpu_top
```
### Testing & Debugging Scripts
```bash
# Various test scripts are available:
./test.sh # General testing
./test_images.sh # Image processing tests
./test_media_system.sh # Media system tests
./comprehensive_test.sh # Full system tests
./server_debug.sh # Server debugging
# Church-specific scripts:
./church-api-script.sh # API management
./bible_verse.sh # Bible verse functionality
```
### File System Organization
```bash
# Uploads directory
ls -la uploads/
# Configuration
cat .env
cat .env.example
# Service files
ls -la *.service
# Migration and backup files
ls -la migrations/
ls -la backup_before_*/
```
### Development Workflow
1. Make changes to code
2. Run `cargo check` for quick syntax validation
3. Run `cargo test` to ensure tests pass
4. Run `cargo build` to compile
5. Test with relevant `test_*.sh` scripts
6. Deploy with `sudo systemctl restart church-api`
## Key Directories
- `src/` - Rust source code
- `migrations/` - Database migrations
- `uploads/` - Media file storage
- `templates/` - HTML templates
- `tests/` - Test files

View file

@ -1,108 +0,0 @@
# Task Completion Workflow
## When a coding task is completed, follow these steps:
### 1. Code Quality Checks
```bash
# Format the code
cargo fmt
# Run linter
cargo clippy
# Check for compilation errors
cargo check
```
### 2. Build & Test
```bash
# Build the project
cargo build
# Run tests
cargo test
# Run specific tests if relevant
cargo test module_name -- --nocapture
```
### 3. Media System Testing (if relevant)
```bash
# Test media processing
./test_media_system.sh
# Test image processing (if modified)
./test_images.sh
# Run comprehensive tests
./comprehensive_test.sh
```
### 4. Service Integration Testing
```bash
# Restart the service
sudo systemctl restart church-api
# Check service status
sudo systemctl status church-api
# View logs for errors
journalctl -fu church-api --lines=50
```
### 5. API Testing (if relevant)
```bash
# Test authentication
curl -X POST https://api.rockvilletollandsda.church/api/auth/login \
-H "Content-Type: application/json" \
-d '{"username": "admin", "password": "..."}'
# Test relevant endpoints with JWT token
# (Check fix_routes.sh for examples)
```
### 6. Performance Validation (for media changes)
- Check hardware acceleration is working:
```bash
vainfo
intel_gpu_top # During transcoding
```
- Monitor memory usage and CPU utilization
- Verify transcoding times are reasonable
- Check for memory leaks in long-running operations
### 7. Documentation Updates
- Update inline comments for complex changes
- Add tracing logs for new operations
- Update memory files if architecture changes
### 8. Final Checklist
- [ ] Code compiles without warnings
- [ ] Tests pass
- [ ] Service restarts successfully
- [ ] No memory leaks or resource exhaustion
- [ ] Hardware acceleration functional (if applicable)
- [ ] Logging provides adequate debugging information
- [ ] Error handling is comprehensive
## Critical Notes
### For Media/Streaming Changes:
- Always test with actual video files
- Verify both AV1 and H.264 codecs work
- Check HLS playlist generation
- Test with different client user agents
- Monitor segment caching behavior
### For GStreamer Integration:
- Ensure GStreamer initialization succeeds
- Test pipeline cleanup (no resource leaks)
- Verify hardware acceleration paths
- Check error handling for missing plugins
- Test with various input formats
### Performance Requirements:
- Transcoding should complete faster than real-time
- Memory usage should remain stable
- No blocking of other requests during transcoding
- Proper cleanup of temporary files and resources

View file

@ -1,68 +0,0 @@
# language of the project (csharp, python, rust, java, typescript, go, cpp, or ruby)
# * For C, use cpp
# * For JavaScript, use typescript
# Special requirements:
# * csharp: Requires the presence of a .sln file in the project folder.
language: rust
# whether to use the project's gitignore file to ignore files
# Added on 2025-04-07
ignore_all_files_in_gitignore: true
# list of additional paths to ignore
# same syntax as gitignore, so you can use * and **
# Was previously called `ignored_dirs`, please update your config if you are using that.
# Added (renamed)on 2025-04-07
ignored_paths: []
# whether the project is in read-only mode
# If set to true, all editing tools will be disabled and attempts to use them will result in an error
# Added on 2025-04-18
read_only: false
# list of tool names to exclude. We recommend not excluding any tools, see the readme for more details.
# Below is the complete list of tools for convenience.
# To make sure you have the latest list of tools, and to view their descriptions,
# execute `uv run scripts/print_tool_overview.py`.
#
# * `activate_project`: Activates a project by name.
# * `check_onboarding_performed`: Checks whether project onboarding was already performed.
# * `create_text_file`: Creates/overwrites a file in the project directory.
# * `delete_lines`: Deletes a range of lines within a file.
# * `delete_memory`: Deletes a memory from Serena's project-specific memory store.
# * `execute_shell_command`: Executes a shell command.
# * `find_referencing_code_snippets`: Finds code snippets in which the symbol at the given location is referenced.
# * `find_referencing_symbols`: Finds symbols that reference the symbol at the given location (optionally filtered by type).
# * `find_symbol`: Performs a global (or local) search for symbols with/containing a given name/substring (optionally filtered by type).
# * `get_current_config`: Prints the current configuration of the agent, including the active and available projects, tools, contexts, and modes.
# * `get_symbols_overview`: Gets an overview of the top-level symbols defined in a given file or directory.
# * `initial_instructions`: Gets the initial instructions for the current project.
# Should only be used in settings where the system prompt cannot be set,
# e.g. in clients you have no control over, like Claude Desktop.
# * `insert_after_symbol`: Inserts content after the end of the definition of a given symbol.
# * `insert_at_line`: Inserts content at a given line in a file.
# * `insert_before_symbol`: Inserts content before the beginning of the definition of a given symbol.
# * `list_dir`: Lists files and directories in the given directory (optionally with recursion).
# * `list_memories`: Lists memories in Serena's project-specific memory store.
# * `onboarding`: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).
# * `prepare_for_new_conversation`: Provides instructions for preparing for a new conversation (in order to continue with the necessary context).
# * `read_file`: Reads a file within the project directory.
# * `read_memory`: Reads the memory with the given name from Serena's project-specific memory store.
# * `remove_project`: Removes a project from the Serena configuration.
# * `replace_lines`: Replaces a range of lines within a file with new content.
# * `replace_symbol_body`: Replaces the full definition of a symbol.
# * `restart_language_server`: Restarts the language server, may be necessary when edits not through Serena happen.
# * `search_for_pattern`: Performs a search for a pattern in the project.
# * `summarize_changes`: Provides instructions for summarizing the changes made to the codebase.
# * `switch_modes`: Activates modes by providing a list of their names
# * `think_about_collected_information`: Thinking tool for pondering the completeness of collected information.
# * `think_about_task_adherence`: Thinking tool for determining whether the agent is still on track with the current task.
# * `think_about_whether_you_are_done`: Thinking tool for determining whether the task is truly completed.
# * `write_memory`: Writes a named memory (for future reference) to Serena's project-specific memory store.
excluded_tools: []
# initial prompt for the project. It will always be given to the LLM upon activating the project
# (contrary to the memories, which are loaded on demand).
initial_prompt: ""
project_name: "church-api"