---
title: MPTS Migrate Perfect Streamer Toolkit v1.1 — Migration der MPTS-Identität
url: https://doc2.pstreamer.tv/de/manual/toolkit/mpts_migrate.html
lang: de
product: Perfect Streamer
version: 2.0.2.362
---

# MPTS Migrate Perfect Streamer Toolkit v1.1 — Migration der MPTS-Identität

Teil des **Perfect Streamer Toolkit** — [https://pstreamer.tv](https://pstreamer.tv)

Erfasst die DVB-SI/PSI-Identität eines laufenden Mehrprogramm-MPEG-TS-Stroms (MPTS) und bildet sie auf einer Perfect-Streamer-Instanz (PSS) auf demselben Host nach. Ergebnis: Teilnehmerempfänger (STB / TV) arbeiten nach einer Migration oder einer Umschaltung auf die Reserve **ohne erneuten Kanalsuchlauf** weiter.

Das Werkzeug ist Bestandteil des Pakets **pstreamer** und befindet sich nach der Installation unter `/opt/pss/tools/mpts_migrate` — eine separate Installation ist nicht erforderlich.

## Voraussetzungen

Stellen Sie vor dem Start des Dienstprogramms sicher, dass:

- **PSS läuft** auf demselben Host (oder auf einem über `--pss-base` erreichbaren Host). Das Dienstprogramm sucht `pss` in `/proc` und liest `pss.json`, um den Admin-Port zu ermitteln (`43971`, wenn die Konfiguration ihn nicht enthält).
- **Die MPTS-Quelle ist erreichbar**, sofern eine Erfassung vorgesehen ist (Modi 1, 2, save+apply): Die als Positionsargument `<input>` übergebene URL muss einen MPEG-TS-Strom liefern. Für UDP-Multicast müssen IGMP / Firewall den Empfang zulassen; bei Dateien muss der Pfad vorhanden sein.
- **Das Ziel-MPTS ist in PSS bereits eingerichtet**: Das Dienstprogramm legt keine neuen Streams an. Das MPTS-Objekt und mindestens so viele SPTS-Feeder, wie das Inventar Dienste enthält, müssen vorab vorhanden sein. Dienste ohne freien Feeder werden im Dialog angezeigt und können übersprungen werden.
- **Die HTTP-Admin-API ist auf localhost verfügbar** — zum Lesen von `/data/stream` (wird bei verify verwendet) und zum Schreiben von `/config/stream` (apply).

## Was migriert wird

Alle für den Empfänger sichtbaren Kennungen auf Transportstrom- und Dienstebene:

- **Transportstrom**: TSID, ONID, network ID, network name, **provider name** (wird als mux-weiter `sdt-provider-name` angewendet, sofern alle Quelldienste ein und denselben Wert aufweisen), Delivery-Deskriptor (Parameter der terrestrischen / Kabel- / Satellitenübertragung), PAT/SDT/NIT-Versionen
- **Je Dienst**: `service_id`, `pmt_pid`, `pcr_pid`, `service_type`, Dienstname, logische Kanalnummer (LCN), free-CA-Kennzeichen, EIT-present- / EIT-schedule-Kennzeichen
- **Elementarströme**: PIDs (es wird ein `identity remap` angewendet — siehe *Einschränkungen*), Stromtypen, Sprachkennungen
- **Bedingter Zugriff**: CA-Deskriptoren auf Programm- und ES-Ebene

Dienst- / Anbieternamen in DVB-Zeichenkodierungen außerhalb von ASCII (zum Beispiel ISO-8859-5 für Kyrillisch) werden automatisch nach UTF-8 dekodiert.

Für jeden Dienst wird das ES-PID-Remapping als Identitätspaare (`mpegts-pid-old` ≡ `mpegts-pid-new`) für jede PCR- / Video- / Audio- / Teletext- / Daten-PID aufgebaut, sodass die ursprünglichen PIDs in der resultierenden multiplexierten Ausgabe **byte-exact** erhalten bleiben. Ältere Empfänger, die die PMT nach dem ersten Suchlauf zwischenspeichern, arbeiten ohne Neukonfiguration weiter.

Ab PSS 2.0.0.193 aktiviert der Plan am Muxer-Eingang des Ziel-MPTS zusätzlich den regulären Modus zur Beibehaltung der ursprünglichen PIDs (deaktiviertes Automatic PID mapping) und setzt für jeden Dienst die erfasste Programmnummer in der PAT (program order) — die On-Air-Reihenfolge der Programme übersteht die Migration. Die Unterstützung wird anhand der Konfiguration des Ziel-Streamers automatisch ermittelt; auf älteren Versionen werden diese Schlüssel nicht gesendet (das Dienstprogramm gibt eine Warnung aus), und die Identitätspaare bleiben der einzige Mechanismus zur Fixierung der PIDs, während die Programmreihenfolge in der PAT nicht erhalten bleibt.

## Anwendungsfälle

- **Failover**: Umschalten der Decoder vom primären MPTS auf das Reserve-MPTS unter Beibehaltung der Kanäle auf der Empfängerseite
- **Hardware-Migration**: Umzug eines laufenden Multiplex von einem PSS-Host auf einen anderen ohne Anweisungen an die Zuschauer
- **Momentaufnahme vor / nach dem Update**: Erfassung des Multiplex vor dem PSS-Update und erneutes Anwenden danach, um bitidentische SI/PSI zu gewährleisten
- **Manuelle Bearbeitung und erneutes Anwenden**: Erfassen, `migrate.json` bearbeiten (Dienste umbenennen, LCN ändern, `service_type` anpassen), erneut anwenden
- **Dry-run-Prüfung**: Ausgabe jedes HTTP POST, der gesendet *würde*, ohne Auswirkung auf PSS

## Schnellstart

```bash
# Capture from a live stream and apply to local PSS in one run
mpts_migrate udp://239.1.1.1:1234

# Capture, save to migrate.json and apply
mpts_migrate -s udp://239.1.1.1:1234

# Capture only — write to file, do not apply
mpts_migrate -o backup.json udp://239.1.1.1:1234

# Apply a previously saved JSON
mpts_migrate -i backup.json

# No arguments — load ./migrate.json and apply
mpts_migrate

# Preview what apply would do, without changes
mpts_migrate -i backup.json --dry-run
```

## Arbeitsablauf

1. **Erfassung** — das Dienstprogramm öffnet den Strom, wertet PAT / PMT / SDT / NIT / EIT über `-t` Sekunden aus (Vorgabe 30) und erstellt das Inventar; die Gesamtbitrate des Stroms wird gemessen.
2. **(Optional) Speichern** — mit `-s` oder `-o` wird das Inventar zur Wiederverwendung als JSON geschrieben.
3. **PSS-Ermittlung** — erkennt das laufende PSS über einen `/proc`-Scan und liest `pss.json`, um den Admin-Port zu ermitteln (`43971`, wenn die Konfiguration ihn nicht enthält); `--pss-base http://host:port` umgeht die automatische Ermittlung.
4. **Bestätigung der Zuordnung** — ein interaktiver Dialog fragt ab, wie jeder erfasste Dienst einem vorhandenen SPTS-Feeder zugeordnet werden soll; `--non-interactive` übernimmt die Vorschläge und bricht bei einem Konflikt ab; `--target-mpts <id>` überspringt die Abfrage zur MPTS-Auswahl.
5. **Automatisches Aufheben der Feeder-Pause** — für jeden zugeordneten SPTS / muxer-output sendet das Dienstprogramm `{"pause":false}`, falls der Feeder pausiert war, damit der Multiplexer nach dem Apply tatsächlich Daten erhält.
6. **Automatische Bitratenanpassung** — überschreitet `captured_bitrate × (1 + headroom%)` die `mpegts-output-bitrate` des Ziel-MPTS, hebt das Dienstprogramm dieses Limit auf PSS mit einem einzigen POST an (mit Aufrundung auf die nächsten 1000 kbps). Abschaltbar über `--no-bitrate-adjust`.
7. **Planung** — vergleicht das Inventar mit dem aktuellen `/config/stream`-Baum auf PSS und bereitet HTTP-POST-Anfragen nur für die abweichenden Felder vor. Das ES-PID-Remapping wird als Identitätspaare (`mpegts-pid-old` ≡ `mpegts-pid-new`) erzeugt, damit die multiplexierte Ausgabe jede ursprüngliche PID unverändert beibehält — einschließlich PCR, Video, Audio, Teletext, SCTE-35, DSM-CC. Ab PSS 2.0.0.193 aktiviert der Plan zusätzlich den Modus zur Beibehaltung der ursprünglichen PIDs am Muxer-Eingang des Ziels und setzt die Programmreihenfolge in der PAT (siehe *Was migriert wird*).
8. **Anwenden** — sendet die geplanten POST-Anfragen und schaltet anschließend das MPTS auf pause/unpause, damit PSS die Konfiguration neu einliest; mit `--dry-run` wird der Plan lediglich ausgegeben.
9. **Verify** (standardmäßig aktiviert, auch bei leerem Plan) — erfasst das resultierende MPTS über einen der UDP-Ausgänge von PSS und vergleicht es mit dem Ziel; kritische Abweichungen (TSID, ONID, service_id, name, type, LCN) → Exit-Code 5.

Ein erneuter Durchlauf der gesamten Verarbeitungskette ist **idempotent**: Der zweite Lauf meldet `no changes needed`, wenn PSS bereits dem Inventar entspricht, und verify bestätigt dies mit einer neuen Erfassung.

## CLI-Optionen

### Modusauswahl

| Option | Beschreibung | Standard |
| --- | --- | --- |
| `-f, --file <path>` | Pfad zum Migrations-JSON (dient als Standardimport, wenn `-i` fehlt, und als Speicherziel mit `-s`) | `./migrate.json` |
| `-s, --save` | Erfasstes Inventar in die Migrationsdatei speichern (kombinierbar mit einem Stromeingang; apply wird dennoch ausgeführt) | — |
| `-o, --output <file>` | Nur Erfassung: Schreiben in die Datei, kein apply | — |
| `-i, --input <file>` | Nur apply: Datei laden, keine Erfassung | — |

### Erfassung

| Option | Beschreibung | Standard |
| --- | --- | --- |
| `-t, --time <sec>` | Maximale Erfassungsdauer | `30` |
| `-b, --bitrate <Mbps>` | Hinweis zur TS-Bitrate für das Pacing im Dateimodus | `38.8` |

### Apply / Verify

| Option | Beschreibung | Standard |
| --- | --- | --- |
| `--target-mpts <id>` | Abfrage zur MPTS-Auswahl überspringen; auf diese stream id auf PSS anwenden | — |
| `--non-interactive` | Vorschläge des Dialogs automatisch übernehmen; bei einem Konflikt beenden | — |
| `--dry-run` | Plan der POSTs ausgeben, nichts senden | — |
| `--pss-base <url>` | Automatische PSS-Ermittlung überschreiben (zum Beispiel `http://host:8808`) | automatisch |
| `--no-verify` | Erfassung und Diff nach dem Apply überspringen | verify aktiviert |
| `--verify-time <s>` | Erfassungsfenster für die Verifikation | `10` |
| `--no-bitrate-adjust` | `mpegts-output-bitrate` am Ziel-MPTS nicht anheben | Anhebung aktiviert |
| `--bitrate-headroom <pct>` | Bitratenreserve über dem gemessenen Wert bei der Anpassung | `15` |

### Sonstiges

| Option | Beschreibung |
| --- | --- |
| `-v, --verbose` | Ausführliches Protokoll (jeder HTTP POST und jeder Dialogzweig) |
| `-h, --help` | Hilfe anzeigen und beenden |

## Migrationsdatei (`migrate.json`)

Menschenlesbares JSON mit `format_version: 1`. Die Standardablage ist `./migrate.json`; sie wird mit `-f` überschrieben. Beispiel für den Aufbau:

```json
{
  "format_version": 1,
  "tool": "mpts_migrate",
  "capture": {
    "source": "udp://239.1.1.1:1234",
    "captured_at_utc": "2026-04-30T08:15:00Z",
    "duration_s": 8.2,
    "packets": 109344
  },
  "transport_stream": {
    "transport_stream_id": 1234,
    "original_network_id": 8442,
    "network_name": "Operator",
    "delivery": { "type": "terrestrial", "frequency_khz": 522000 }
  },
  "services": [
    {
      "service_id": 1, "pmt_pid": 256, "pcr_pid": 256,
      "service_type": 1, "service_name": "Channel 1",
      "provider_name": "MyProvider", "logical_channel_number": 101,
      "program_order": 1,
      "free_ca_mode": false,
      "elementary_streams": [
        { "pid": 256, "stream_type": 27, "language": "rus" }
      ]
    }
  ]
}
```

Die Datei kann vor einem erneuten Apply bearbeitet werden: Dienste umbenennen, LCN ändern, `service_type` wechseln, `network_name` anpassen — `mpts_migrate -i migrate.json` sendet nur die geänderten Felder.

## Verbindung zu PSS

- **Automatische Ermittlung**: Durchsuchen von `/proc/<pid>/comm` nach `pss`, Lesen der zugehörigen `--config`-Datei, Übernahme von `web-server.bind-port` (`43971`, wenn der Schlüssel fehlt).
- **Manuell**: `--pss-base http://host:port` umgeht die automatische Ermittlung vollständig. Nützlich für ein entferntes PSS oder wenn `--dry-run` einen Plan ohne laufendes PSS erstellen soll.
- Die Admin-REST-API erfordert auf `localhost` keine Authentifizierung.

## Verifikation

Wenn `--no-verify` **nicht** angegeben ist (Vorgabe), führt das Dienstprogramm nach dem Anwenden des Plans Folgendes aus:

1. Sucht am Ziel-MPTS einen UDP-Ausgang auf localhost oder fügt vorübergehend einen auf `127.0.0.1:<auto>` hinzu (mit dem Vermerk `added by mpts_migrate for verification`).
2. Erfasst das laufende MPTS über diesen Ausgang für `--verify-time` Sekunden (Vorgabe 10).
3. Vergleicht das erfasste Inventar mit dem Ziel:

   - **Kritische** Abweichung (TSID, ONID, network name, service_id, name, type, LCN) → Exit-Code **5**.
   - **Weiche** Abweichung (PMT PID, Anzahl der ES, Anbietername, Programmreihenfolge in der PAT) → wird als Warnung ausgegeben, Exit-Code 0.
4. Ist das Ziel-MPTS überlastet (Ausgangsbitrate ≥ der konfigurierten `mpegts-output-bitrate`), wird `WARNING: target MPTS is overloaded` ausgegeben — siehe *Bitrate adjust* weiter unten.

## Dry-run

`--dry-run` gibt jede HTTP-Anfrage aus, die das Dienstprogramm senden *würde* (Pfad, JSON-Rumpf), sendet jedoch keine davon. Nützlich für:

- Die Durchsicht des Plans mit dem Bediener vor der Übernahme.
- Die Erzeugung reproduzierbarer Änderungssätze in CI / Change-Management.
- Den Betrieb bei nicht erreichbarem PSS (zu kombinieren mit `--pss-base http://host:port`).

Dry-run startet keine Verifikation.

## Bitrate adjust

Überschreitet `captured_bitrate × (1 + headroom%)` standardmäßig die `mpegts-output-bitrate` des Ziel-MPTS, hebt das Dienstprogramm dieses Limit auf PSS an, bevor die SI/PSI-Änderungen angewendet werden. Ohne ausreichende Reserve verliert ein überlastetes MPTS Daten niedriger Priorität — typische Symptome sind Tonaussetzer bei Radiodiensten und sporadische EIT-CRC-Fehler. Abschaltbar über `--no-bitrate-adjust`; die Reserve wird über `--bitrate-headroom <pct>` eingestellt (Vorgabe `15`).

## Exit-Codes

| Code | Bedeutung |
| --- | --- |
| `0` | Erfolg — apply und (sofern aktiviert) die Verifikation sind fehlerfrei durchgelaufen. Wird auch von einem erfolgreichen `--dry-run` zurückgegeben. |
| `1` | Fehler bei Argumenten / Datei / Ermittlung |
| `2` | In der Quelle wurde keine PAT gefunden — der Eingang ist kein gültiger MPEG-TS oder das Erfassungsfenster ist zu kurz; wird auch zurückgegeben, wenn der Bediener die Bestätigung der Zuordnung abgelehnt oder den Dialog verlassen hat (apply abgebrochen) |
| `3` | Ein oder mehrere HTTP POSTs des Apply sind fehlgeschlagen |
| `4` | Apply war erfolgreich, das Ziel-MPTS ist jedoch nicht in den Zustand *Running* zurückgekehrt |
| `5` | Die Verifikation ist fehlgeschlagen — der erfasste Strom weicht in kritischen Feldern vom Ziel ab |

## Einschränkungen und Fallstricke

- **PSS muss das Ziel-MPTS und die Feeder bereits vorhalten**: Das Dienstprogramm legt keine neuen Streams an. Das Ziel-MPTS und mindestens so viele SPTS-Feeder, wie das Inventar Dienste enthält, müssen vorab vorhanden sein; Dienste ohne freien Feeder werden im Dialog übersprungen.
- **Die MPTS-Quelle muss während der Erfassung erreichbar sein** (Modi 1, 2, save+apply): Die als Positionsargument `<input>` übergebene URL muss einen MPEG-TS-Strom liefern; für UDP-Multicast müssen IGMP / Firewall dies zulassen.
- **Das ES-PID-Remapping wird automatisch angewendet**: Für jeden Dienst wird ein Identity-Remap (`mpegts-pid-old` ≡ `mpegts-pid-new`) für jede PCR-/Video-/Audio-/Teletext-/Daten-PID erzeugt, damit die multiplexierte Ausgabe die ursprünglichen PIDs byte-exact beibehält. Das PMT-Layout bleibt von Migration zu Migration stabil — selbst ältere Empfänger (STB vor 2015, Samsung vor der H-Serie, LG vor WebOS 3.0), die PIDs zwischenspeichern, benötigen keinen erneuten Suchlauf.
- **Der Delivery-Deskriptor muss dem tatsächlichen Übertragungsweg entsprechen** — für Empfänger, die sich über die NIT neu abstimmen (DVB-T/T2/C/S). Ein nicht passender `delivery`-Block kann den Empfänger auf eine falsche Frequenz führen.
- **Die Konsistenz der LCN** zwischen primärem und Reserve-MPTS ist für Failover entscheidend — unterscheiden sie sich, verschieben sich die Kanalpositionen in der Empfängerliste nach der Umschaltung.
- **Der Provider name ist in PSS mux-weit gültig** (ein `sdt-provider-name` je MPTS-Muxer-Eingang). Das Dienstprogramm wendet ihn automatisch an, wenn alle erfassten Dienste ein und denselben Wert aufweisen; tragen verschiedene Dienste unterschiedliche `provider_name`-Werte, wird eine Warnung ausgegeben und das Feld bleibt unberührt — die Entscheidung liegt beim Bediener.
- **Kein PSS-Konfigurationswerkzeug**: `mpts_migrate` berührt ausschließlich die SI/PSI-Identitätsfelder, das `pause`-Kennzeichen jedes Feeders, (optional) `mpegts-output-bitrate` sowie ab PSS 2.0.0.193 die Schlüssel für den PID-Beibehaltungsmodus und die Programmreihenfolge. Encoder, Eingänge, Verschlüsselung, Zeitpläne und Ähnliches konfiguriert es nicht.
- **Auf PSS älter als 2.0.0.193** werden der Modus zur Beibehaltung der ursprünglichen PIDs am Muxer und die Programmreihenfolge in der PAT nicht unterstützt: Das Dienstprogramm gibt eine Warnung aus, die PIDs werden allein durch Identitätspaare fixiert, und die Programmreihenfolge kann nach der Migration von der ursprünglichen abweichen.

## Fehlerdiagnose

| Symptom | Wahrscheinliche Ursache / Abhilfe |
| --- | --- |
| `Error: no PAT seen in stream` | Die Quelle ist kein MPEG-TS, IGMP/Firewall blockiert den Multicast, oder `-t` ist zu kurz |
| `Error: cannot reach PSS` | `--pss-base http://host:port` verwenden, um die automatische Ermittlung zu umgehen |
| Apply war erfolgreich, das MPTS bleibt jedoch pausiert | Das PSS-Protokoll prüfen; mit `-v` erneut starten, um den vollständigen Plan der POSTs zu sehen |
| Die Verifikation meldet eine kritische Abweichung | Ziel und erfassten Strom im JSON vergleichen; meist wurde ein Feeder im Dialog dem falschen Dienst zugeordnet |
| `WARNING: target MPTS is overloaded` | `mpegts-output-bitrate` auf PSS anheben oder `--bitrate-headroom <higher %>` verwenden; ohne Reserve werden das Audio der Radiodienste und die PSI-Tabellen beschädigt |