Handling von FBC-Tunern

Antworten
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Handling von FBC-Tunern

Beitrag von Janus »

Ich habe mal durch die Neutrino-Sourcen zum Frontend-Managment gestöbert.
Weder im NI-Neutrino noch im Neutrino-MP bei DDT wird auf Besonderheiten der FBC-Tuner im Code eingegangen.

Bei den DVB-C-Tunern mag das ja wegen der eindimensionalen Zielansprache auf die TS-Streams vielleicht noch ohne Relevanz sein, bei den DVB-S Tunern sollten da aber ein paar Randbedingunen in den Code integriert sein.

* Zuallererst kann bei FBC-Tunern nur eins der vier möglichen Bänder einer einzelnen Zuleitung zugeordnet werden.

* Bei den z.B. in der Duo4K verbauten Twin-FBC - Version mit zwei Zuleitungen können parallel nicht mehr als zwei der vier Bänder genutzt werden.

* So wie das da aussieht, werden zwei der acht vorhandenen Tuner auf diese Zuleitungen entsprechend konfiguriert ( dort A und B ). Die verbleibenden 6 weiteren Tuner können nach Bedarf wohl dynamisch jeweils einer von beiden Zuleitungen zugewiesen werden. Bei nur einer Zuleitung zum Tuner-Modul ist natürlich nur einer konfiguriert und darauf 7 zuweisbar.

* Die Ermittlung der Möglichkeit einer solchen dynamischen Zuweisung ist dabei erheblich komplexer als bei einem 'normalen' Sat-Tuner, der ja nur einen einzelnen Transportstream mehrfach parallel nutzen kann.

* Die "Schaltung" der dann zugewiesenen (Sub-) Tuner beschränkt sich auf das bereits 'aktive' Band und benötigt zum Tunen nur noch die Zuweisung von den abweichenden TS-Parametern (frq, sr, fec usw.) für Demux und die weitere Verarbeitung des Streams.
DiSEqc-Pfad, Band und Polarisation sind ja schon durch den "Leithammel"-Tuner festgelegt.

* Zum Schluss muss auch immer wieder eine Kontrolle stattfinden, ob das "Band" noch verwendet wird oder die dann freien Tuner mit völlig neuen "Zielen" über eine oder beide Zuleitungen ausgestattet werden können.

Von Alledem kein einziges Byte im vorhandnen Neutrino-Code.
Ich habe mal kurz in die Frontend-Header von OpenATV geschaut,
Da gibt es wenigstens ein Flag m_fbc in der Tunerkonfiguration und ein paar Sonderregelungen für bestimmte Tuner-Fabrikate. Ich denke, das wrd im Tunermanagment von Enigma auch ausgewertet.

In Neutrino ist das im Moment wohl eher Glücksache, ob eine Aufnahme oder Umschaltung bei Nutzung des FBC-Sattuners tatsächlich ausgeführt werden kann.
Es gibt demnach viel zu tun...
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Janus, wenn Du irgendwelche Logs brauchst, sag bescheid. Bei DVB-C kann man derzeit nur eine Aufnahme machen und einen anderen Sender schauen, aber keine zwei Aufnahmen (egal ob vom gleichen Sender oder von unterschiedlichen).
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Im Moment "denke" ich nur, aber wenn ich meine Duo4K wiederhabe, habe ich ja selbst FBC-Tuner für S2X und C.

Aber wenn dann mal was zu testen ist, kann ich mich ja vielleicht melden...
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Ist das dann der gleiche DVB-C FBC Tuner wie bei der UNO4KSE ?
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Kann ich im Moment nicht sagen, meine Box ist gerade in der "Grundausbildung".
Aber vielleicht hilft Tante Gurgel...

Worüber ich ansonsten da gerade nach"denke":

EIn solches FBC-Frontend sollte eine Property für "FBC" (z.B. bool m_isFBC;) besitzen.
Oder über eine eigene, fbc-bezogene Klassendefinition deklariert werden.

Dann muss ein zusätzlicher Status "linked" eingeführt werden, der bei Statuswechsel die Liste der benutzten/freien Subtuner im Frontendmanager beim ensprechenden "Mastertuner" - der mit der Zuleitung - aktualisiert.
Bei DVB-C dürfte das eher kein Problem sein, solange man fest vorgibt, dass es beim User immer nur einen einzigen Provider gibt/geben darf.

Für die 'Verwaltung' müsste es vielleicht noch eine Property "m_priority" geben, um die Zuweisung von parallel arbeitenden Subtunern über Nutzungszeit und Verwendungsart anwenderoptimiert zu automatisieren.

Für die "Intelligenz" des Frontendmanagers wäre auch eine 'Rückwärtssuche' nach dem Motto: Ich brauche eine Aufnahme aus "dem Ersten" um 21:00 bis 22.15. Hast Du dafür einen geeigneten Tuner?
(SD, HD, UHD ist egal, könnte man natürlich auch noch eingrenzen)
Auf meiner HD51 sollten dann der Multischalter, die Motorschüssel, der Kabelnetzbetreiber und der T2 Sendemast abgefragt werden, ob "Das Erste" verfügbar ist.
Und dann der Tuner mit freier Zeit von 21: bis 22:15 gewählt werden, der von allen Möglichkeiten die beste Auflösung oder den geringsten Speicherbedarf ermöglicht.

Das Alles verkompliziert natürlich den bereits vorhandenen Code, wenn man solch weitergehenden Features da reinfrickeln muss.
Deshalb hatte ich insgesamt ja eher an einen klassenbasierten Ansatz gedacht. Da gibt es so schnuckelige Sachen wie Wiederverwendung, Vererbung, Separation of Concern uVm.
Und nicht zu vergessen, die dadurch verbesserte Möglichkeit der Anpassung des "Codes" an reale UseCases und tatsächlich vorhandene Hardware. (z.B. Factory Pattern, Inversion of Control)
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Ich "denke" es ist wichtiger die FBC Tuner überhaupt erstmal nutzbar zu machen (das man zwei Aufnahmen machen kann).
Das andere wäre, "ist auch ganz nett".
Derzeit muss ich oft von Web-TV Sendern aufnehmen, habe dort aber das Problem das dort die EPG Info über den Autotimer nicht übernommen wird und somit die Sendungen keinen Namen haben.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Jou, auch ein Grund für meine Überlegungen.

Ich habe eine Interface-Klasse IConnector
in der die mindestens notwendigen Dinge 'virtuell' festgelegt werden.
Das ist eine Art globale Schnittstellen-Definition für Programmteile.

Connector deshalb, weil die dafür übliche Bezeichnung "Adapter" (genau wie "Frontend") schon bei den Devices im DVB-Bereich verwendet wird. Ich möchte Mehrfachbedeutungen gerne vermeiden.

Von dieser 'nichtsnutzigen' Interface-Klasse werden entsprechende Basisklassen abgeleitet:

DVB_Connector : IConnector
NET_Connector : IConnector
File_Connector : IConnector
HDMI_Connector : IConnector
BT_Connector : IConnector
...

In denen die Verbindung zwischen der Hardware und der dafür zuständigen Software entsprechend codiert wird.

Die wird dann je nach Anwendungszweck weiter 'vererbt' und um die speziellen Belange erweitert.

DVB_S_Connector : DVB_Connector
DVB_C_Connector: DVB_Connector
DVB_T_Connector: DVB_Connector
...
NET_LAN_Connector : NET_Connector
NET_WLAN_Connector : NET_Connector

...
So kann man jeden Connector aufs Feinste (nur) an sein Aufgabe anpassen.
Das Interessante daran ist, dass eine Instanz der jeweilgen Klasse dann selbst weiß, wie sie ihre Aufgabe(n) zu erledigen hat.
Dein Vorschag daher: Der NET_Connector sollte also eine eigene Methode zur Abholung der EPG-Daten besitzen. Die sich wohl von den EPG-Methoden der DVB-Klassen unterscheidet.
DVBConnector.HoleEPG() sollte dann genauso "seinen" EPG holen, wie
NETConnector.HoleEPG() den seinen. Im Code des Managers steht dann aber nur:
zuständigerConnector.HoleEPG()

Und das Schöne mit der Interface-Klasse ist die Möglichkeit, dass der Frontendmanager sich seine Connectoren - und nur die Notwendigen - selber 'einbinden' kann.
Was auch das schonmal vermisste Einfügen einer per Hotplug angebundenen Hardware per Factory-Pattern während der Laufzeit ermöglicht.

Vereinfacht:
Hotplug liefert ConnectorType="DVB_C"
KabelTuner[9] = Create( IConnector, HotPlug.ConnectorType + "_Connector" );


p.s.
Du kannst ja mal über einen HDMI_CEC_Connector nachdenken... :sunglasses:
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Hört sich gut an, auch wenn ich davon fast nichts verstehe.
CEC ist zwar gefixt worden, funktioniert bei mir aber leider noch nicht so wie es sollte. Ich fürchte das wird sich auch nicht mehr ändern.
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Ich habe eine Idee, warum der Scan mit den FBC-Tunern der Duo4K bei den neueren Treiberversionen nicht funktionieren könnte.

Da in frontend.cpp keinerlei "Vorkehrungen" für FBC-Tuner getroffen oder gar ausgewertet werden, die "Schaltungen" der Transportstreams damit aber in Teilen anders ablaufen, könnte da ein Grund für die "Unterschlagung" einzelner Transponder liegen.

Fällt unter Enigma vielleicht nicht so ins Gewicht weil Reihenfolge und Timing dort anders geregelt sind.

Da die FBC-Tuner ja auf "Band"-Ebene arbeiten, sind vorhandene DiSEqC und LNB-Konfigurationsabläufe nicht wirklich optimiert.

Ich vermute, dass bei einem Transponderwechsel die komplette DiSEqC-Litanei über PortGroup-Kommandos abgesetzt werden.
Für den ersten Zugriff auf ein Band ist das in Ordnung, weil ja auch Options- und Positionssteuerung erforderlich sein könnte. Sobald aber darüber auch ein Band festgelegt ist, ist das bei einem nachfolgenden Transponderwechsel nicht komplett notwendig, sondern kann bei einem FBC-Tuner reduziert werden auf das reine Umstellen der LNB-Parameter (frq, sr, fec usw) oder zusätzlich bei einem dadurch erforderlichen Wechsel des Bands die Umstellung von Basisfrequenz und Polarisation.

Aus diesem Grund wäre es bei solchen Änderungen sinnvoller, diese beiden Aufgabe zu trennen, solange man nicht auch die Position ändert.

