tvstreamrecord - Aufzeichnen von HTTP-Streams

hulahoop

Benutzer
Mitglied seit
04. Jan 2019
Beiträge
33
Punkte für Reaktionen
1
Punkte
8
Verstehe ich nicht. Was würde das erklären? Ich hatte ja exakt das gleiche Verhalten auch vorher. Mit dem Unterschied, dass nun die Deltas (vorher/nachher) stimmen. Das eigentliche Problem bleibt aber.
Und nach dem Ändern der Deltas (in der xmltv.py) habe ich erst alle Logs, dann den EPG und dann alle programmierten Aufzeichnungen gelöscht und dann TSR neu gestartet. Es war also quasi alles auf "Null". Also "Laborbedingungen" für die Funktion der automatischen Aufzeichnungs-Programmierung.
 

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
So ein Versatz um eine Minute kann ich mir nur damit erklären, dass Du den ersten EPG-Durchlauf mit Delta -5/+15 gemacht, und dann Dein Delta auf -4/+14 verändert hast, wodurch neue Aufnahmen generiert wurden (oder umgekehrt). So kann ich es jedenfalls nachstellen.
 

hulahoop

Benutzer
Mitglied seit
04. Jan 2019
Beiträge
33
Punkte für Reaktionen
1
Punkte
8
Nö, die Deltas sind bei mir schon Ewigkeiten (Jahren) unverändert auf -5/+15 - daran hab ich nichts geschraubt. Hatte nur den von Dir genannten Dreher in der xmltv.py korrigiert.
Wie gesagt, ich hatte alles gelöscht und wieder bei Null angefangen, um die perfekte Ausgangslage zu haben. Es wurden keinerlei Einstellungen geändert und erst Recht nicht die Deltas. Damit würde sich zwar die erneute Programmierung zu einer anderen Zeit erklären lassen. Nicht aber die Programmierung zwei Mal zur selben Zeit. Aber wie gesagt - Deltas sind/waren unangetastet.

FunFact. Das Phänomen tritt auch scheinbar nur bei den Sat.1 Nachrichten auf. Bei den RTL Nachrichten ist alles ganz normal. Liegt das jetzt an meiner EPG Quelle, oder am Sender? Wobei das aus meiner Sicht immer noch nicht nicht erklären würde, warum zwei exakt gleiche Programmierungen entstehen können....
Aber nochmal generell die Frage - gibt es keine Möglichkeiten, nahezu identische Aufnahmen der gleichen Sendung, mit dem gleichen Namen auf dem gleichen Sender zur nahezu gleichen bzw. gleichen Uhrzeit zu unterbinden?

PS: Du siehst ja aber auch bei den Tagen, an denen 3 mal das gleiche programmiert wurde, dass die Zeiten oftmals auch exakt identisch sind. Also z.B. 19:50 - 20:29, da würde dann die Theorie mit dem geänderten Delta keine Rolle spielen bzw. widerlegt sein ....

1662299165840.png
 
Zuletzt bearbeitet:

OliOS/2

Benutzer
Mitglied seit
26. Aug 2018
Beiträge
19
Punkte für Reaktionen
1
Punkte
3
Ich habe ein ähnliches Problem mit den "Deltas". Allerdings werden die Aufnahmen bei mir nicht "verdoppelt". Ich beobachte bei mir, glücklicherweise allerdings recht selten und leider bisher nicht nachvollziehbar, folgendes Problem: Die Sendung wird ganz regulär für 20:15 Uhr programmiert. (Die beiden Deltas sind jeweils auf 5 Minuten eingestellt, sodass es bei mir keinen Unterschied macht, dass diese im Code vertauscht wurden.)
Nun kommt ab und zu vor, dass die Sendung erst 5 Minuten später beginnt. Also statt 20:10 Uhr beginnt die Aufnahme erst um 20:20 Uhr.
Vielleicht hilft diese Information bei der Fehlersuche.
 

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
Ich habe ein ähnliches Problem mit den "Deltas". Allerdings werden die Aufnahmen bei mir nicht "verdoppelt". Ich beobachte bei mir, glücklicherweise allerdings recht selten und leider bisher nicht nachvollziehbar, folgendes Problem: Die Sendung wird ganz regulär für 20:15 Uhr programmiert. (Die beiden Deltas sind jeweils auf 5 Minuten eingestellt, sodass es bei mir keinen Unterschied macht, dass diese im Code vertauscht wurden.)
Nun kommt ab und zu vor, dass die Sendung erst 5 Minuten später beginnt. Also statt 20:10 Uhr beginnt die Aufnahme erst um 20:20 Uhr.
Vielleicht hilft diese Information bei der Fehlersuche.
Das kenne ich allerdings nicht... bitte um mehr Info, falls es zu sehr nervt.
 

hulahoop

