Jump to content

Scan-Problem mit TransEdit 3.8.2


Recommended Posts

Ich habe ein komisches Problem mit der neuesten TransEdit-Version 3.8.2. Bis einschließlich 3.8.1 tritt es nicht auf, auch jetzt wenn ich hin- und herwechsle passiert es nur mit 3.8.2. Und zwar wenn ich einen "Scan All" auf Astra 19.2 mache bleibt TransEdit bei etlichen Transpondern sehr lange hängen, dann geht die Anzeige "PMT" auf rot und nach ein paar Sekunden Pause geht es weiter (siehe Bild im Anhang). Das passiert willkürlich so ca. bei jedem 10. Transponder und nicht jedesmal bei den gleichen. Natürlich werden am Ende jede Menge (funktionierender) Kanäle falsch als "Dead Channels" angezeigt. Scanne ich die Transponder einzeln mit "Scan selected" geht jeder ohne den Fehler, nur beim automatischen Durchlauf hängt er, aber eben nur mit der neuesten Version, nicht mit irgendwelchen früheren.

 

Was ich probiert habe:

- Recording-Service natürlich vorher gestoppt damit der nicht dazwischenfunkt

- in C:\ProgramData\CMUV\DVBViewer die "transedit.ini" umbenannt um alle Einstellungen zurückzusetzen

- Settings - Hardware - Detect Devices erneut ausgeführt

- Settings - Hardware - Use standard interface testweise aktiviert, brachte auch nichts

 

Wie geschrieben, bei 3.8.1 geht es mit der identischen Konfiguration jedesmal und einzeln gehen die Transponder ja auch. Ich habe das gestern auch hier im englischen Forenteil erwähnt und dort wurde mir von Derrick geraten das "Detect Devices" zu wiederholen. Habe ich gemacht wobei der Unterschied beim "Vendor" wohl nur den DVBViewer selbst betraf der gar nicht direkt auf die Karte zugreift sondern nur über den Recordingservice. Jedenfalls hat das Neuerkennen der Hardware sowohl in RS, DVBViewer und TransEdit nichts geändert. Support.zip hab ich aktuell neu erstellt und angehängt.

 

Gibt es noch was das ich probieren könnte?

post-88727-0-91110800-1325750303_thumb.gif

Link to comment
Gibt es noch was das ich probieren könnte?

Ja. Die Testversion 3.8.2.4 aus dem Mitgliederbereich -> Beta-Sektion :)

 

Deine ausführliche Beschreibung lässt mich ahnen, was passiert. Verwendest du die TT 3200 mit CI?

 

Wahrscheinlich liegt es daran, dass die Karte nach dem Tunen noch erhebliche Daten-Restbestände des vorherigen Transponders aus Puffern liefert. Dieser Fall wird in der 3.8.2 zwar behandelt, aber nicht mehr so gründlich wie in der 3.8.1. Aufgrund eigener Tests war ich zur Ansicht gelangt, dass nach dem Tunen maximal eine PAT des vorherigen Transponders eintrifft (die wird erkannt und verworfen). Wie sich inzwischen gezeigt hat, können es jedoch mehr sein - in einem Fall (Digital Devices mit zwei CI Filtern) waren es 4.

 

Wenn der Scanner eine PAT vom vorherigen Transponder als Ausgangspunkt verwendet, kann er natürlich mit den PMTs vom richtigen Transponder nichts anfangen, denn die passen nicht dazu ;)

Link to comment

Bingo! Das war es offensichtlich, die 3.8.2.4 Testversion läuft wieder korrekt durch. Alle Transponder/Kanäle gefunden, keine "Dead Channels" mehr. Danke für die superschnelle Lösung :) Ich scanne halt lieber regelmäßig mit TransEdit als mit dem DVBViewer weil man so detailliert mitbekommt was sich getan hat.

Link to comment

