Emby Dokumentation2

Datum: 3. September 2025

Status: Native Installation, produktiv und stabil

System-Übersicht

Installation-Typ: Native Debian-Installation (kein Docker)

Version: Emby Server 4.9.1.24

Server-Name: STORE2

Zugang: http://dergagi.changeip.org:8096

Prozess: EmbyServer (PID 1684585)

Technische Details

Ausführbare Datei: /opt/emby-server/system/EmbyServer

Programmdaten: /var/lib/emby

User: emby (dedicated service user)

FFmpeg-Integration: Vollständig konfiguriert mit eigenen Binaries

FFmpeg: /opt/emby-server/bin/ffmpeg
FFprobe: /opt/emby-server/bin/ffprobe
FFdetect: /opt/emby-server/bin/ffdetect

Netzwerk-Konfiguration

HTTP-Port: 8096 (aktiv, funktional)

HTTPS-Port: 8920 (nicht konfiguriert)

API-Endpoint: http://127.0.0.1:8096/System/Info/Public (funktional)

Externe URL: http://dergagi.changeip.org:8096

Router-Portweiterleitung: Port 8096 → 192.168.1.102:8096

Datenbank-System

MariaDB-Instanzen: 2 aktive Prozesse

PID 216805: mariadbd (emby user)
PID 2005213: mariadbd (emby user) Datenbank-Pfad: Unter /var/lib/emby/ verwaltet

Service-Management

Service-Typ: SystemD-managed (automatischer Start)

Restart-Policy: Exit Code 3 für Updates

Update-Methode: APT-Package emby-server-deb_{version}_amd64.deb

Benutzer-Zugang

Aktive externe User: ~5 Freunde mit Remote-Zugang

Funktionalität: Streaming funktioniert stabil über Internet

Performance: Response Time <1ms lokal, stabile Verbindungen

Integration mit STORE2-Ecosystem

Monitoring: Überwacht von Uptime Kuma (Port 8096, Tag: Critical)

Backup: Enthalten in nvme-Backup-System

Netzwerk: Läuft parallel zu Apache (Port 443), keine Konflikte

Medien-Bibliothek

Content-Status: Etablierte Sammlung für 5+ aktive Remote-User

Request-System: Aktuell manuell über persönliche Nachrichten

Geplante Erweiterung: Ombi Request-System für strukturierte User-Requests

Wartung & Updates

Update-Methode: APT-basiert über offizielle Emby-Repository

Backup-Status: Vollständig in nvme-incrementelle Backups enthalten

Stabilität: Läuft seit Installation ohne größere Probleme

Calibre-Web Automated (CWA) auf STORE2

Übersicht

Docker-Konfiguration

docker-compose.yml

yaml

services:
  calibre-web-automated:
    image: crocodilestick/calibre-web-automated:latest
    container_name: calibre-web-automated
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    ports:
      - "127.0.0.1:8084:8083"
    volumes:
      - /data/ebooks:/calibre-library:rw
      - /data/ebooks-config:/config:rw
    healthcheck:
      test: ["CMD-SHELL","python3 -c \"import socket; s=socket.socket(); s.settimeout(2); s.connect(('127.0.0.1',8083)); s.close()\""]
      interval: 15s
      timeout: 5s
      retries: 10
      start_period: 120s
    stop_grace_period: 30s

Pfade

Automatisierung

SystemD Timer

cwa-health.timer (jede Minute)

Überwacht Container-Status
Startet CWA bei Absturz neu
Service: /etc/systemd/system/cwa-health.timer
Script: /usr/local/bin/cwa-health.sh

bash

systemctl status cwa-health.timer

Cron-Jobs (root)

cwa-smart-import-v2.sh (alle 6 Stunden)

Scannt /data/ebooks nach neuen EPUBs
Importiert automatisch
Log: /var/log/cwa-import.log

bash

crontab -l | grep cwa

Geplante Aufgaben (CWA Web-UI, täglich 06:00)

✓ Buchcover Miniaturansichten erzeugen
✓ Mit Calibre Bibliothek neu verbinden
✓ Metadaten Backup Datei erzeugen

Aktive Features

CWA-Services

✓ Auto-Convert (EPUB als Standard)
✓ Automatic Cover & Metadata Enforcement
✓ Kindle EPUB Fixer
✓ Import Auto-Backup

Web-UI Einstellungen

✓ Hochladen aktiviert
✓ Update-Benachrichtigungen
✓ GMX Mail-Server konfiguriert (Send-to-Kindle)

Neue eBooks einbinden

Methode 1: Automatischer Import (empfohlen)

Neue EPUBs nach /data/ebooks/ kopieren:

bash