Die Bandumschaltung kann man selektiv ja ebenfalls mit PortGroup-Kommandos (E0 11 38 3x) setzen, da das aber nur das LNB betrifft, sollte man nur LNB-AdressBytes (0x11 [Standard LNB] oder 0x12 [LoopThrough LNB] verwenden. Danach letztlich (oder ausschließlich) mit einem passendes Delay dazwischen das Setzen der Transportstream-Parameter (setFrontend).

Bei einem Scan über ständig wechselnde Bänder (meist von H nach V und zurück) könnte ich mir schon vorstellen, dass das für den Tuner ziemlich stressig sein dürfte, zumal wenn die "Anforderungen" Schlag auf Schlag folgen und dann noch mit nicht notwendigem Überhang und nicht angepassten oder garnicht vorhandenen Delays.

Leider ist meine Box gerade nicht greifbar, sonst würde ich das mal selber antesten.
Zuerst würde ich über 'optimierte' Scandateien mal versuchen, diesen Bandwechsel zu vermeiden.
Dafür habe ich mal meine Astra-Transponderliste in die vier Bänder 'zerlegt' und die mit unterschiedlichen Namen und "Positionen" versehen.
Dazu habe ich per myservices.xml 4 Services (einer je Band) vorgegeben und in einem User-Bouquet "Band-Umschalter" zusammengefasst. Beim Neustart oder nach Löschung/Neuladen werden die daher zur Verfügung gestellt.

Falls Jemand das mit der Duo4K und den neueren Treibern (BPanthers Experimental) testen kann:
Im Zip ist auch mein Komplettscan (services.xml) über die HD51 zum Vergleich vorhanden.
Die satellites.xml besteht nur aus den 4 Astra-Teilpositionen (192 LH,193 HH,194 HV,195 LV)
FBC_test_config.zip
(18.47 KiB) 198-mal heruntergeladen
Für den Test würde ich meine satellites.xml umbenennen und mein zapit temporär ersetzen.

mv zapit zapit.org
ln -sf test zapit

und danach

rm zapit
mv zapit.org zapit

Wenn sich da 'Verbesserungen' gegenüber der bisherigen Komplettsuche über die übliche satellites.xml ergeben, könnte man gezielt im Code mit den oben angedeuteten Maßnahmen für ein FBC_Frontend-Handling weitermachen...


p.s.
Vergessen:
In der Tunereinstellung alle "SatPositionen" diseqc-mäßig auf das gleiche LNB stellen.
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Handling von FBC-Tunern

Beitrag von BPanther »

Was ich dabei nicht verstehe ist, was das mit der Senderliste zu tun hat? Auch die von Dir hat die gleichen Auswirkungen - kein Empfang auf bestimmten Transpondern - hat nichts mit den Bändern dabei zu tun, war auch nie das Problem. Daher gleiches Ergebnis wie mit der "normalen" Senderliste.
Bild
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Zielrichtung der Idee war auch nicht irgendeine Senderliste, sondern (ungeeignete) Schaltkommandos und (dadurch zu knappes) TIming der Kommandofolgen.

Die Senderliste sollte nur Basis einer Testumgebung sein...
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Handling von FBC-Tunern

Beitrag von BPanther »

Du schreibst allgemein von einem FBC Problem, das besteht aber nicht wirklich, denn Solo4K und Zero4K nutzen mit FBC Tunern die aktuellen Module problemlos. Es liegt daher irgendwas beim BCM-Treiber, da wurde was verändert. Natürlich muß der Ansatz nicht falsch sein, von daher muß das dann auch bei den anderen Boxen mit getestet werden, falls die dann Änderungen vielleicht übel nehmen. Unter E2 wurde, soweit mir bekannt, nichts verändert. Als die neuen Module kamen lief das normal wie zuvor. Aber hatte ich glaube auch schon oft geschrieben...
Bild
Benutzeravatar
Charles Darwin
NI - VIP
Beiträge: 73
Registriert: Di 12. Apr 2016, 12:47
Wohnort: Panama City

Re: Handling von FBC-Tunern

Beitrag von Charles Darwin »

Gorcon hat geschrieben: Fr 12. Jun 2020, 17:52 Hört sich gut an, auch wenn ich davon fast nichts verstehe.
CEC ist zwar gefixt worden, funktioniert bei mir aber leider noch nicht so wie es sollte. Ich fürchte das wird sich auch nicht mehr ändern.
CEC funktioniert im aktuellen BPanther-Vu+Uno4KSE Experimentalimage...mit meinem Sony-TV und meiner Pioneer-Audio...hab über Multiboot den direkten Vergleich mit dem aktuellen NI-Nightly-Image...damit funktioniert es nicht.
1xVU+Uno4k,1xTrinity-v2-kabel, 1xTank, 1xTrinity, 2xZEE, 1xNeo2, 2xHD1
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Hi Charles!

Ich glaube, Du bist gerade im falschen Thread.

@BPanther
Gerade weil es nur bei den 'neuen' Treibern für die Duo4K und dem darin verbauten S2X-Tuner nicht geht, suche ich ja nach einer Lösung.
Wenn ich in Enigma (OpenATV 6.3) sehe, dass die Subtuner-Zuweisung automatisch gehandhabt wird und in Neutrino offensichtlich nicht (siehe die Probleme mit mehrfachen Aufnahmen) ist mir halt die Idee gekommen.
Mal ins Unreine gedacht:
Bei dem Upgrade der Treiber (wegen der mit den altern Treibern nicht funktionierenden Multistream Transpondern) ist vielleicht am Timing oder Eigenintelligenz des Treibers bezüglich der Subtuner-Zuweisung etwas eingebaut worden, was mit dem schlichten Frontendmanagment von auch aktuellem Neutrino nicht mehr zu wuppen ist.

Mal angenommen, der Neutrino-Scan hält sich nach einem erfolgreichen Transponder-Tuning im Hintergrund sehr lange mit Auswertungen ellenlanger SI-Tabellen oder NIT-Auswertungen auf, während die Scan-Schleife schon auf den nächsten Transportstream umschaltet.
Als kleverer Frontendmanger mit Zugriff auf zusätzliche, ungenutzte Subtuner und sogar noch Unterstüzung durch den neuen Treiber, würde ich auf einen anderen Subtuner umschalten und den weiteren Scan erstmal dort durchführen.
Offensichtlich besteht ja eine solche Möglichkeit, was die Abfrage nach "Anderer Tuner für Aufnahmen auf gleichem Transponder" ja andeutet.

Würde vielleicht sogar die demux-Geschichte erklären.
Unter Enigma wird diese für Aufnahmen und Streaming sinnvolle Option bei einem Scan sicher als 'kontraproduktiv' verhindert. (oder bewusst genutzt um den Enigma-Scan endlich mal schnell und effektiv zu machen)
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Handling von FBC-Tunern

Beitrag von BPanther »

Nunja, ganz so stimmt die Aussage nicht. Man kann durchaus mehrere Tuner ansprechen, das funktioniert dann aber letztlich nur als Live Ausgabe vom Bild her (unabhängig von den Modulversionen). Starte einfach mehrere Aufnahmen und Du wirst sehen, daß da dann z.B. Tuner G bei rauskommt beim Live-TV, auch wenn letztlich bei den 6 Aufnahmen nur die erste OK sein wird. Neutrino scheint also zumindest die Tuner zu reservieren, aber die Zuweisung intern (wahrscheinlich Demux etc.) passt da nicht richtig. Und ob man nun "Auto" hat oder manuell die Tuner einstellt wäre mir persönlich egal. Letztlich muß man eh oft manuell eingreifen und Anpassungen vornehmen, gerade wenn man Diseqc oder Unicable verwendet. Das war aber auch ein Grund, warum ich auch bei Neutrino im DDT die Tunerbuchstaben (A bis X) eingeführt habe, unterscheidet sich am Ende besser und man kann auch ggf. mit E2 vergleichen, was ein echter Tuneranschluß ist und was der FBC. Keine Ahnung, wie E2 das bestimmt, wäre aber noch interessant das einzubauen bzw. diese zu markieren.
Die Option "Anderer Tuner für Aufnahmen auf gleichem Transponder" ist auch bekanntlich wichtig und sollte immer aktiv sein bei VU+ mit FBC, denn gerade bei den aktuellen Modulen klappts dann mit den Aufnahmen (jedoch dennoch nicht überlappend auf eigenem TP) auch ganz gut - wie schon oft geschrieben.

Wobei alles in allem dennoch eines irritiert: Es betrifft ja nur den BCM-SAT-Tuner. Der Kabel-Tuner kann FBC haben, da klappts dennoch mit den aktuellen Modulversionen. Es ist also irgendwas am BCM-Treiber verändert worden. Demnach erstmal kein generelles FBC Problem würde ich daher behaupten.

Im Prinzip wird der entsprechende Filter gesetzt, dann der Demuxer und dann versucht zu lesen. Das letzte funktioniert dann nicht mehr mit den aktuellen Modulen...
Bild
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

[OT Anfang]
Charles Darwin hat geschrieben: Mi 17. Jun 2020, 09:46
CEC funktioniert im aktuellen BPanther-Vu+Uno4KSE Experimentalimage...mit meinem Sony-TV und meiner Pioneer-Audio...hab über Multiboot den direkten Vergleich mit dem aktuellen NI-Nightly-Image...damit funktioniert es nicht.
Danke Muss ich mal testen. Aber Lautstärke soll ja eh nur über externe Geräte nutzbar sein, das kann ich dann nicht nutzen da mein AV kein Audio per HDMI unterstützt.
Mir gehts nur darum das der TV sich ein und auf HDMI umschaltet.
[/OT Ende]
Benutzeravatar
Janus
NI - VIP
Beiträge: 1138
Registriert: Di 12. Apr 2016, 19:41
Box: HD1, Zee, Neo, Tank, HD51, Duo4K

Re: Handling von FBC-Tunern

Beitrag von Janus »

Ich habe mir mal die Sourcen von OpenATV angesehen.
Dort gibt es für das Handling der FBC-Tuner eine entsprechende Erweiterung inkl. FBC-Frontend-Manager. (fbc.h und fbc.cpp).
Im dortigen 'normalen' Frontend-Handling wird im Constructor eigentlich nur ein Flag (m_fbc) gesetzt, falls das Frontend zu einem FBC-Tuner gehört.

Ich kann mir - ehrlich gsagt - nicht vorstellen, dass Neutrino ohne solche Anpassungen eine fehlerfreie Nutzung der FBC-Möglichkeiten schafft.
Schon die Freigabe des Zugriffs bei laufender Aufnahme ist (noch) begrenzt auf den dafür benutzen Transponder statt im Falle von FBC auf das komplette Band. Im Falle des DVB-C Tuners sollte es garkeinen eingeschränkten Zugriff geben.
Von dynamischer Zuweisung der insgesamt 8 Tuner auf die zwei Zuleitungen bei Sat ist unter Neutrino auch Nichts zu erkennen.

Müsste man vielleicht mal querlesen und nachbauen...
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Janus hat geschrieben: Mi 5. Aug 2020, 13:06
Ich kann mir - ehrlich gsagt - nicht vorstellen, dass Neutrino ohne solche Anpassungen eine fehlerfreie Nutzung der FBC-Möglichkeiten schafft.
Sieht man ja das es nicht funktioniert.
Man kann zwar etwas Aufnehmen und etwas anderes schauen, aber zwei Aufnahmen funktionieren nicht, egal ob vom gleichen Sender, vom gleichen TP oder von unterschiedlichen.
Es wird dann nur eine (fast) lehre TS erzeugt. Im Movieplayer wird der Film dann als aufgenommen angezeigt lässt sich aber nicht abspielen.
TS funktioniert auch nur ab und zu. Meist bricht die Aufnahme in dem Moment ab wo man wieder Start drückt. (Die Aufnahme wird aber weiter signalisiert)
Benutzeravatar
BPanther
NI - VIP
Beiträge: 745
Registriert: So 29. Sep 2019, 18:37
Kontaktdaten:

Re: Handling von FBC-Tunern

Beitrag von BPanther »

Gorcon hat geschrieben: Mi 5. Aug 2020, 14:59Sieht man ja das es nicht funktioniert.
Man kann zwar etwas Aufnehmen und etwas anderes schauen, aber zwei Aufnahmen funktionieren nicht, egal ob vom gleichen Sender, vom gleichen TP oder von unterschiedlichen.
Es wird dann nur eine (fast) lehre TS erzeugt. Im Movieplayer wird der Film dann als aufgenommen angezeigt lässt sich aber nicht abspielen.
Das hat nichts mit FBC zu tun sondern immernoch mit dem BCM-Treiber, bei der aktuellen BCM-Treiber-Version und bei den anderen Boxen ohne BCM-Tuner geht das.
Bild
Benutzeravatar
Gorcon
NI - VIP
Beiträge: 2724
Registriert: Mi 13. Apr 2016, 10:55
Box: E2HD, VU+ Uno4kSE, VU+ Ultimate4k
Has thanked: 8 times
Been thanked: 2 times

Re: Handling von FBC-Tunern

Beitrag von Gorcon »

Sind die Treiber für Enigma denn so grundverschieden aufgebaut?
Antworten

Zurück zu „Entwicklung“