Bei einigen Transpondern kannst du wahrscheinlich beobachten, dass die Farbfelder plötzlich rot werden, aber der Scanner nicht zum nächsten Transponder springt, sondern auf dem selben noch mal neu ansetzt. Das liegt daran, dass er während des Empfangs von PMTs und SDT weiterhin die PAT im Auge behält und auf eine unerwartete Änderung reagiert (ohne Retune).

 

Die Sache wäre kein Problem, wenn es nicht Feeds und Unicable zu berücksichtigen gäbe. Bei Feeds kann es tatsächlich passieren, dass zwei aufeinanderfolgende Transponder die gleiche PAT liefern, und das ist dann korrekt. Bei Unicable wiederum ist sowas ein Anzeichen für eine Kollision (Tunen hat im Unicable-Router nicht stattgefunden, weil zwei Geräte gleichzeitig versucht haben, ein DiSEqC-Kommando zu senden). Die Fälle muss der Scanner nach Möglichkeit unterscheiden.

 

Noch mal: Ist bei dir ein CI mit im Spiel?

Link to comment
Noch mal: Ist bei dir ein CI mit im Spiel?

CI ist bei TechnoTrend und Digital Devices komplett anders implementiert. Bei DD gehen die Daten immer erst durch diverse Treiber bevor sie zurück an das CI (bzw. die CI's bei Kaskadierung) und schlussendlich die Applikation geschickt werden, damit sie für MTD gegenenfalls aufbereitet (gefiltert und neu gemuxt) werden können. Üblicherweise (wie bei TechnoTrend) verlässt der Stream das DVB-Gerät vor dem CI nicht (hängt direkt am Demodulator oder der Bridge). Nichtsdestotrotz dürfte es natürlich auch in den CAM's Restbestände geben. Bei DD schaukelt sich das durch mehrfache Pufferung in diversen Treibern weiter hoch.

 

Soweit ich weiß, puffert der TT-Treiber generell sehr viel. Da war doch mal das Problem, wenn 2 Kanäle dieselbe Video-PID hatten!? Das hat die Wiedergabe dann komplett lahmgelegt. War im Jahre Schnee, als ich noch mit TechnoTrend hantiert habe. Die Diskussion müsste aber noch irgendwo im Forum zu finden sein.

Link to comment

Was im ci-modul an daten gepuffert wird, dürfte hier zu vernachlässigen sein. Ausserdem kann man das modul ja ziehen, um zu sehen, ob es unterschiede beim scanning in transedit gibt.

Link to comment

Stimmt eigentlich. Bei der S2-3200 muss die Applikation doch sowieso erst via API den Port auf dem SAA Chip umbiegen, damit die Daten über das CI gehen. Das dürfte TransEdit nicht machen.

Link to comment
Da war doch mal das Problem, wenn 2 Kanäle dieselbe Video-PID hatten!?

Das Erste und Eins Extra auf Astra. Das Problem besteht im DVBViewer auch weiterhin. Eine Vermeidung würde die Umschaltzeiten deutlich erhöhen. Inzwischen ist allerdings der DVBViewer Filter in der Lage, die Zeitstempel-Diskontinuität zwischen den vorherigen und neuen Daten zu erkennen und zu behandeln. Deshalb gehe ich davon aus, dass es nicht mehr die Wiedergabe zum Erliegen bringt. Es müsste mal jemand mit einem entsprechend anfälligen Gerät testen. Falls es doch Bruch gibt, sollte das Einschalten der Vorab-Formaterkennung im DVBViewer helfen.

 

Bei der TT 3600 USB ist mir das von HaraldL geschilderte Problem übrigens nicht begegnet. Ich hatte natürlich diesen Aspekt mit TransEdit 3.8.2 und allen hier verfügbaren Geräten getestet.

Link to comment

Das ganze ist - und war schon immer - extrem hardwareabhängig. Ich habe jetzt mal ein paar komplettscans von 19E mit transedit gemacht und und jeweils einen screenshot der totenliste gemacht. Die inis waren jungfräulich und default (diseqc A/A aus transponderliste). 4 devices, einmal mit transedit 3.8.2.3 und einmal mit 3.8.2.4. Natürlich sind das momentaufnahmen, aber ein trend ist schon sichtbar.

 

Einzig die TBS6925 scannt fehlerlos. Bei der Firedtv-S2 gibt es unterschiede zwischen den transedit-versionen. TBS8921 ist allgemein weniger gut aber auch da sind unterschiede zwischen den versionen erkennbar. Ganz schlecht schneidet eine Prof7500 (USB) ab. Bei der ist die 2.8.2.3 witzigerweise sogar besser. Bei dieser karte dürfte es aber wahrscheinlich an umschaltschwierigkeiten bei der polarisation (13/18V) liegen. Alle karte kriegen natürlich alle transponder, wenn entsprechend nachgescannt wird ;)