cp ~/neue-buecher/*.epub /data/ebooks/

Import erfolgt automatisch alle 6h via Cron, oder manuell triggern:

bash

/usr/local/bin/cwa-smart-import-v2.sh

Methode 2: Web-Upload

https://dergagi.changeip.org/cwa öffnen
"Upload" Button → Dateien auswählen
CWA importiert automatisch

Methode 3: Calibre Desktop Import (für große Mengen)

⚠️ WICHTIG: Container MUSS gestoppt sein!

bash

# Container stoppen
cd /srv/calibre-web-automated
docker compose down

# Calibre Desktop öffnen (GUI)
# Bibliothek: /data/ebooks
# Bücher hinzufügen mit Duplikat-Merge

# Container wieder starten
docker compose up -d

Import-Scripts

Aktive Scripts (behalten):

Legacy Scripts (archiviert):

29 alte Import-Scripts wurden identifiziert. Bei Bedarf aufräumen:

bash

# Liste anzeigen
ls -lht /usr/local/bin/cwa-* /usr/local/bin/import-* /usr/local/bin/calibre-*

# Archivieren (falls gewünscht)
mkdir -p /root/old-cwa-scripts
mv /usr/local/bin/cwa-{scan,import,turbo,fast,simple}* /root/old-cwa-scripts/

Wartung

Container-Neustart

bash

cd /srv/calibre-web-automated
docker compose restart

Datenbank-Backup

Automatisch: Täglich um 06:00 Uhr via CWA Scheduled Task

Manuell:

bash

cp /data/ebooks/metadata.db /data/ebooks/metadata.db.backup-$(date +%Y%m%d-%H%M%S)

Backups finden:

bash

ls -lht /data/ebooks/metadata.db.* | head -5

Logs prüfen

bash

# Container-Logs
docker logs -f calibre-web-automated

# Import-Logs
tail -f /var/log/cwa-import.log

# Health-Check Logs
journalctl -u cwa-health.service -f

Buchanzahl prüfen

bash

sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;"

Statistiken

Import-Historie

Performance

Auto-Ingest: ~10-15 Bücher/Minute
Calibre Desktop Bulk-Import: ~200-300 Bücher/Minute
Große Imports (>30k Bücher): 2-3 Stunden

Bekannte Einschränkungen

Format-Duplikate

CWA zeigt jedes Format (epub/mobi/pdf) als separaten Eintrag
Keine Gruppierungsfunktion verfügbar
Workaround: Nur ein Format pro Buch hochladen (bevorzugt EPUB)

Import-Geschwindigkeit

Auto-Ingest langsamer als Calibre Desktop
Große Imports (>500 Bücher) besser via Calibre Desktop

Tiefe Ordnerstrukturen

Werden erkannt, aber langsam verarbeitet
Besser: Flache Struktur /Autor/Buchtitel/

Fehlerbehebung

Container startet nicht

bash

cd /srv/calibre-web-automated
docker compose down
docker compose up -d
docker logs calibre-web-automated

CWA zeigt falsche Buchanzahl

bash

# Im Browser: Admin → "Mit Calibre Bibliothek neu verbinden"
# Oder per API:
curl -X POST http://127.0.0.1:8084/admin/reconnect

Unvollständige Einträge / Fehlende Cover

Admin → Geplante Aufgaben → "Metadaten Backup" manuell starten

"Database is locked" Fehler

Ursache: Calibre Desktop läuft parallel zum Container

Lösung:

bash

# Container stoppen
docker compose down

# Calibre Desktop schließen
pkill -f calibre

# Container neu starten
docker compose up -d

Monitoring

Live-Monitor (während Import läuft)

bash

watch -n 2 'echo "=== CWA STATUS ==="; \
echo "Bücher in DB: $(sqlite3 /data/ebooks/metadata.db "SELECT COUNT(*) FROM books;")"; \
echo "Container: $(docker ps --filter name=calibre-web-automated --format "{{.Status}}")"; \
echo "Healthcheck: $(docker inspect calibre-web-automated --format="{{.State.Health.Status}}")"'

Timer-Status prüfen

bash

systemctl list-timers | grep cwa

Apache Reverse Proxy

CWA ist über Apache erreichbar:

VirtualHost: 000-catchall-443.conf + 000-website-dergagi-443.conf

ProxyPass-Regel:

apache

ProxyPass /cwa http://127.0.0.1:8084
ProxyPassReverse /cwa http://127.0.0.1:8084

Externe URL: https://dergagi.changeip.org/cwa

Wichtige Hinweise

NIE Container UND Calibre Desktop gleichzeitig laufen lassen! → SQLite-DB kann nur von EINEM Prozess beschrieben werden
Große Imports immer via Calibre Desktop: → Container stoppen, Import durchführen, Container starten
Backups vor großen Änderungen:

bash

   cp /data/ebooks/metadata.db /data/ebooks/metadata.db.backup-$(date +%Y%m%d)

System-Backups via nvme-backup.timer: → Täglich 03:07 Uhr, 21 Versionen in /mnt/nvme_backup/

Letzte Aktualisierung: 10. Oktober 2025

Version: 2.0 (Post-Torboox-Import)

MediaWiki - Aktuelle Konfiguration & Dokumentation

Stand: 03. September 2025, 15:30 Uhr

Status: Produktiv, vollständig funktional nach Container-Wiederherstellung

System-Übersicht

Grundkonfiguration

MediaWiki Version: 1.44.0
URL: http://dergagi.changeip.org:8088/
Betriebssystem: Debian 13 (STORE2)
Container-System: Docker + Docker-Compose
Installation-Pfad: /srv/mediawiki-clean-final/

Admin-Zugang

Admin-User: admin
Admin-Passwort: CleanFinalMW2025!
Admin-URL: http://dergagi.changeip.org:8088/index.php/Spezial:Anmelden

Docker-Setup

Container-Konfiguration

bash

# Container-Namen
mw-clean-final        # MediaWiki-Anwendung
mw-clean-final-db     # MariaDB-Datenbank

# Management-Befehle
cd /srv/mediawiki-clean-final/
docker-compose up -d        # Start
docker-compose down         # Stop
docker ps | grep mw-clean  # Status
docker logs mw-clean-final # Logs

Port-Mapping

MediaWiki: Container:80 → Host:8088
Datenbank: Container:3306 (intern, nicht exposed)

Datenbank-Konfiguration

MariaDB-Credentials

DB-Host: database (Container-Name)
DB-Name: mediawiki
DB-User: mwuser
DB-Passwort: CleanFinalMW2025!
DB-Root-User: root
DB-Root-Passwort: CleanFinalRoot2025!

Datenbank-Zugriff

bash

# Direkte Datenbank-Verbindung
docker exec -it mw-clean-final-db mysql -u mwuser -p'CleanFinalMW2025!' mediawiki

# Root-Zugriff
docker exec -it mw-clean-final-db mysql -u root -p'CleanFinalRoot2025!' mediawiki

MediaWiki-Konfiguration

LocalSettings.php (Zentrale Einstellungen)

Container-Pfad: /var/www/html/LocalSettings.php
Host-Backup: /srv/mediawiki-clean-final/LocalSettings.php

Wichtige Konfigurationswerte

php

$wgSitename = "Store2 Wiki";
$wgServer = "http://dergagi.changeip.org:8088";
$wgLanguageCode = "de";
$wgDefaultSkin = "vector";
$wgEnableUploads = true;
$wgLogos = [
    '1x' => "$wgResourceBasePath/images/logo.png",
    'icon' => "$wgResourceBasePath/images/logo.png",
];

# Suppress MediaWiki 1.44 core deprecation warnings
error_reporting( E_ALL & ~E_USER_DEPRECATED & ~E_DEPRECATED );

Logo-Integration

Logo-Datei: /var/www/html/images/logo.png (im Container)
Original-Logo: /data/Downloads/Fertig/Mediawiki_Store2_Logo.png
Skalierung: 160x160px (optimiert für MediaWiki)
Dateigröße: ~10KB (von ursprünglich 1.1MB)
Status: Store2-Logo mit rotem Rahmen und Stern sichtbar

Daten-Inhalt

Wiki-Seiten (12 Hauptseiten + aktuelle Ergänzungen)

Hauptseite (mit Kachel-Layout)
Store_2.0 (umfangreiche System-Dokumentation)
RAID-Systeme (Raid, Raid-Layout)
Linux-Verwendung (Linux-use)
Change-Routen (System-Migration)
Webservices & Subversion
Wiki-Bearbeitung (Wiki-Edit)
Aktuelle Ergänzungen: Container-Wiederherstellung-Dokumentation (03.09.2025)

Statistik

Seiten: 12+ importiert (erweitert um aktuelle Dokumentation)
Revisionen: 1059+ (aus 2010er Backup + neue Inhalte)
Datenquelle: XML-Backup von Original-Store2-System + laufende Updates

Backup-System

Aktuelle Backups

bash

# Perfektes Aktuell-Backup mit Logo (94MB) - 03.09.2025
/root/mediawiki-perfect-with-logo-20250903-152727/
├── mediawiki-perfect-152727.sql  (47MB - SQL mit aktuellen Daten)
├── mw-database-perfect.tar.gz    (33MB - Docker-Volume)
├── mw-images-with-logo.tar.gz    (14MB - Images + Store2-Logo)
├── LocalSettings-perfect.php     (4.7KB - Konfiguration)
└── mediawiki-setup/              (Docker-Compose)

# Notfall-Backups (während Wiederherstellung erstellt)
/root/mediawiki-emergency-backup-20250903-151021/  # Sichere aktuelle Daten
/root/mediawiki-before-logo-fix-*/                # Pre-Logo-Fix Backups

# Original-Backups (Fallback)
/root/mediawiki-working-backup.20250831-123906/   # Funktionierendes Backup
/root/STORE2-XML-BACKUP-SAFE-20250831-112526.xml.gz  # XML-Original

Restore-Prozedur (Aktualisiert)

bash

# Restore aus perfektem Backup (mit Store2-Logo)
cd /root/mediawiki-perfect-with-logo-20250903-152727/
docker-compose -f mediawiki-setup/docker-compose.yml down
docker volume rm mediawiki-clean-final_mw-database mediawiki-clean-final_mw-images
docker-compose -f mediawiki-setup/docker-compose.yml up -d
gunzip < mw-database-perfect.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-database:/data alpine tar xzf - -C /data
gunzip < mw-images-with-logo.tar.gz | docker run -i --rm -v mediawiki-clean-final_mw-images:/data alpine tar xzf - -C /data
docker cp LocalSettings-perfect.php mw-clean-final:/var/www/html/LocalSettings.php

Docker-Volumes

Volume-Management

bash

# Volume-Namen
mediawiki-clean-final_mw-database  # MariaDB-Daten
mediawiki-clean-final_mw-images    # MediaWiki-Uploads + Store2-Logo

# Volume-Pfade
/var/lib/docker/volumes/mediawiki-clean-final_mw-database/_data
/var/lib/docker/volumes/mediawiki-clean-final_mw-images/_data

Container-Wiederherstellung (03.09.2025)