Benutzer
Mitglied seit
04. Jan 2019
Beiträge
33
Punkte für Reaktionen
1
Punkte
8
Vielleicht liefert Deine EPG-Quelle aktualisierte Daten für den Sender, falls sich die Nachrichten tatsächlich verschieben... Wie auch immer, mit etwas SQL sollte es möglich sein, die Aufnahmen zu unterdrücken, wenn sie sich mit bestehenden überschneiden:
https://github.com/Pavion/tvstreamrecord/commit/627e89c5b12b943737d441674a242d821e256966
Vielen Dank für deine (sonntäglichen) Bemühungen!! 🥳🏆

Noch zwei generelle Fragen zum Verständnis.
- Wie ist denn normal das Vorgehen bei "automatic records" wenn jeden Tag beim Import die Sendungen abgeglichen werden? Da muss es ja auch schon einen Abgleich geben, was schon programmiert wurde, oder?

- ist das "etwas SQL" von Dir nun ein FIX für exakt gleiche Überschneidungen (also 2x exakt gleiche Uhrzeit) - oder geht das auch mit Delta, sprich ist damit auch das Problem gelöst, wenn die gleiche Sendung mit 1-2 Minuten Unterschied schon programmiert ist?

Danke und Grüße

hula
 

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
1) Jain :) Es gab keinen Abgleich, es wurde einfach jedes Mal versucht die Sendung neu zu erstellen, was aber normalerweise an dem Primärschlüssel der DB (Sender; Von; Bis) von alleine gescheitert ist;

2) Jetzt wird mit dem schönen SQL im Vorfeld geprüft, ob es bereits eine Sendung mit dem gleichen Sender; Von ± DeltaVon; Bis ± DeltaBis gibt. Falls ja, wird keine Neue erstellt.

Das sollte Dein Problem hoffentlich erschlagen!

Grüße
Pav
 
  • Like
Reaktionen: hulahoop

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
14.160
Punkte für Reaktionen
407
Punkte
393
  • Like
Reaktionen: Pavion und peko

peko

Benutzer
Mitglied seit
20. Sep 2021
Beiträge
2
Punkte für Reaktionen
1
Punkte
53
Hallo Götz,

danke hat beim Testen funktioniert. Jetzt muss ich noch die Sendernamen anpassen.

Viele Grüße, Peter
 
  • Like
Reaktionen: Pavion

volsch

Benutzer
Mitglied seit
12. Nov 2022
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
1) Jain :) Es gab keinen Abgleich, es wurde einfach jedes Mal versucht die Sendung neu zu erstellen, was aber normalerweise an dem Primärschlüssel der DB (Sender; Von; Bis) von alleine gescheitert ist;

2) Jetzt wird mit dem schönen SQL im Vorfeld geprüft, ob es bereits eine Sendung mit dem gleichen Sender; Von ± DeltaVon; Bis ± DeltaBis gibt. Falls ja, wird keine Neue erstellt.

Das sollte Dein Problem hoffentlich erschlagen!

Grüße
Pav
Ich habe diese Vervielfachungen auch ab und zu. Resultiert aus meiner Sicht daraus, dass im EPG die Sendung (aus aktuellem Anlass) etwas verschoben wird. Jetzt bleibt die Sendung mit der alten Zeit stehen und eine mit der neuen Zeit kommt dazu. Wenn Du die neue Zeit zugunsten der vorhandenen Aufnahmezeit verwirfst, ist das eine Verschlimmbesserung. Neue Zeit sollte alte Zeit ersetzen.
 

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
Ich habe diese Vervielfachungen auch ab und zu. Resultiert aus meiner Sicht daraus, dass im EPG die Sendung (aus aktuellem Anlass) etwas verschoben wird. Jetzt bleibt die Sendung mit der alten Zeit stehen und eine mit der neuen Zeit kommt dazu. Wenn Du die neue Zeit zugunsten der vorhandenen Aufnahmezeit verwirfst, ist das eine Verschlimmbesserung. Neue Zeit sollte alte Zeit ersetzen.
Das stimmt nicht ganz. Ich prüfe ja, ob die neue Zeit in der alten Zeit ± Delta liegt, nur dann wird die neue Zeit verworfen. Das heißt, die gesamte Sendung würde dennoch aufgenommen, dafür ist das Delta ja da. Erst wenn die Abweichung zu gravierend ist, so dass diese Bedingung fehlschlägt, wird eine neue Aufnahme angelegt.
 

volsch

Benutzer
Mitglied seit
12. Nov 2022
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Das stimmt nicht ganz. Ich prüfe ja, ob die neue Zeit in der alten Zeit ± Delta liegt, nur dann wird die neue Zeit verworfen. Das heißt, die gesamte Sendung würde dennoch aufgenommen, dafür ist das Delta ja da. Erst wenn die Abweichung zu gravierend ist, so dass diese Bedingung fehlschlägt, wird eine neue Aufnahme angelegt.
Ah, OK. Dann ist mein Problem davon unabhängig.
 

kinkel13

Benutzer
Mitglied seit
25. Mrz 2013
Beiträge
31
Punkte für Reaktionen
0
Punkte
6
Hallo Pavion,