Link to comment
einmal mit transedit 3.8.2.3 und einmal mit 3.8.2.4.

Beim Scanner gibt es keinen Unterschied zwischen diesen Versionen. In der .4 sind nur zwei Fixes hinzugekommen - beim Schreiben der TransEdit.ini und beim XML-Export.

 

Bei der Firedtv-S2 gibt es unterschiede zwischen den transedit-versionen.

Taucht bei dir mit der FireDTV S2 im Analyzer auch eine ominöse PID 5 mit einem Teil der SDT-Pakete auf?

Link to comment
Beim Scanner gibt es keinen Unterschied zwischen diesen Versionen.

..dann ist das ganze um so schlimmer und sehr vom zufall abhängig.

 

Taucht bei dir mit der FireDTV S2 im Analyzer auch eine ominöse PID 5 mit einem Teil der SDT-Pakete auf?

Wo soll das sein? Nur bei bestimmten transpondern oder wahllos bei irgendwelchen analysen? Ist mir bisher noch nicht aufgefallen..

 

ps.

Karten habt ihr ja selbst genug, aber die umgebung (satzf-verteilung und übrige hardware) ist doch allgemein sehr unterschiedlich. Vielleicht solltest du solche scans sammeln. Ausganspunkt müssten definierte inis sein, bei denen nur diseqc personalisiert wird.

Link to comment
Wo soll das sein?

Hier bei jedem Transponder mit der letzten Firmware und Windows 7-Treiber (von der DD-Site). Meist ist nach ein paar Paketen Schluss mit der Umleitung, aber mitunter zieht es sich auch länger hin, und dann kann das Erfassen der SDT im Scanner scheitern ;)

 

Ich kann mich nicht erinnern, sowas früher unter XP bei der FireDTV S2 beobachtet zu haben. Vielleicht liegt es am Windows 7-Treiber und/oder der dazugehörigen Firmware.

Link to comment

..hab's wie gesagt noch nie gesehen und bei der karte werde ich auch nichts mehr am treiber ändern und XP/SP3 wird mich wohl auch noch eine zeitlang begleiten :D

 

vielleicht hat das ja mit DDs undurchsichtigen remuxing zu tun? ;)

Link to comment

Das ist der Original DE-Treiber und hat mit dem DD-Remuxing nichts zu tun...

 

Ich hatte auch schon massiv Probleme mit der FloppyDTV S2 zusammen mit TransEdit, da ging dann auch plötzlich nichts mehr bei SDT. Kann mich aber an die Testresultate nicht mehr so genau erinnern. 'Stop stream while tuning' hat glaub geholfen.

Link to comment

So wie es aussieht stolpert die FireDTV bei Muxen > 60 mbps und bekommt sich in weiterer Folge nicht mehr ein. Das Problem hatten wir ja intern schon diskutiert.

Link to comment
  • 3 months later...

Habe auch eine S2 TT-3200 und das Problem mit Transedit 3.8.4, dass beim Scannen "PMT" auf rot wechselt. Scanne ich dann erneut, finde ich die Sender (PMT grün).

 

Gibt es hierzu Abhilfe?

 

EDIT: Kein CI im Spiel.

Edited by darky
Link to comment

Mir ist das auch schon aufgefallen. Kann es damit zusammenhängen daß TransEdit und der RS inzwischen die LNB-Spannung bei der TT S2-3200 abschalten können?

 