Durchgeführte Reparaturen

Problem: Versehentliches docker container prune -f löschte alle Container
Lösung: Vollständige Wiederherstellung aus nvme-Backup
Status: Erfolgreich wiederhergestellt mit allen Daten
Logo-Fix: Store2-Logo neu installiert und auf MediaWiki-Standard skaliert
Deprecation-Warning: Über PHP error_reporting unterdrückt

Lessons Learned

Backup-Kritikalität: nvme-Backup war entscheidend für Wiederherstellung
Vorsichtige Vorgehensweise: Immer Backup vor Systemänderungen
Systematische Reparatur: Erst Daten sichern, dann reparieren

Wartung & Maintenance

MediaWiki-Maintenance-Scripts

bash

# Update-Script
docker exec mw-clean-final php /var/www/html/maintenance/update.php

# Cache-Rebuild
docker exec mw-clean-final php /var/www/html/maintenance/rebuildrecentchanges.php

# Site-Statistiken
docker exec mw-clean-final php /var/www/html/maintenance/initSiteStats.php

Monitoring

Port-Check: netstat -tlnp | grep :8088
Container-Status: docker ps | grep mw-clean
Logs: docker logs mw-clean-final

Integration in STORE2-System

Netzwerk-Konfiguration

Läuft parallel zu Apache (Port 443)
Keine BasicAuth-Konflikte
Direkter Port-Zugang ohne Proxy
Unabhängig von /data2-Mount (läuft auf Haupt-Partition)

Dienste-Integration

Läuft eigenständig ohne Abhängigkeiten zu anderen Store2-Services
Keine Apache-Proxy-Konfiguration erforderlich
Automatischer Docker-Start mit System

Sicherheit & Zugänge

Authentifizierung

Keine Apache-BasicAuth (direkter Port-Zugang)
MediaWiki-eigene Benutzerkonten
Admin-Account für Vollzugriff

Netzwerk-Sicherheit

Port 8088 HTTP-only (kein HTTPS konfiguriert)
Datenbank nicht extern exposed
Container-zu-Container Kommunikation über Docker-Netzwerk

MediaWiki Store2 ist vollständig eingerichtet, produktiv und backup-gesichert.

Koel Musikstreaming-Server

📍 Installation erfolgreich abgeschlossen

Server: STORE2

URL: http://dergagi.changeip.org:6680

Status: ✅ Voll funktionsfähig

🔑 Zugangsdaten

Admin-Account:

Email: daniel.gareis@gmail.com
Passwort: #s46@jCuFEq5S^

Datenbank:

DB-Root: KoelRootStore2!
DB-User: koel / KoelStore2Music2025!

🎵 Musik-Archiv

Verzeichnisse:

Hauptordner: /data2/mp3/mp3 (92.980 MP3-Dateien)
Symlinks: 38.046 Links in /data2/mp3/mp3/00_Unique_From_Other_Folders
Weitere: 7.778 MP3s in /data2/mp3/mp3s von MB/
Cover: 7.015 Cover-Dateien im Archiv, werden bei Koel aber nicht genutzt, sondern on-the-fly online hergeholt und auch nicht lokal gespeichert

Scan-Status:

Läuft gerade im Hintergrund (2-3 Stunden für alle Dateien)
Songs erscheinen live im Web-Interface während des Scans
Log: /var/log/koel-scan.log

🔧 Technische Details

Docker-Setup:

Installation in /srv/koel
Container: koel (App) + koel-db (MariaDB 10.11)
Port: 6680 (extern) → 80 (intern)
Images: phanan/koel:latest + mariadb:10.11
Memory Limit: 2GB für Koel, 512MB für DB

Konfigurationsdateien:

Docker Compose: /srv/koel/docker-compose.yml
Environment: /srv/koel/koel.env
APP_KEY: Automatisch generiert und in koel.env gespeichert

Features:

✅ Web-basiertes Streaming
✅ Playlist-Verwaltung
✅ Last.fm/Spotify/iTunes Metadaten
✅ Cover-Art (dynamisch geladen)
✅ Suche und Filter
⚠️ 100.686/137.074 Songs verfügbar

Bekannte Probleme:

Unterordner in /00_Unique_From_Other_Folders/ werden nicht gescannt
UTF-8 Encoding-Fehler bei Sonderzeichen
Keine lokale Cover-Speicherung

📝 Wichtige Wartungsbefehle

bash

<# Musik-Scan manuell starten
docker exec --user www-data koel php artisan koel:scan

# Scan-Progress verfolgen
tail -f /var/log/koel-scan.log

# Container-Status prüfen
docker ps | grep koel

# Container neu starten
cd /srv/koel && docker-compose restart

# Laravel-Logs bei Problemen
docker exec koel tail -50 /var/www/html/storage/logs/laravel.log

# Cache leeren
docker exec koel php artisan cache:clear
docker exec koel php artisan config:clear

💾 Backup-Information

Navidrome-Backup vorhanden: /root/backup-navidrome-*.tar.gz
Koel-Daten: /srv/koel/ (Docker Volumes)
Musik unverändert in: /data2/mp3/

⚠️ Bekannte Einschränkungen

Läuft nur über HTTP (kein HTTPS aktiv)
Mobile Apps sind kostenpflichtig
Keine automatischen Metadaten-Downloads konfiguriert

System läuft stabil! Container sind healthy, Web-Interface funktioniert

Navidrome (läuft nicht mehr, nur historisch, wurde durch Koel ersetzt)

📋 Service-Übersicht

Service: Navidrome Music Streaming Server

Status: Produktiv

Installation: 2025-09-03

Container-ID: navidrome

🔧 Technische Konfiguration

Netzwerk & Ports

Port: 4533 (HTTP)
Lokal: http://localhost:4533
Extern: http://dergagi.changeip.org:4533
Protocol: HTTP (kein HTTPS - läuft hinter Apache wenn gewünscht)

Docker-Container

bash

Container Name: navidrome
Image: deluan/navidrome:latest
Restart Policy: unless-stopped
Port Mapping: 4533:4533
Network: Bridge (Standard)

Volume-Mounts

bash

/data2/mp3 → /music (read-only)           # Musik-Archiv (138.192 MP3s)
/opt/navidrome/data → /data               # SQLite-DB & Metadaten
/opt/navidrome/cache → /cache             # Thumbnails & Cache
/opt/navidrome/navidrome.toml → /opt/navidrome/navidrome.toml (ro)

Konfigurationsdatei

Pfad: /opt/navidrome/navidrome.toml

toml

MusicFolder = "/music"
DataFolder = "/data"
CacheFolder = "/cache"
Address = "0.0.0.0"
Port = 4533
LogLevel = "info"
ScanSchedule = "@every 1h"
SessionTimeout = "24h"
UIWelcomeMessage = "Willkommen zu STORE2 Music Center"
EnableTranscodingConfig = true
TranscodingCacheSize = "1GB"
EnableSharing = true
EnableStarRating = true
EnableUserEditing = true
MaxSidebarPlaylists = 100

Verwaltungsbefehle

bash

# Status prüfen
docker ps | grep navidrome

# Logs ansehen
docker logs navidrome

# Container stoppen/starten
docker stop navidrome
docker start navidrome

# Container neu starten
docker restart navidrome

# Container entfernen (Notfall)
docker stop navidrome && docker rm navidrome

iTunes/Last.fm Cover Downloader Service

System: STORE2 (Debian 13)

Stand: 2025-09-14

Status: ✅ AKTIV UND FUNKTIONSFÄHIG

1. SYSTEM-ÜBERSICHT

Zweck

Automatisches Herunterladen fehlender Album-Cover für die MP3-Sammlung unter /data2/mp3/mp3/ mittels iTunes und Last.fm APIs.

Aktuelle Statistik

Service läuft seit: 14.09.2025 08:15 Uhr
Erfolgsrate: ~11-15% (normal für diese Sammlung mit vielen Bootlegs)
Bisher heruntergeladen: 380+ Cover erfolgreich, 2187 neue Cover in 24h
Verbleibende Queue: 2901 Alben ohne Cover
Geschätzte Restzeit: ~2-3 Stunden bei 3 Sek/Album

2. TECHNISCHE ARCHITEKTUR

Verzeichnisstruktur

/opt/itunes-persistent/
├── downloader_robust_v3.sh      # Hauptscript (Bash)
├── download_queue.txt           # Queue (TAB-getrennt: Pfad<TAB>Artist<TAB>Album)
├── skip_artwork.txt             # Skip-Cache für bereits versuchte Alben
├── make_queue.py                # Python-Script zur Queue-Generierung
├── logs/
│   ├── downloader-YYYY-MM-DD.log  # Tägliche Log-Dateien
│   └── session_stats.log          # Statistik-Übersicht
└── backup-*/                    # Backup-Verzeichnisse

SystemD Service Configuration

Datei: /etc/systemd/system/itunes-downloader.service

ini

[Unit]
Description=Hybrid iTunes + Last.fm Cover Downloader
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/itunes-persistent
ExecStart=/opt/itunes-persistent/downloader_robust_v3.sh
Restart=always
RestartSec=60
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

3. API KONFIGURATION

Last.fm API

API Key: 7c327a65fcfcec095b42e9df6b3b46b4
Secret: 4765b081824d0dfc5a6174fd457b6a9b
User: dergagi33
App Name: Store2
Rate Limit: 300 requests/minute
Erfolgsrate: ~60% für offizielle Releases

iTunes API

Endpoint: https://itunes.apple.com/search
Rate Limit: 20 requests/minute
Auth: Keine erforderlich
Erfolgsrate: ~30% für offizielle Releases

4. WORKFLOW & LOGIK

Download-Prozess

Queue laden aus download_queue.txt
Skip-Check: Prüfung gegen skip_artwork.txt
API-Versuch 1: iTunes API Query
API-Versuch 2: Last.fm API als Fallback
Alternative Schreibweisen bei Fehlschlag (& → and, Umlaute, etc.)
Download: Cover als cover.jpg speichern
Cache-Update: Erfolg/Misserfolg in Skip-Cache

Queue-Generierung (`make_queue.py`)

python

#!/usr/bin/env python3
import os

base_dir = '/data2/mp3/mp3'
output_file = '/opt/itunes-persistent/download_queue.txt'

with open(output_file, 'w') as f:
    for root, dirs, files in os.walk(base_dir):
        # Skip Sampler/Collections
        if any(part.startswith('00') for part in root.split('/')):
            continue
        # Check for missing cover
        if 'cover.jpg' not in files:
            # Extract artist and album from path
            # Write TAB-separated: path<TAB>artist<TAB>album

5. WICHTIGE BEFEHLE

Service Management

bash

# Status prüfen
systemctl status itunes-downloader

# Service stoppen
systemctl stop itunes-downloader

# Service starten
systemctl start itunes-downloader

# Service neustarten
systemctl restart itunes-downloader

# Logs anzeigen (live)
journalctl -u itunes-downloader -f

# Auto-Start aktivieren/deaktivieren
systemctl enable itunes-downloader
systemctl disable itunes-downloader

Monitoring & Statistik

bash

# Live-Log verfolgen
tail -f /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Erfolgsstatistik
grep -c "SUCCESS:" /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Queue-Status
wc -l < /opt/itunes-persistent/download_queue.txt

# Neue Cover der letzten Stunde
find /data2/mp3/mp3 -name "cover.jpg" -mmin -60 | wc -l

# Erfolgsrate berechnen
awk '/Processing:/ {total++} /SUCCESS:/ {success++} END {
    print "Erfolge: " success "/" total " = " int(success*100/total) "%"
}' /opt/itunes-persistent/logs/downloader-$(date +%F).log

Queue Management

bash

# Queue neu generieren
systemctl stop itunes-downloader
cd /opt/itunes-persistent
python3 make_queue.py
systemctl start itunes-downloader

# Skip-Cache leeren (für neue Versuche)
> /opt/itunes-persistent/skip_artwork.txt

# Backup erstellen
cp download_queue.txt download_queue.backup
cp skip_artwork.txt skip_artwork.backup

6. TROUBLESHOOTING

Problem: Service läuft in Endlos-Schleife

Symptom: Service startet alle 60 Sekunden neu

Ursache: Alle Queue-Einträge im Skip-Cache

Lösung:

bash

systemctl stop itunes-downloader
> /opt/itunes-persistent/skip_artwork.txt  # Skip-Cache leeren
python3 /opt/itunes-persistent/make_queue.py  # Neue Queue
systemctl start itunes-downloader

Problem: Keine neuen Downloads

Mögliche Ursachen:

API-Rate-Limits erreicht
Alle verbleibenden Alben nicht in APIs verfügbar
Queue leer

Diagnose:

bash

# Prüfe ob Queue leer
wc -l < /opt/itunes-persistent/download_queue.txt

# Prüfe letzte Aktivität
tail -20 /opt/itunes-persistent/logs/downloader-$(date +%F).log

# Prüfe ob Prozess läuft
pgrep -f downloader_robust_v3.sh

Problem: Zu viele API-Fehler

Lösung: Rate-Limit in Script anpassen

bash

# In downloader_robust_v3.sh:
# RATE_LIMIT variable von 2 auf 3-4 Sekunden erhöhen

7. MUSIK-SAMMLUNG STRUKTUR

Gesamt-Statistik

Basis-Verzeichnis: /data2/mp3/mp3/
Künstler-Verzeichnisse: 1372
Gesamt-Alben: 6642
Mit Cover: 3741 (nach Downloads)
Ohne Cover: 2901 (hauptsächlich Bootlegs/VA)

Kategorien ohne Cover

VA-Compilations: ~540 Einträge
- Schwer zu finden, oft lokale Zusammenstellungen
Bootlegs/Underground: ~800 Einträge
- Release-Groups (-uC, -RpM, -WHOA, -XXL)
- Niemals in offiziellen APIs
Fehlende Metadaten: ~550 Einträge
- Verzeichnisname = Artist = Album
- Parser konnte nicht trennen
Reggae-Sammlung: ~200 Einträge
- Spezielle Struktur unter REGGAE/REGGEA
Normale Alben: ~800 Einträge
- Ältere/unbekannte Releases
- Falsche Schreibweise

8. PERFORMANCE & OPTIMIERUNG

Aktuelle Performance

Durchsatz: ~20-30 Alben/Minute
Pause zwischen Downloads: 2 Sekunden
Erfolgsrate: 11-15% (systembedingt niedrig)

Optimierungsmöglichkeiten

Parallel-Processing: Mehrere Worker-Threads
Bessere APIs: MusicBrainz, Discogs
Lokale Datenbank: Cache erfolgreicher Matches
Fuzzy-Matching: Bessere Schreibweisen-Toleranz

9. BACKUP & RECOVERY

Wichtige Dateien sichern

bash

# Vollbackup
tar -czf itunes-backup-$(date +%F).tar.gz \
    /opt/itunes-persistent/ \
    /etc/systemd/system/itunes-downloader.service

# Queue & Skip-Cache Backup
cp /opt/itunes-persistent/download_queue.txt ~/backup/
cp /opt/itunes-persistent/skip_artwork.txt ~/backup/

Wiederherstellung

bash

# Service stoppen
systemctl stop itunes-downloader

# Backup einspielen
tar -xzf itunes-backup-DATUM.tar.gz -C /

# Service neu laden und starten
systemctl daemon-reload
systemctl start itunes-downloader

10. ZUSAMMENFASSUNG

Der iTunes/Last.fm Cover Downloader läuft stabil und zuverlässig. Die niedrige Erfolgsrate von 11-15% ist normal und erwartbar für diese Musik-Sammlung, da:

Viele Bootlegs und Underground-Releases vorhanden sind
VA-Compilations selten in APIs verfügbar sind
Verzeichnisstrukturen teilweise problematisch sind

Der Service hat bereits 2187 Cover in 24 Stunden erfolgreich heruntergeladen und wird die verbleibenden 2901 Einträge durcharbeiten. Danach kann er gestoppt oder für neue Alben reaktiviert werden.

Nächste Schritte nach Abschluss:

Service stoppen wenn Queue leer
Periodisch neue Queue generieren für neue Alben
Ggf. manuelle Cover für wichtige Alben ergänzen

Ombi Media Request System - Konfigurationsdokumentation

Datum: 3. September 2025

Status: Vollständig konfiguriert und produktiv

System-Übersicht

Installation:

Version: LinuxServer Ombi (latest)
Container: ombi (/srv/ombi/)
Port: 3579 (HTTP)
Zugang: http://192.168.1.102:3579 | http://dergagi.changeip.org:3579
Database: SQLite (Standard)
Admin-User: dergagi

Emby-Server-Integration

Server-Konfiguration:

Server Name: STORE2 Emby
Hostname: dergagi.changeip.org
Port: 8920 (HTTPS)
SSL: Aktiviert
API Key: d740243a61584180af06df568d56dd23
Server ID: 5a6aa876ff544473bd36e7ccd9742a8b

Überwachte Bibliotheken:

Movies ✓
Serien ✓
FPV Videos ✓
Andere deaktiviert

Benutzer-Verwaltung

Importierte Emby-User (9 Personen):

Benny, Bianka, Chris, Ogi, Hollis, Michi, Flippo, Pitri, Instalazer

Standard-Benutzerrollen:

Request Movie: Aktiviert
Request TV: Aktiviert
Request Music: Aktiviert
Auto-Approve: Deaktiviert (manuelle Genehmigung)
Admin: Nur dergagi

Request-Limits:

Movie Requests: 10/Woche
Episode Requests: 20/Woche
Music Requests: Unbegrenzt

Email-Benachrichtigungen

SMTP-Konfiguration:

Server: mail.gmx.net:587 (STARTTLS)
Absender: dergagi@gmx.de
Username: dergagi@gmx.de
Sender Name: Emby Request
Admin Email: daniel.gareis@gmail.com

Aktive Benachrichtigungen:

New Request, Request Approved, Request Available, Request Declined, Welcome Email

Authentifizierung: Emby-User-Integration (keine OAuth) Login-Prozess: Username/Password wie bei Emby URL für Freunde: http://dergagi.changeip.org:3579

YT4K System - Zusammenfassung

Server: STORE2 (Debian 13)

URL: http://dergagi.changeip.org:8443/

Status: Voll funktionsfähig

Aktuelle Konfiguration

Service: SystemD-managed yt4k.service

User: www-data:www-data

Port: 8443 (HTTP, Router-forwarded)

Processing: FFmpeg-basiert (3-8 Min pro Video)

Verzeichnisse:

Anwendung: /srv/yt4k/
Output: /data/Downloads/YT4K/ (gagi:www-data 775)
Temp: /tmp/yt4k/

Python-Umgebung

Virtual Env: /srv/yt4k/.venv

Python: 3.13.5

Packages: fastapi, uvicorn, yt-dlp, opencv, numpy

Processing-Pipeline

Aktiv: FFmpeg-basierte AI-Simulation

Lanczos-Interpolation
Noise Reduction
Color Enhancement
Unsharp Masking
H.264 Encoding (CRF 16-18)

Deaktiviert: Real-ESRGAN (zu langsam - Stunden pro Video)

API-Endpunkte

/ - Web-Interface
/upload - Video-Processing
/status/{job_id} - Progress
/download/{filename} - Download
/health - System-Status

Service-Management

bash

systemctl start/stop/restart yt4k.service
journalctl -u yt4k.service -f
curl http://127.0.0.1:8443/health

Performance

Processing-Zeiten:

480p→4K: 3-5 Min
720p→4K: 5-8 Min
1080p→4K: 8-12 Min

Output-Qualität: Hochwertige 4K-Videos (20-50MB typisch)

Troubleshooting

Emergency-Restart:

bash

systemctl restart yt4k.service
rm -rf /tmp/yt4k*

Häufige Probleme:

Job-Status hängt → Service restart
Permissions → chown www-data:www-data
Port nicht erreichbar → Router-Check

Das System ist stabil, produktionsbereit und nutzt bewährte FFmpeg-Technologie für schnelle, zuverlässige Video-Upscaling.

Nextcloud Konfiguration - STORE2

Datum: 01. September 2025

Status: Produktiv, vollständig funktionsfähig

System-Übersicht

Server: STORE2 (192.168.1.102)

OS: Debian 13

Container-System: Docker Compose

Reverse-Proxy: Traefik v3.5

Öffentliche URLs

Nextcloud (HTTPS): https://nc.dergagi9.duckdns.org:8444
Nextcloud (HTTP intern): http://192.168.1.102:8086
Traefik Dashboard: http://192.168.1.102:8082

Authentifizierung

Nextcloud Admin:

Benutzer: dergagi
Passwort: Store2@NC#2025

Datenbank (MariaDB):

Host: db (Docker-intern)
Datenbank: nextcloud
Benutzer: nextcloud
Passwort: Store2@NC#2025

SSL/TLS-Zertifikat

Typ: Let's Encrypt Wildcard-Zertifikat

Domain: *.dergagi9.duckdns.org

Gültigkeitsdauer: Bis 10. Oktober 2025

Issuer: Let's Encrypt (R11)

Speicherort: /srv/traefik/certificates/

Docker-Konfiguration

Traefik (Reverse Proxy)

Container: traefik-nc
Image: traefik:v3.5
Ports: 81→80, 8444→443, 8082→8080
Config: /srv/traefik/docker-compose.yml
Zertifikate: /srv/traefik/certificates/dynamic.yml

Nextcloud

Container: nextcloud-app
Image: nextcloud:31
Port: 8086→80 (HTTP intern)
Config: /srv/nextcloud/docker-compose.yml
Trusted Domains: nc.dergagi9.duckdns.org:8444

Datenbank

Container: nextcloud-db
Image: mariadb:10.11
Port: 3306 (nur intern)
Volume: nextcloud_db-data

Netzwerk-Konfiguration

Router-Portweiterleitung:

Port 81 → 192.168.1.102:81 (HTTP Challenge)
Port 8444 → 192.168.1.102:8444 (HTTPS Nextcloud)

DNS:

Provider: DuckDNS
Domain: nc.dergagi9.duckdns.org
IP: 91.65.237.120 (automatisches Update aktiv)

Sicherheit

HTTPS-Only (Port 8444)
Let's Encrypt-Zertifikat (vertrauenswürdig)
Apache Store2-Website unberührt (Port 443)
Alle anderen Dienste isoliert

Wartung

Container neustarten:

bash

<cd /srv/traefik && docker compose restart
cd /srv/nextcloud && docker compose restart

Zertifikat erneuern (vor Oktober 2025):

Neues Zertifikat von Let's Encrypt holen
In /srv/traefik/certificates/ ersetzen
Traefik neustarten

Datensicherung:

Volume: nextcloud_db-data (Datenbank)
Volume: nextcloud_nextcloud-data (Dateien)

Integration

Unberührte Dienste:

Store2-Website (Apache Port 443)
MediaWiki (Port 8088)
YT4K (Port 8443)
HomeBox (Port 3100)
Alle anderen bestehenden Dienste

Besonderheiten:

Kein Konflikt mit Apache
Rate Limit-Problem durch Wildcard-Zertifikat umgangen
Automatische DNS-Updates durch DuckDNS

Nextcloud Docker Update

Voraussetzungen

Nextcloud läuft via Docker Compose unter /srv/nextcloud
Traefik als Reverse Proxy unter /srv/traefik
Zugriff: https://nc.dergagi9.duckdns.org:8444