ich bin vor geraumer Zeit von EyeTV Netsteam Sat auf EyeTV Netstream 4Sat umgestiegen.
Ich habe nun seit dem Umstieg das erste Mal versucht über tvstreamrecords ein Sendung aufzunehmen. Leider scheint irgendetwas nicht zu passen. Die IP ist im 4 Sat die gleiche wie im vorherigen Setting. (bei diesem liefen die Aufnahmen reibungslos). Kannst du aus dem anhängenden Log Aussagen zu meinem Problem machen? Wie bekomm ich die Sache zum Laufen?

Die rtsp-Adresse (hier Das Erste HD) funktioniert, eingefügt im VLC-Player wird der Sender abgespielt.

Weihnachtliche Grüße
kinkel13
 

Anhänge

  • Bildschirmfoto 2022-12-26 um 17.01.59.png
    Bildschirmfoto 2022-12-26 um 17.01.59.png
    131 KB · Aufrufe: 12
Zuletzt bearbeitet:

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
Hallo zurück!
Auf den ersten Blick kann es mehrere Ursachen haben:
- prüfe bitte, dass Du ffmpeg installiert hast (mit Video Station oder manuell) und gib bei Bedarf den kompletten Pfad in den Einstellungen ein
- passe die Befehlszeile für ffmpeg an: -loglevel error sollte mehr Information anzeigen
- versuche Deine Dateierweiterung in mp4 oder mkv zu ändern
Diese und weitere Tipps findest Du auch in meiner Anleitung:
https://github.com/Pavion/tvstreamrecord#ffmpeg-support
Gruß
Pav
 

kinkel13

Benutzer
Mitglied seit
25. Mrz 2013
Beiträge
31
Punkte für Reaktionen
0
Punkte
6
Hallo zurück!
Auf den ersten Blick kann es mehrere Ursachen haben:
- prüfe bitte, dass Du ffmpeg installiert hast (mit Video Station oder manuell) und gib bei Bedarf den kompletten Pfad in den Einstellungen ein
- passe die Befehlszeile für ffmpeg an: -loglevel error sollte mehr Information anzeigen
- versuche Deine Dateierweiterung in mp4 oder mkv zu ändern
Diese und weitere Tipps findest Du auch in meiner Anleitung:
https://github.com/Pavion/tvstreamrecord#ffmpeg-support
Gruß
Pav
Hallo Pav,

Danke für deine Unterstützung.

- habe ffmpeg installiert (DS Pfad: /bin/ffmpeg)
- Befehlszeile angepasst
- Dateierweiterung geändert auf mp4

leider ohne erfolgt. (Siehe Screenshot)

Was mich stutzig macht. Als Fehler wird das Protocol in Frage gestellt. bzw. nicht gefunden. (Protocol not found)

Über deine GitHub Hilfeseite bin ich leider auch nicht viel schlauer geworden. Die Terminaleingabe und -suchgeschichte ist mir zu komplex, dazu bin ich zuwenig erfahren mit ssh.
 

Anhänge

  • Bildschirmfoto 2022-12-27 um 11.48.23.png
    Bildschirmfoto 2022-12-27 um 11.48.23.png
    147,2 KB · Aufrufe: 10

Pavion

Benutzer
Mitglied seit
02. Feb 2013
Beiträge
567
Punkte für Reaktionen
14
Punkte
44
Protocol not found sollte bedeuten, dass die ffmpeg-Version, die Du installiert hast, kein rtsp kann...
Versuche vielleicht entweder die Version von der VideoStation
Code:
/volume1/@appstore/VideoStation/bin/ffmpeg
oder lade ffmpeg separat herunter (wie in meiner Anleitung beschrieben), entpacke es im Aufnahmeordner und gib dann seinen Pfad ein, z.B.
Code:
/volume1/Aufnahmen/ffmpeg/ffmpeg
 

kinkel13

Benutzer
Mitglied seit
25. Mrz 2013
Beiträge
31
Punkte für Reaktionen
0
Punkte
6
Naben Par,

alles gemacht wie angesagt.
Jetzt scheint er das Protocol zu finden. Leider wirft er jetzt eine andere Fehlermeldung raus. (Bild 1)
Stelle ich in der erweiterten FFMPEG-Konfig
Legacy-Aufzeichnungsmethode für http-Streams verwenden ein
Kommt dann die andere Fehlermeldung (Bild 2)
Ich verzweifle hier noch.
 

Anhänge

  • Bildschirmfoto 2022-12-30 um 20.41.06.png
    Bildschirmfoto 2022-12-30 um 20.41.06.png
    103,7 KB · Aufrufe: 11
  • Bildschirmfoto 2022-12-30 um 20.49.34.png
    Bildschirmfoto 2022-12-30 um 20.49.34.png
    76,8 KB · Aufrufe: 10
Zuletzt bearbeitet von einem Moderator:


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat