Aber das wären dann im Ergebnis doch auch wieder 2 voneinander unabhängige juristische Vorgänge, oder nicht? @agarnele
Das Eine ist ja was Dir persönlich vorgeworfen wird, dass Andere ein ggf. daraus resultierender Anspruch Deinerseits gegenüber dritten die Dich getäuscht haben können.
Ich bin ja inhaltlich bei Euch, und auch bei Dir, aber so funktioniert's halt leider nicht, unser System, fürchte ich...
Als Privatkäufer kannst du afaik da sehr wohl rangenommen werden. Du kannst nämlich bei uns sehr wohl Eigentum erwerben, auch wenn der Verkäufer nicht rechtmäßiger Veräußerer war. Nämlich dann, wenn du das Eigentum in gutem Glauben erworben hast.
Dem entgegen steht allerdings ganz klar, dass hier scheinbar Leute Software für einen Bruchteil des marktüblichen Preises (unabhängig davon ob man den nun für angemessen hält oder nicht) erworben haben und genau da hätten stutzig werden müssen.
In der Folge davon lässt sich daraus durchaus konstruieren, dass eben diese Leute eigentlich wissentlich eine illegale Version gekauft und benutzt haben.
Und: Unwissenheit schützt ja bekanntlich vor Strafe nicht.
Und es ist eben auch nicht so, das man dann deshalb sagen könnte: dann Zahl halt die Differenz und gut is - denn das wäre ja dann keine Strafe... Außerdem hat man zu diesem Zeitpunkt die illegale Version in der Regel auch schon eine gehörige Zeit lang genutzt...
... Also macht es euch bitte nicht zu einfach.
Ich war jetzt einfach Mal davon ausgegangen, wir reden von 576i... Aber ja Art des Eingangsmaterials (genau) ist natürlich auch wichtig...
Ich hinterfrage zunächst Mal etwas um ein klareres Bild der Problemstellung zu bekommen:
1. Du sprichst nur von Aufnahmen. Im Normalfall nimmt TVH aber den originalen Stream auf - es müsste also LiveTV genau so betreffen...
2. An was genau hängt denn den FireTV? 4k Fernseher?
3. Was für ein iPhone/iPad Modell ist es genau?
Wenn es zeitlich mal wieder besser aussieht werde ich mich nochmal damit auseinandersetzen so etwas für das deinterlacing auf dem Nano zu verwenden - wenn das klappt (keine Ahnung ob die Performance dafür reicht) dürfte es schwer zu toppen sein und wäre dann wohl im Ergbnis auch 576p@50 und nicht 576p@25, es würden also weniger Informationen "verloren" gehen...
@Canis Nova der Gist dazu findet sich: hier (funktioniert im Moment nur mit MagentaTV)
In den einzelnen Dateien steht jeweils in der ersten Zeile wo die Datei hingelegt werden muss. Die Zeile sollte dann entfernt werden.
Die binary für den rtsp-simple-server kann hier heruntergeladen werden und muss in "/usr/local/bin/rtsp-simple-server" abgelegt werden (chmod +x nicht vergessen). Die Konfiguration rtsp-simple-server.yml entspricht bis auf die letzten 3 Zeilen dem Default (als Beispiel habe ich Pro7 via MagentaTV hinterlegt). Da ich keine Möglichkeit gefunden habe, dass GStreamer selber ermittelt ob es ein Stream mit AC3 oder MP2 Audio ist hab ich das als Flag ergänzt ("-a", default ist "mp2", ansonsten "ac3" eintragen), welcher manuell (aber immerhin ja einmalig) hinterlegt werden muss.
Der rtsp-simple-server.service muss natürlich noch via systemd aktiviert und gestartet werden.
stream.start (startet die GStreamer Pipeline und published dann auf den rtsp-simple-server) wird onDemand vom rtsp-simple-server aufgerufen und startet von sich aus auch stream.dump - was lediglich den originalstream abruft und die Pakete so aufbereitet, dass GStreamer damit arbeiten kann. Letzteres könnte man z.B. für andere Quellen (als MagentaTV) auch via FFMPEG machen, dann sind die Umschaltzeiten aber nochmal wieder ein ganzes Stück länger.
Edit: Da hab ich doch glatt die Installation der Entrans-Filter vergessen... Hier ein Beispiel wie man das installiert bekommt so das es funktioniert.
Ist das alles eingerichtet und gestartet, dann kann man in TVHeadend ein neues Network anlegen und dazu dann einen Mux mit folgender URL einrichten (zunächst die originale Stream-URL eintragen, damit der Scan durchläuft):
rtp://232.0.10.120:10000?sources=87.141.215.251
Wenn das erledigt ist, kann man die folgende Pipeline hinterlegen (muss leider durch FFMPEG, da TVHeadend RTSP nur sehr rudimentär unterstützt):
pipe:///usr/bin/ffmpeg -loglevel fatal -hide_banner -nostdin -nostats -i rtsp://xxx.xxx.xxx.xxx:8554/pro7 -c:v copy -c:a copy -metadata service_name=ProSieben -metadata service_provider=Nano -mpegts_service_type advanced_codec_digital_sdtv -f mpegts pipe:1
Das war jetzt mal die extreme Kurzfassung (bin im Moment leider ziemlich überlastet) - bei Fragen: Fragen 
@TylerDurden_BS also vermutlich doch kein skin Problem?
@TylerDurden_BS ist also scheinbar dich nicht nur ein Problem bei embuary + Profilen?
@Canis Nova Soll ich mal einen GitHub Gist fertig machen mit den ganzen Scripten für den Nano? 
Das Setup ist, wenn man die Fallstricke erstmal überwunden hat (was ja dann schon der Fall wäre) ziemlich simpel. Ich hab's neulich in ca. ner halben Stunde wieder aufgesetzt bekommen auf ner frischen Installation vom Nano, damit der nicht mehr von SD sondern USB SSD bootet/läuft...
Generell gesprochen geht es bei mir noch, hakt aber häufig. Zurückspringen springt idR nicht zurück, sondern ziemlich weit nach vorne. Nach vorne springen hingegen funktioniert meistens, hat aber manchmal eine Verzögerung von Bild und Ton im Anschluss zur Folge.
@goscho ich meine die Option gab es auch schon vorher
@Scheibes du kannst auf der shield eine Netzwerkfreigabe aktivieren, dann kannst du von deinem Desktop aus direkt darauf zugreifen
@Scheibes du musst die Einstellungen rüberkopieren, da die maven-Version ein anderes Verzeichnis benutz, aber sollte kein Problem sein...
@bumblebee das mit dem Fokus-Problem ist mir auch schon aufgefallen. Ich hab nur keine Ahnung wie sich das evtl beheben lässt 
@darkicenight benutzt du zufällig auch Profile?
Leider kann ich im Emby-Next Gen Addon im Embuary Skin auch nicht auf die Button Configuartion navigieren was mit den anderen untengenannten Skins funfunktioniert
Das geht bei mir auch nicht komischerweise. Probier Mal OK gedrückt halten auf dem addon und dann über das Kontextmenü
@TylerDurden_BS Ich stell nochmal direkt ein paar Rückfragen, so lange Deine Erinnerung noch frisch ist:
1. Bevor Du das Embuary-ZIP installiert hast hattest Du auf beiden Profilen Amber als Skin in Verwendung und das lief sauber?
2. Das reine umswitchen von Embuary zu Amber im Elternprofil hat nicht gereicht?
3. Hast Du Embuary dann im Elternprofil über die GUI deinstalliert oder über das dateisystem direkt und inkl. aller "Abhängigkeiten"?
@TylerDurden_BS Nur um's nochmal klarzustellen: Mit "programmieren" im Sinne von irgendeiner tatsächlichen Programmiersprache, sei es nun kompiliert oder interpretiert hat ein Skin eigentlich nichts zu tun. Das gesamte Repo beinhaltet nicht eine einzige Zeile Programmcode (korrigiert mich, wenn ich was übersehen haben sollte), sondern lediglich Definitionen in Form von XML (o.ä.) und Assets in Form von Skin-Grafiken, Fonts, UI-Sounds etc. Klar, im XML stehen Dinge drin die von Kodi interpretiert werden, aber das ist dann eben Sache von Kodi und nicht des Skins.
Daher auch die starke Vermutung die Ursache an anderer Stelle suchen zu müssen bzw. wenn, dann in den requires des Skins. Letzteres hätte aber dann ergeben müssen, dass die von Dir genannten, nicht funktionierenden Skins dort eine eindeutige Gemeinsamkeit hätten haben müssen, was aber nicht der Fall ist.
Ich persönlich würde die Ursache, wenn die requires als Ursache ausscheiden (wovon ich ausgehen würde) im Moment irgendwo in emby-next-gen vermuten..
@TylerDurden_BS Nur nochmal zur Sicherheit: Bei Dir verbindet emby-next-gen-5.1.17 eigentlich wirklich nur unter Estuary zuverlässig, bei allen anderen genannten Skins geht es nicht, korrekt?
Ich hab gerade mal ein paar der anderen Skins durchgechecked ob es da Gemeinsamkeiten in den requires in der jeweiligen addon.xml gibt: Gibt es aber nicht wirklich... Fällt also als Idee im Grunde aus