Update-Prozedur (Beispiel: 31.0.8 → 31.0.9)

1. Version in docker-compose.yml ändern

cd /srv/nextcloud
nano docker-compose.yml

Ändere die Image-Zeile von:

services:
  app:
    image: nextcloud:31

auf die gewünschte Version:

services:
  app:
    image: nextcloud:31.0.9

Wichtig:

Bei Minor-Updates (31.0.8 → 31.0.9): Direkt möglich
Bei Major-Updates (30.x → 31.x): Nur ein Major-Schritt gleichzeitig!
Nie überspringen (29.x → 31.x geht NICHT)

2. Optional: Datenbank-Backup

docker exec nextcloud-db mariadb-dump -u nextcloud -p'Store2@NC#2025' nextcloud > /root/nextcloud-backup-$(date +%F).sql

3. Update durchführen

# Neues Docker Image herunterladen
docker compose pull

# Container mit neuem Image neu starten
docker compose up -d

4. Automatisches Upgrade abwarten Der Container erkennt die Versionsdifferenz automatisch und führt das Upgrade durch. Dies dauert 30-60 Sekunden. Logs beobachten mit:

docker compose logs -f

Warten auf die Meldung:

Initializing nextcloud 31.0.9...
Upgrading nextcloud from 31.0.8...
Upgrade successful

5. Verifikation

# Version prüfen
docker exec nextcloud-app php occ -V

# Container-Status
docker compose ps

# Web-Interface testen
curl -I https://nc.dergagi9.duckdns.org:8444

Besonderheiten der Installation

Docker-Struktur:

Nextcloud App: Container nextcloud-app, Port 8086 intern
Datenbank: Container nextcloud-db (MariaDB 10.11)
Reverse Proxy: Traefik v3.5 auf Port 8444 (HTTPS)
Volumes: Daten bleiben in Docker Volumes erhalten

Keine manuellen Schritte nötig:

❌ Kein occ upgrade erforderlich
❌ Kein Maintenance Mode nötig
❌ Kein Web-Updater (bei Docker deaktiviert)
✅ Alles läuft automatisch beim Container-Start

Rollback bei Problemen

# Alte Version wiederherstellen
cd /srv/nextcloud
docker compose down

# docker-compose.yml auf alte Version zurücksetzen
nano docker-compose.yml  # Version wieder auf z.B. nextcloud:31.0.8 ändern

# Container neu starten
docker compose up -d

# Optional: Datenbank aus Backup wiederherstellen
docker exec -i nextcloud-db mariadb -u nextcloud -p'Store2@NC#2025' nextcloud < /root/nextcloud-backup-DATUM.sql

Update-Pfad für größere Sprünge Beispiel von Version 29 auf 31:

Speedtest Tracker

Setup-Datum: 04.09.2025

Version: LinuxServer.io Image

Status: Vollautomatisch, produktiv

Installation & Zugriff

Container-Details:

Container-Name: speedtest-tracker-new
Image: lscr.io/linuxserver/speedtest-tracker:latest
Port: 8092 (HTTP)
URL: http://dergagi.changeip.org:8092
Login: daniel.gareis@gmail.com / 9@8Cq%UhhWYFs%

Konfiguration

Docker-Compose-Pfad: /opt/speedtest-tracker-new/docker-compose.yml

Finale Environment-Variablen:

SPEEDTEST_SCHEDULE="*/10 * * * *"  # Alle 10 Minuten (Cron-Format)
SPEEDTEST_SERVERS=52770           # Verizon.com Server (944+ Mbps)
TZ=Europe/Berlin
APP_URL=http://dergagi.changeip.org:8092
DB_CONNECTION=sqlite
DISPLAY_TIMEZONE=Europe/Berlin

Abhängige Services:

InfluxDB: speedtest-influxdb-v2 (Port 8087)
Datenbank: SQLite (primär) + InfluxDB (optional)

Datenbank & Speicherung

SQLite-Datenbank:

Container-Pfad: /config/database.sqlite
Docker-Volume: speedtest-app-data
Backup-relevant: Ja

InfluxDB (optional):

Container: speedtest-influxdb-v2
Port: 8087
Login: admin / SpeedTest2025!

Automatisierung

Test-Schedule:

Intervall: Alle 10 Minuten
Server: Verizon.com (ID: 52770)
Geschwindigkeit: 944+ Mbps (typisch)
Wartung: Keine manuelle Wartung erforderlich

Cron-Format Erklärung:

*/10 * * * *
│    │ │ │ │
│    │ │ │ └── Wochentag (0-7, Sonntag = 0 oder 7)
│    │ │ └──── Monat (1-12)
│    │ └────── Tag (1-31)
│    └──────── Stunde (0-23)
└────────────── Minute (0-59, */10 = alle 10 Minuten)

Container-Management

Neustart:

bash

cd /opt/speedtest-tracker-new
docker-compose restart speedtest-tracker

Komplett-Neustart:

bash

cd /opt/speedtest-tracker-new
docker-compose down
docker-compose up -d

Status prüfen:

bash

docker ps | grep speedtest-tracker-new

Logs anzeigen:

bash

docker logs speedtest-tracker-new
docker logs speedtest-tracker-new --tail 50

Konfigurationsprüfung

Environment-Variablen checken:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST

Container-Config anzeigen:

bash

docker inspect speedtest-tracker-new | grep -A10 -B10 SPEEDTEST

Service-Erreichbarkeit:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:8092

Web-Interface Funktionen

Hauptfunktionen:

Automatische Tests alle 10 Minuten
Historische Datenansicht
Server-Auswahl und -Konfiguration
Statistiken und Trends
Export-Funktionen

Wichtige Settings:

Default Server: Verizon.com (52770)
Schedule: */10 * * * * (alle 10 Minuten)
Timezone: Europe/Berlin

Troubleshooting

Häufige Probleme:

1. Container startet nicht:

bash

docker logs speedtest-tracker-new
# Prüfe Environment-Variablen und Dependencies

2. Tests laufen nicht automatisch:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST_SCHEDULE
# Sollte zeigen: SPEEDTEST_SCHEDULE="*/10 * * * *"

3. Falscher Server wird verwendet:

bash

docker exec speedtest-tracker-new env | grep SPEEDTEST_SERVERS
# Sollte zeigen: SPEEDTEST_SERVERS=52770

4. Web-Interface nicht erreichbar:

bash

curl -v http://localhost:8092
# Prüfe Port-Mapping und Container-Status

Backup & Wiederherstellung

Wichtige Backup-Pfade:

Docker-Compose: /opt/speedtest-tracker-new/docker-compose.yml
Daten-Volume: speedtest-app-data
InfluxDB-Volume: influxdb-data (falls verwendet)

Backup erstellen:

bash

cd /opt/speedtest-tracker-new
cp docker-compose.yml docker-compose.yml.backup-$(date +%Y%m%d-%H%M%S)
docker run --rm -v speedtest-app-data:/data -v $(pwd):/backup alpine tar czf /backup/speedtest-data-backup-$(date +%Y%m%d).tar.gz -C /data .

Server-Informationen

Verizon.com Server (52770):

Standort: USA
Typische Geschwindigkeit: 944+ Mbps Download
Latenz: ~26ms
Zuverlässigkeit: Hoch
Grund der Auswahl: Beste Geschwindigkeit in Tests

Wartung

Regelmäßige Checks: Keine erforderlich

Log-Rotation: Automatisch durch Docker

Updates: Bei Bedarf über docker-compose pull

Überwachung: Über Uptime Kuma integriert

Grafana Konfiguration

Setup-Datum: 04.09.2025

System: Grafana + Prometheus + Node Exporter

Status: Real-time Monitoring aktiv

Installation & Zugriff

Container-Details:

Container-Name: grafana-system
Netzwerk: Host-Netzwerk
URL: http://dergagi.changeip.org:3000
Login: admin / QgdQh9ksJraVHL

Prometheus-Stack

Prometheus-Container:

Name: prometheus-system
Netzwerk: Host-Netzwerk
Port: 9090 (intern)
URL: http://localhost:9090

Node Exporter:

Name: node-exporter-system
Port: 9100
Sammelt: CPU, RAM, Disk, Network-Metriken

Datasource-Konfiguration

Prometheus-Datasource:

Name: Prometheus-System
Type: Prometheus
URL: http://localhost:9090
Access: Proxy
Default: Yes
UID: eex39fbvthon4f

Dashboard

Node Exporter Full Dashboard:

Metriken: CPU-Auslastung, RAM-Verbrauch, System-Load, Disk-Space, Network-Traffic
Refresh: 30 Sekunden
Zeitbereich: Konfigurierbar (Standard: letzte Stunde)

Container-Management

Grafana-Neustart:

bash

docker stop grafana-system
docker rm grafana-system
docker run -d --name grafana-system --network host --restart=unless-stopped \
  -e GF_SECURITY_ADMIN_USER=admin \
  -e GF_SECURITY_ADMIN_PASSWORD=QgdQh9ksJraVHL \
  grafana/grafana:latest

Status-Check:

bash

docker ps --format "table {{.Names}}\t{{.Status}}" | grep -E "(grafana|prometheus|node-exporter)"

Überwachte Metriken

CPU:

Auslastung in Prozent
System vs. User vs. Idle
Load Average (1m, 5m, 15m)

Memory:

RAM-Verbrauch absolut und prozentual
SWAP-Nutzung
Cache + Buffer

Disk:

Speicherplatz aller Partitionen
I/O-Statistiken
Disk-Usage-Trends

Network:

Ein-/Ausgehender Traffic
Bytes pro Sekunde
Interface-Status

Troubleshooting

Grafana-Erreichbarkeit:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:3000

Prometheus-Verbindung:

bash

curl -s -o /dev/null -w "Status: %{http_code}" http://localhost:9090/api/v1/query?query=up

Container-Logs:

bash

docker logs grafana-system
docker logs prometheus-system
docker logs node-exporter-system

Wartung

Automatisierung: Vollautomatisch, keine manuelle Wartung

Datensammlung: Alle 30 Sekunden

Retention: Standard Prometheus-Einstellungen

Backup: Container-Volumes bei System-Backup eingeschlossen

Portainer Konfiguration

Zugang:

URL: http://100.108.194.126:9000 (über Tailscale)
Lokaler Zugang: http://localhost:9000
Status: Vollständig funktional

Container-Setup:

Container: portainer
Image: portainer/portainer-ce:latest
Port-Binding: 100.108.194.126:9000→9000/tcp, 127.0.0.1:9000→9000/tcp
Docker-Compose: /srv/portainer/docker-compose.yml

Daten-Persistierung:

Datenbank: /srv/portainer/data/portainer.db (524KB)
Zertifikate: /srv/portainer/data/certs/ (SSL-Certs)
Konfiguration: /srv/portainer/data/docker_config/

Tailscale-Integration:

Tailscale-IP: 100.108.194.126
Interface: tailscale0 (aktiv)
Netzwerk: hassio Docker-Netzwerk verfügbar

Funktionsumfang:

Vollständige Docker-Container-Verwaltung
Monitoring aller STORE2-Services
Image-Management und Container-Logs
Network- und Volume-Verwaltung

Letzte Wiederherstellung: 03.09.2025, aus /mnt/nvme_backup/daily.0/srv/portainer

Uptime Kuma Monitoring - Setup-Dokumentation

Datum: 3. September 2025

Status: Vollständig konfiguriert und produktiv

System-Übersicht

Uptime Kuma Installation:

Version: 1.23.13-alpine (stabile Produktionsversion)
Zugang: http://192.168.1.102:3001
Admin-User: dergagi
Container: uptime-kuma (Docker)
Daten: /opt/uptime-kuma/data (Bind-Mount)

Überwachte Services (11 aktive Monitore)

Critical Services (5) - Email-Alerts aktiv

Home Assistant - http://dergagi.changeip.org:8123
MediaWiki Store2 - http://dergagi.changeip.org:8088/
Grafana Dashboard - http://dergagi.changeip.org:3030
Nextcloud - https://nc.dergagi9.duckdns.org:8444
Emby - http://dergagi.changeip.org:8096

Media Services (3) - Email-Alerts aktiv

HomeBox - http://dergagi.changeip.org:3100
YT4K Upscaler - http://dergagi.changeip.org:8443/
Store2 Website - https://dergagi.changeip.org/

Development Services (3) - Email-Alerts aktiv

n8n - http://dergagi.changeip.org:5678
Portainer - http://100.108.194.126:9000 (via Tailscale)
Tailscale - 100.108.194.126 (Ping-Monitor)

Email-Benachrichtigungen

SMTP: mail.gmx.net:587 (dergagi@gmx.de → daniel.gareis@gmail.com)
Status: Aktiv für alle 11 Services
Test: Erfolgreich

Systemstatus

11 aktive Monitore: Alle Services grün und stabil
Response Times: 200-300ms (optimal)
Nextcloud: Stabilisiert nach Timeout-Optimierung
Email-System: Vollständig funktional

Das Monitoring-System überwacht erfolgreich die gesamte STORE2-Infrastruktur.

HomeBox Konfiguration

Datum: 03. September 2025

Status: Produktiv, vollständig funktionsfähig

System-Übersicht

Server: STORE2 (192.168.1.102)
OS: Debian 13
Container-System: Docker (Standalone)
Öffentliche URL: http://dergagi.changeip.org:3100

Authentifizierung

Benutzer: daniel.gareis@gmail.com
Passwort: Q6Zv&*YsmDBN3e
Login-URL: http://dergagi.changeip.org:3100/login

Docker-Konfiguration

Container-Name: homebox
Image: ghcr.io/hay-kot/homebox:latest
Port-Mapping: 3100:7745
Volume: /srv/homebox:/data
Restart-Policy: unless-stopped

Container-Management

bash

docker ps | grep homebox
docker stop/start homebox
docker logs homebox --tail 20

Datenbank

Hauptdatenbank: /srv/homebox/homebox.db (192KB)
WAL-File: /srv/homebox/homebox.db-wal (424KB)
Letztes Update: 31. August 2025

Backup & Restore

bash

# Backup
cp -r /srv/homebox /root/homebox-backup-$(date +%Y%m%d-%H%M%S)

# Restore (bei Problemen)
docker stop homebox
rsync -av /mnt/nvme_backup/daily.0/opt/homebox/data/ /srv/homebox/
docker start homebox

Runterfahren über Konsole

umount /data
umount /data2

Falls blockiert, nachschauen wer darauf zugreift mittels

lsof /data 
kill "processid"

shutdown -h now

Webzugang von Außen

in /srv/www/htdocs .htaccess

darin nur den genutzten IPs Zugang erlauben.

Neuer Webuser

htdigest2 /srv/www/.htdigest Store gagihawaii

Webseite verändern

in /srv/www/htdocs/index.template verändern/anpassen

bzw. in /usr/local/bin/update_http.sh Parameter optimieren

dann

/usr/local/bin/update_http.sh

Store2-Website Dokumentation

Übersicht

Die STORE2 Website zeigt System-Monitoring-Daten auf https://dergagi.changeip.org/

Automatisches Update: Alle 5 Stunden via Cronjob
Manuelle Updates: /usr/local/bin/update_store2_website.sh

Architektur

Hauptkomponenten