Wenn ich TransEdit "frisch" starte und einen Scan versuche bekomme ich manchmal auch rot. Breche ich dann den Scan ab und starte ihn sofort erneut läuft er korrekt durch. Nicht daß TransEdit nach dem Einschalten der LNB-Spannung einfach noch etwas warten müsste bevor der Scan beginnt. Habe hier einen Technisat Multiswitch im Einsatz, brauchen die evtl. einen Moment bis sie bereit sind?

Edited by HaraldL
Link to comment

Dann fehlt eventuell die passenden MS VC runtime libraries. Am besten die TT Unterstützung nochmal über den DVBViewer Pro Downloader installieren. Da wird die richtige mitinstalliert.

 

Wenn der RS verwendet wird, sollte man den Stoppen bevor man TransEdit startet.

Link to comment
Dann fehlt eventuell die passenden MS VC runtime libraries. Am besten die TT Unterstützung nochmal über den DVBViewer Pro Downloader installieren. Da wird die richtige mitinstalliert.
Link to comment

Bei meiner TT-S2 3200 ist Standard-interface eingeschaltet (gleich bedeutend mit direkten Tunen aus im DVBViewer Pro)

Ich habe zwar mit TransEdit auch ohne beim normalen Scan keine Probleme, aber ich hab das jetzt einheitlich so eingestellt.

Die probleme beim Umschalten mit direkten Tunen im Pro sind zwar durch Grigas Massnahmen im DVBSource beseitigt,

aber es hat immer wieder defekte Aufnahmen gegeben mit direkten Tunen, wo der DVBSource den Ton nicht findet.

Die Ursache ist hier eventuell die gleiche: nach dem Tunen liefert die Karte noch Brocken vom vorherigen Transponder aus.

Mit Standard-Interface dauert das Tunen minimal länger, was offensichtlich ausreicht, um das zu beseitigen.

Vielleicht bewirkt das Fehlen der "ttBdaDrvApi_Dll.dll" etwas Ähnliches.

Verwende allerdings noch Win XP

 

Edit: der Standard ist keine Stand-art, berichtigt :blush:

Edited by gwr
Link to comment
Die probleme beim Umschalten mit direkten Tunen im Pro sind zwar durch Grigas Massnahmen im DVBSource beseitigt,

Hmm? Welche Maßnahmen? Habe ich da schon wieder was vergessen?

 

aber es hat immer wieder defekte Aufnahmen gegeben mit direkten Tunen, wo der DVBSource den Ton nicht findet.

Die Ursache ist hier eventuell die gleiche: nach dem Tunen liefert die Karte noch Brocken vom vorherigen Transponder aus.

Das wüsste ich gerne genauer. In der Hinsicht sehe ich eigentlich keine Probleme für die Wiedergabe.

 

Den Problemen mit TransEdit werde ich mich zuwenden, sobald ich mit dem DVBViewer GE-Release durch bin.

Link to comment

@Griga: ist es evtl. möglich das der Parameter "Set Group"/Group A-H irgendwo in den Transponderlisten von Transedit mit abgespeichert wird? Ich verwende auf den Tunern verschiedene Netze und mit dem DVBViewer sowie dem Rec.-Service wird dieser Parameter ja in der Sendeliste mit abgespeichert.

Ändere ich nur den "Group-Parameter" möchte Transedit ja auch die Senderliste speichern, aber nach dem Neustart ist wieder "Group A" aktiv...

Link to comment
ist es evtl. möglich das der Parameter "Set Group"/Group A-H irgendwo in den Transponderlisten von Transedit mit abgespeichert wird?

Er wird dort abgespeichert, vorausgesetzt du klickst nach der Änderung auf Save. Der Eintrag für Gruppe B sieht in der Transponderlisten-INI z.B. so aus:

 

[sATTYPE]

Group=1

Link to comment

@Griga: Der Wert Group=1 funktioniert bei DVB-S, aber leider nicht bei DVB-C. Ich weiß, das ich ein Sonderfall mit 2 verschiedenen Kabelnetzen bin :whistle:

Link to comment
Ich glaub ohne die "ttBdaDrvApi_Dll.dll" funktioniert es. Ich muss es nochmal genauer testen.

also wenn ich die Datei lösche, kann ich meine Fernbedienung nicht mehr nutzen...

Wenn es nur um die FB geht und nicht um CI, kannst du die ttBdaDrvApi_Dll.dll im Verzeichnis drin lassen und dafür den Vendor-Wert in der TransEdit.ini, Hardware.xml oder wo auch immer auf 26 ändern. Dann wird die DLL nicht geladen und auf jeden Fall das TT DiSEqC 1.0-Interface verwendet, bei dem sich der Treiber um das Senden der Kommandos kümmert. Das Input Plugin greift unabhängig vom Hauptprogramm auf die DLL zu.

 

Ich habe bereits eine Idee, woran es liegt, und werde hier eventuell demnächst eine TransEdit-Testversion bereitstellen. Allerdings muss es dann auch jemand testen...

Link to comment
Kann es damit zusammenhängen daß TransEdit und der RS inzwischen die LNB-Spannung bei der TT S2-3200 abschalten können?

TransEdit selbst schaltet die LNB-Spannung bei der TT 3200 nicht ab, außer wenn man es mit einem Tweak konfiguriert (LNBOff.x=1 in der [Hardware]-Sektion). Es kann natürlich sein, dass vorher der RS oder DVBViewer die Spannung abgeschaltet hat, wenn es dort in den Hardware-Optionen konfiguriert ist. Den Zusammenhang müsste mal jemand gezielt überprüfen.

 

Wenn ich TransEdit "frisch" starte und einen Scan versuche bekomme ich manchmal auch rot. Breche ich dann den Scan ab und starte ihn sofort erneut läuft er korrekt durch. Nicht daß TransEdit nach dem Einschalten der LNB-Spannung einfach noch etwas warten müsste bevor der Scan beginnt.

In der ttBdaDrvApi_Dll.dll gibt es einen Aufruf, mit dem man gleichzeitig ein DiSEqC-Kommando senden und die Spannung vorgeben kann. Wie der Treiber das timingmäßig behandelt, ist unbekannt. Beim ersten Tunen nach der Geräteinitialisierung verwendet TransEdit diesen Call, um das DiSEqC-Kommando abzusetzen und 18 V einzuschalten, wartet dann 250 ms und wiederholt den Aufruf. Wenn der Switch nach 250 ms noch nicht bereit ist, fragt sich, mit welchem Wert es zuverlässig funktioniert. Ich kann ihn natürlich beliebig hochsetzen, aber dann wartet TransEdit unnötig bei allen, die keine lange Verzögerung brauchen.

 

@darky: Versuche, mit der DiSEqC-Einstellung Extended und dem DiSEqC-Editor zu ermitteln, wie lange dein Switch braucht. Beginne die Sequenz mit dem passenden Committed-Kommando für die Transponderliste bzw. Satellitenposition, gefolgt von einer Verzögerung (Delay), einer Wiederholung des Committed-Kommandos und einer abschließenden Verzögerung, die immer 100 ms betragen sollte:

 

1 Switch Committed (updated)

2 Internal Delay -> variieren

3 Switch Committed (updated)

4 Internal Delay -> immer 100 ms

 

Nach der Eingabe nicht vergessen, auf der linken Seite des TransEdit-Hauptfensters Apply anzuklicken. Wenn du z.B. die erste Verzögerung (Kommando 2 in der Sequenz) auf 200 ms setzt, sieht der Ablauf beim ersten Tunen effektiv so aus:

 

DiSEqC -> 250 ms Pause -> DiSEqC -> 200 ms Pause -> DiSEqC -> 100 ms Pause -> Tunen

 

Die 250 ms und die erste Wiederholung fügt TransEdit wie oben beschrieben von sich aus ein, der Rest ist von dir beeinflussbar. Gibt es eine Schwelle für die erste Verzögerung (Kommando 2), ab der es zuverlässig funktioniert?

Edited by Griga
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...