Website-Template: /var/www/html/index.template
- HTML mit Platzhaltern (z.B. )
- Responsive Design mit blauem Theme
Update-Script: /usr/local/bin/update_http.sh
- Sammelt CPU-Temps, System-Info, RAID-Status
- Ersetzt Platzhalter im Template
- Generiert /var/www/html/index.html
- WICHTIG: Keine HDD-Temperatur-Abfragen mehr (entfernt für Performance)
Heatmap-Service: Port 8020
- Service: heatmap8020.service (systemd)
- Pfad: /opt/heatmap8020/
- Hauptdateien:
  - app.py - FastAPI Web-Interface
  - store2_heatmap.py - Rendering-Engine
- Static Files: /opt/heatmap8020/static/
HDD-Temperatur-Sammler: /usr/local/bin/dt.sh
- Liest Temperaturen von 44 HDDs
- Output-Format: /dev/sdX -> raid slot serial info temp°C
Heatmap-Update: /usr/local/bin/update_heatmap.sh
- Führt dt.sh aus und piped zu store2_heatmap.py
- Generiert PNG in /opt/heatmap8020/static/
- Kopiert zu /var/www/html/heatmap.png
Master-Update-Script: /usr/local/bin/update_store2_website.sh
- Kombiniert Heatmap- und Website-Updates
- Wird vom Cronjob aufgerufen

Datenquellen

CPU-Temperaturen

Tool: sensors (lm-sensors)
6 Kerne (Core 0-5)
Anzeige in °C

System-Speicher

Quelle: /dev/nvme0n1p1
Anzeige: Frei/Total in GB

Swap

Quelle: free -h
Anzeige: Frei/Total in GB

RAID-Arrays

Data (kleineres RAID): /data (~50TB)
Data2 (größeres RAID): /data2 (~58TB)
Status: clean/degraded
Mountpoint-basierte Erkennung (reboot-sicher)

HDD-Temperaturen

44 Festplatten total
Heatmap zeigt:
- Slot-Position (#01-#45)
- Temperatur mit Farbcodierung (35°C grün bis 55°C rot)
- Seriennummer, Kapazität, Hersteller
- RAID-Zugehörigkeit (data/data2)

Service-Links

Die Website verlinkt auf folgende Dienste:

Emby 🎬: Port 8096
Ombi 📋: Port 3579
Navidrome 🎵: Port 4533
HomeBox 📦: Port 3100
CWA 📚: Port 8084 (Calibre)
TV 📺: Port 8089
Wiki 📖: Port 8088 (MediaWiki)

Cronjob-Konfiguration

bash

# Aktiver Cronjob (alle 5 Stunden zur vollen Stunde)
0 */5 * * * /usr/local/bin/update_store2_website.sh >/dev/null 2>&1

Backup-Locations

Vollbackup vom 17.09.2025: /root/STORE2-VOLLBACKUP-FUNKTIONIERT-20250917-195253/
Script-Backups:
- /usr/local/bin/update_http.sh.bak*
- /usr/local/bin/update_http.sh.before-hdd-removal
- /usr/local/bin/update_http.sh.with-all-hdds

Wichtige Pfade

/var/www/html/index.template     # HTML-Template mit Platzhaltern
/var/www/html/index.html         # Generierte Website
/var/www/html/heatmap.png        # Aktuelle HDD-Heatmap
/usr/local/bin/update_http.sh    # Website-Update-Script
/usr/local/bin/update_heatmap.sh # Heatmap-Generator
/usr/local/bin/update_store2_website.sh # Master-Update-Script
/usr/local/bin/dt.sh             # HDD-Temperatur-Sammler
/opt/heatmap8020/                # Heatmap-Service-Verzeichnis

Manuelle Operationen

Website sofort aktualisieren

bash

/usr/local/bin/update_store2_website.sh

Nur Heatmap generieren

bash

/usr/local/bin/update_heatmap.sh

Nur Website-Daten aktualisieren (ohne Heatmap)

bash

/usr/local/bin/update_http.sh

Heatmap-Service neustarten

bash

systemctl restart heatmap8020
systemctl status heatmap8020

HDD-Temperaturen manuell prüfen

bash

/usr/local/bin/dt.sh

Performance-Optimierungen

Entfernte HDD-Abfragen: Ursprünglich waren 40+ einzelne HDD-Temp-Abfragen im update_http.sh Script. Diese wurden komplett entfernt.
Einmalige HDD-Abfrage: HDDs werden nur noch 1x für die Heatmap abgefragt (via dt.sh)
Update-Zeit: Von mehreren Minuten auf ~10 Sekunden reduziert

Fehlerbehebung

Heatmap zeigt keine Daten

Prüfe ob dt.sh korrekte Ausgabe liefert
Prüfe ob heatmap8020.service läuft
Schaue in /opt/heatmap8020/static/ nach generierten PNGs

Website zeigt alte Daten

Manuell updaten: /usr/local/bin/update_store2_website.sh
Browser-Cache leeren (Strg+F5)

Service nicht erreichbar

Apache-Status prüfen: systemctl status apache2
SSL-Zertifikat prüfen
Port 443 muss offen sein

Änderungshistorie

17.09.2025: Große Überarbeitung
- HDD-Temp-Abfragen aus update_http.sh entfernt
- Heatmap-Integration implementiert
- Performance drastisch verbessert
- Cronjob auf neues Master-Script umgestellt

Store-Webseite ändern

Script unter

/usr/local/bin/update_store2_website.sh

Definierte Inhalte unter

/var/www/html/index.template

Generierte Website selbst unter

/var/www/html/index.html

Router

Fritzbox (als Modem)

192.168.178.1

Hitron Kabelmodem (als Modem im Bridge-Mode)

192.168.100.1

TP-Link TL-WR1043ND (als Router und WLAN-AP) und alle späteren Router

192.168.1.1

Webservices

Emby Dokumentation2

System-Übersicht

Technische Details

Netzwerk-Konfiguration

Datenbank-System

Service-Management

Benutzer-Zugang

Integration mit STORE2-Ecosystem

Medien-Bibliothek

Wartung & Updates

Calibre-Web Automated (CWA) auf STORE2

Übersicht

Docker-Konfiguration

docker-compose.yml

Pfade

Automatisierung

SystemD Timer

Cron-Jobs (root)

Geplante Aufgaben (CWA Web-UI, täglich 06:00)

Aktive Features

CWA-Services

Web-UI Einstellungen

Neue eBooks einbinden

Methode 1: Automatischer Import (empfohlen)

Methode 2: Web-Upload

Methode 3: Calibre Desktop Import (für große Mengen)

Import-Scripts

Aktive Scripts (behalten):

Legacy Scripts (archiviert):

Wartung

Container-Neustart

Datenbank-Backup

Logs prüfen

Buchanzahl prüfen

Statistiken

Import-Historie

Performance

Bekannte Einschränkungen

Format-Duplikate

Import-Geschwindigkeit

Tiefe Ordnerstrukturen

Fehlerbehebung

Container startet nicht

CWA zeigt falsche Buchanzahl

Unvollständige Einträge / Fehlende Cover

"Database is locked" Fehler

Monitoring

Live-Monitor (während Import läuft)

Timer-Status prüfen

Apache Reverse Proxy

Wichtige Hinweise

MediaWiki - Aktuelle Konfiguration & Dokumentation

System-Übersicht

Grundkonfiguration

Admin-Zugang

Docker-Setup

Container-Konfiguration

Port-Mapping

Datenbank-Konfiguration

MariaDB-Credentials

Datenbank-Zugriff

MediaWiki-Konfiguration

LocalSettings.php (Zentrale Einstellungen)

Wichtige Konfigurationswerte

Logo-Integration

Daten-Inhalt

Wiki-Seiten (12 Hauptseiten + aktuelle Ergänzungen)

Statistik

Backup-System

Aktuelle Backups

Restore-Prozedur (Aktualisiert)

Docker-Volumes

Volume-Management

Container-Wiederherstellung (03.09.2025)

Durchgeführte Reparaturen

Lessons Learned

Wartung & Maintenance

MediaWiki-Maintenance-Scripts

Monitoring

Queue-Generierung (`make_queue.py`)