Kein Neues Tunen Bei Der Floppydtv Wenn Stream Fehlt?

[Prinz]

Hallo,

 

ich habe gerade ein Problem mit meiner FloppyDTV gehabt. Er hat 0 Bytes aufgenommen. Was ich nicht verstehe, warum der DVBViewer nicht versucht neu zu tunen, wenn der Stream fehlt.

 

Nach dem Log zu urteilen hat ein neu tunen nicht stattgefunden, obgleich es unter Hardware das retunen nach 10s eingetragen ist.

 

Unter welchen Bedingungen wird denn neu getuned? Bei der Terratec 1200 DVB-C hat das meist geholfen, warum funkt es bei der FloppyDTV nicht?

 

 

Hier der Log:

05.03.2007 19:34:37 Start App -----------------------------------

05.03.2007 19:34:37 Hardware.InitDevice Load settings for: DVB File Device

05.03.2007 19:34:37 Hardware.InitDevice Load settings for: Unicast Network Device

05.03.2007 19:34:37 Hardware.InitDevice Load settings for: Multicast Network Device

05.03.2007 19:34:37 Hardware.InitDevice Load settings for: FireDTV BDA Tuner DVBC (1)

05.03.2007 19:34:37 Hardware.InitDevice Load settings for: FireDTV BDA Tuner DVBC (1)

05.03.2007 19:35:00 VCR-Internal Starting recording process.

05.03.2007 19:35:00 OpenBDAdevice Getting SigStat: 2

05.03.2007 19:35:04 Opendevice Found FireDTV

05.03.2007 19:35:04 Allocate Hardware FireDTV BDA Tuner DVBC (1)

05.03.2007 19:35:04 VCR-Internal Found fitting Hardware: FireDTV BDA Tuner DVBC (1)

05.03.2007 19:35:04 TDVBHardware.SetTuner PMT: 300SID: 28008

05.03.2007 19:35:08 CI Base SetTuner Entering

05.03.2007 19:35:08 CI Base SetTuner PMT: 300SID: 28008

05.03.2007 19:35:08 CI Base SetTuner Leaving

05.03.2007 19:35:08 VCR-Internal Recording did start.

05.03.2007 20:31:00 Release Hardware FireDTV BDA Tuner DVBC (1)

05.03.2007 20:31:00 Destroy Hardware FireDTV BDA Tuner DVBC (1)

05.03.2007 20:31:02 FireDTVResetCA HResult: Ein an das System angeschlossenes Gerät funktioniert nicht

05.03.2007 20:31:02 Recording: D:\myVideos\logo_05.03.2007_07.50_03-05_19-35-08.mpg Discontinuities: 0

05.03.2007 20:31:32 End App -----------------------------------

05.03.2007 20:31:32 handle 393274

 

Gruß

Prinz

[Griga]

Setze einen Haken bei Optionen -> Hardware -> Öffne ganzen Transponder. Ich fürchte, die Hardware-Filterung der relevanten Streams ist bei der FireDTV/FloppyDTV noch nicht ganz ausgereift. Damit habe ich auch schon Überraschungen erlebt. Selbst bei geringfügigen Störungen wurden die Filter hier aus unerfindlichen Gründen zurückgesetzt, und alles blieb stehen. Auto-Retune half überhaupt nicht, nur ein neues Setzen der Filter, oder mit anderen Worten, das komplette Neu-Einstellen des Senders. Kaputt ist die Aufnahme dann auf jeden Fall

[Derrick]

..beim ungefilterten transport stream ist aber kein 256psk-empfang mehr möglich, weil der nicht durchs nadelöhr der firedtv passt.

 

ps.

 

muss natürlich heissen 256-QAM

[Prinz]

Hallo,

Setze einen Haken bei Optionen -> Hardware -> Öffne ganzen Transponder.

 

Habe ich für meine beiden Karten angehakt. Stream beim Tunen stoppen ebenfalls.

 

Nur so kann man doch mehrere Programme eines Bouquets mit nur eine Karte aufnehmen.

 

 

..beim ungefilterten transport stream ist aber kein 256psk-empfang mehr möglich, weil der nicht durchs nadelöhr der firedtv passt.

 

Mmm, die FireDTV hat doch eine FireWire 400 Schnittstelle, das müsste doch ausreichen? Ich habe bisher auch keine Probleme. Habe mit 2 Karten 10 unterschidliche Programme testweise gleichzeitig ohne Problem aufgenommen.

 

Gruß

Prinz

 

Gruß

Prinz

[Griga]

Habe ich für meine beiden Karten angehakt.

Laut Setup.xml für beide Karten nicht:

 

<entry name="UseHardwareFilter">1</entry>

Moment mal - das scheint im DVBViewer Pro 3.6.1.2 sehr speziell gehandhabt zu werden. Wenn ich "Ganzen Transponder öffnen" anwähle, erhalte ich in der Setup.xml UseHardwareFilter=1, und umgekehrt. Ebenso bei der SkyStar2. Das tatsächliche Verhalten scheint aber dem zu entsprechen, was in den Optionen zu sehen ist. Ein bemerkenswerter Fall von Supporter-Verwirr-Taktik...

 

beim ungefilterten transport stream ist aber kein 256psk-empfang mehr möglich

Mit aktueller Firmware schon, wie zu lesen war.

[Prinz]

Hallo Griga,

 

Laut Setup.xml für beide Karten nicht:

Moment mal - das scheint im DVBViewer Pro 3.6.1.2 sehr speziell gehandhabt zu werden. Wenn ich "Ganzen Transponder öffnen" anwähle, erhalte ich in der Setup.xml UseHardwareFilter=1, und umgekehrt. Ebenso bei der SkyStar2. Das tatsächliche Verhalten scheint aber dem zu entsprechen, was in den Optionen zu sehen ist. Ein bemerkenswerter Fall von Supporter-Verwirr-Taktik...

 

Wenn ich Deinen Beitrag richtig verstanden habe, arbeitet der DVBViewer bzgl. dieses Flags in der sogenannten negativen Logik.

 

So eine negative Logik birgt i.A. größere Gefahren. Könnte es sein, dass der DVBViewer beim neu tunen, wenn kein Stream vorhanden, dieses Flag in positiver - und somit fehlerhaft - auswertet? Dann wäre das ein Bug im DVBViewer.

 

Oder was könnten sonst noch die Gründe sein, dass nicht neu getuned wird?

 

Gruß

Prinz

[Derrick]

>beim ungefilterten transport stream ist aber kein 256psk-empfang mehr möglich

 

Mit aktueller Firmware schon, wie zu lesen war.

 

..ach ja? Wo steht das denn? Ich habe mal im firedtv-forum und auf der site von digital-everywhere geguckt. Bei denen werde ich aber nie so richtig schlau

 

Ausprobieren kann ich es auch mit dvb-s, denn ich kriege transponder, die breit genug sind

[Griga]

arbeitet der DVBViewer bzgl. dieses Flags in der sogenannten negativen Logik.

Sehr höflich ausgedrückt. Ich würde es eher verdrehte Logik nennen. Die Bezeichnung in der xml gibt genau das Gegenteil der tatsächlichen Einstellung an.

 

Hier passiert jedoch effektiv, was in den Optionen angezeigt wird - kann man mit dem Videorecorder Plugin -> Channels -> PID Dump -> List PIDs überprüfen. Soweit ich sehen kann, liegt kein Bug vor. Warum der Stream bei dir stehen geblieben ist, kann ich auch nicht sagen. Bleibt nur, zu warten, ob es ein weiteres Mal auftritt, und falls ja, die Bedingungen und Begleiterscheinungen genauer zu analysieren.

 

..ach ja? Wo steht das denn?

Digital Everywhere hatte es so angegeben, und Anwender hatten es hier im Forum bestätigt (war HDTV bei Kabel BW, glaube ich). Suchen werde ich es nicht für dich...

[Derrick]

Digital Everywhere hatte es so angegeben, und Anwender hatten es hier im Forum bestätigt (war HDTV bei Kabel BW, glaube ich). Suchen werde ich es nicht für dich...

..ja, das wäre auch zuviel verlangt Ich habe mal gesucht, aber keine stichhaltigen hinweise finden können. 256qam ist schon lange gelöst aber eben durch die hardwarefilter. Den neuen treiber werde ich mal ausprobieren und selbst testen

[Griga]

256qam ist schon lange gelöst aber eben durch die hardwarefilter.

Soweit ich weiß, muss man das im DVBViewer nicht einstellen. Der Default ist ja "Ganzer Transponder", und damit scheint es zu funktionieren. Keine Ahnung, wie sie es gemacht haben. Vielleicht sind sie meinem Vorschlag gefolgt und haben für DVB-C die Null Packets eliminiert? Wie auch immer, es war mit der Firmware behoben (nicht mit dem Treiber), und seitdem wurden hier keine Probleme mehr mit QAM 256 gemeldet. Ich kann mich erinnern, dass du damals die Firmware probiert und gemosert hast, das würde bandbreitenmäßig bei DVB-S nichts bringen. Scheint sich also auf Kabel zu beschränken.

[Derrick]

Scheint sich also auf Kabel zu beschränken.

..hinterm demodulator gibt es keine unterschiede zwischen S,C oder T. Wenn die nullpakete eliminiert werden, ist das eine rein kosmetische operation. Bei vollem mux müssten ohne pid_filter wieder probleme auftreten.

 

Es gibt doch hier ein paar kompetente kabeluser, die sowas leicht mit TransEdit testen könnten

 

ps.

das gehört hier zwar nicht hin, aber trotzdem Die beschränkung vom digitalen (dvb-s)-demodulator liegt in der symbolrate. Bei 90MHz abtastrate vom A/D-wandler wären das 45MS/s. Es gibt auf 53E einen transponder mit 44950KS/s. Nur mit dem tuner/demodulator der SS2 v2.6 kriege ich einen lock. Natürlich müssen da dann auch die pid_filter ran, aber mit allen anderen tunern geht nichts

[Benarty]

..hinterm demodulator gibt es keine unterschiede zwischen S,C oder T. Wenn die nullpakete eliminiert werden, ist das eine rein kosmetische operation. Bei vollem mux müssten ohne pid_filter wieder probleme auftreten.

 

Es gibt doch hier ein paar kompetente kabeluser, die sowas leicht mit TransEdit testen könnten

 

ps.

das gehört hier zwar nicht hin, aber trotzdem Die beschränkung vom digitalen (dvb-s)-demodulator liegt in der symbolrate. Bei 90MHz abtastrate vom A/D-wandler wären das 45MS/s. Es gibt auf 53E einen transponder mit 44950KS/s. Nur mit dem tuner/demodulator der SS2 v2.6 kriege ich einen lock. Natürlich müssen da dann auch die pid_filter ran, aber mit allen anderen tunern geht nichts

 

 

Ich habe auch das problem als DVBViewer nicht korrekt geschossen wird aber forciert mit windows.

FTA emfangst ohne probleme aber kein verschusselte mehr. DVBViewer is activiert, dan starte ich das commoninterface.exe vaon der tools menu der fireDTV. Ich be- ende das commoniterface.exe.In DVBViewer, nun das verschusselte kanal neu selektieren und poof, da ist das bild.

[Derrick]

Ich be- ende das commoniterface.exe.In DVBViewer, nun das verschusselte kanal neu selektieren und poof, da ist das bild.

..ok, aber was hat das mit diesem topic zu tun ?

[Derrick]

..da ich den verschreiber 256psk -> 256qam editiert habe, gleich noch ein nachtrag zur max. bitrate der firedtv.

 

Bei meine messungen mit realen dvb-s transpondern hatte sich eine grenze von ca. 48mbps für die firedtv ergeben. Darüber gab es massive discontinuitäten. Genau liesse sich das nur mit einem ts_generator ermitteln. Aber qualitativ reicht es..

 

256QAM bei der gebräuchlichen symbolrate von 6,9MS/s im kabel ergibt eine netto streamrate von 50,9mbps. Daraus folgt, dass störungsfreier betrieb bei unterdrückung der nullpakete nur gewährleistet ist, wenn wenn die nullpaketrate nicht unter ca. 3mbps absinkt. Wieviel im kabel leer ist, vermag ich nicht zu sagen, aber das könnte knapp werden und dann rätselt jeder, woran das denn liegen könnte

[Prinz]

Hallo,

 

Bleibt nur, zu warten, ob es ein weiteres Mal auftritt, und falls ja, die Bedingungen und Begleiterscheinungen genauer zu analysieren.

 

so wie es aussieht kann man den Fall abhaken. Es gab noch mal einen ähnlichen Fall nach meiner letzten Mail. Ich hatte mich dann erst mal entschlossen Windows XP wieder neu zu installieren bzw. einen Image einspielen von einem Zeitpunkt zu dem ich noch keinen TV-Karten-Treiber eingespielt hatte. Habe von diesem Punkt an alles neu installiert.

 

Das, was mir bei der ursprünglichen Installation aufgefallen war, dass die zwei Karten, die ich im System hatte mit dem gleichen Namen im DVBViewer angezeigt wurden, ist jetzt mit der Neuinstallation behoben. Auch gab es seit dem keinerlei Fehlaufnahmen mehr. Vielleicht war die eigentliche Ursache des Problems störende Reste des alten BDA-Treibers der Terratec-Karte 1200-C, die ich aus dem System ausgebaut hatte, da ein sicherer Aufnahmebetrieb mit dieser Karte bei mir nicht möglich war.

 

Letzlich hatte ich versehentlich während der Aufnahme den PC in den Standby gesetzt. Nach dem ich das bemerkt hatte, hatte ich in gleich wieder eingeschaltet. Die Aufnahme wurde direkt wieder ohne zusätzliche Aktionen wieder fortgesetzt. Das hatte ich bisher bei keiner Software/Hardware-Kombination erlebt und auch nicht erwartet. Die kombination FloppyDTV-C und DVBViewer scheinen demnach fast optimal zusammen zu arbeiten.

 

Aber eben nur fast, optimal wäre es gewesen, wenn der DVBViewer erst gar nicht in den Ruhezustand gegangen wäre.

 

Gruß

Prinz

[hdv]

Hallo,

 

optimal wäre es gewesen, wenn der DVBViewer erst gar nicht in den Ruhezustand gegangen wäre.

setzt du den DVB Task Scheduler ein?

Der verhindert den Ruhezustand bzw. Standby wenn der DVBViewer läuft.

 

[Prinz]

Hallo,

 

Hallo,

setzt du den DVB Task Scheduler ein?

Der verhindert den Ruhezustand bzw. Standby wenn der DVBViewer läuft.

 

Nein, den verwende ich nicht.

 

Da ich ein paar Kanäle nur analog empfangen kann, verwende ich den PVR Scheduler.

 

Wenn eine digitale Sendung aufgezeichnet werden soll, startet der PVR Scheduler ein VB-Script, das den DVBViewer kurz vor der Aufnahme startet (falls er nicht schon gestartet ist) und das dann die Aufnahme programmiert.

 

Bei Sendungen, welche nur analog in das Kabel eingespeist werden, startet der PVR Scheduler automatisch die WinTVCap-Anwendung und nimmt mittels ein PVR 350 die analoge Sendung auf. Die WinTVCap-Anwendung verhinder von sich aus den Standby.

 

Ich hatte auch vor längerer Zeit den DVB Task Scheduler in Betrieb, habe nur noch in Erinnerung, dass er die Aufnahmen erst scannt, wenn der DVBViewer verlassen wird. Das ist für die Betriebsart, die ich verwende, leider zu spät.

 

Für mich ist aber die Verwendung des DVB Task Schedulers etwas suspekt, da solche Funktionalitäten - wie unterdrücken vom Standby - eigentlich in das Hauptprogramm gehören. Bei dem Recording-Service ist dies jetzt - wie es sich gehört - auch integriert. Leider hat der Recording-Service noch keine COM-Schnittstelle, so dass ich diesen momentan noch nicht verwenden kann.

 

Gruß

Prinz

Edited March 17, 2007 by Prinz

[Prinz]

Hallo,

 

so wie es aussieht kann man den Fall abhaken.

eine Schwalbe macht noch keinen Sommer.

 

Leider haben heute wieder 2 Aufnahmen, welche mit der 1. Karte aufgenommen wurden nur die Länge 1kB.

 

Aufgewacht aus dem Standby um 10:14

1. fehlerhafte Aufnahme: Start 10:19:07, Ende 11:31:00

2. fehlerhafte Aufnahme: Start 11:14:04, Ende 12:31:00

 

Obgleich die Dateien nur 1kByte lang sind, ist wieder kein einiger Versuch "neu tunen" im ganzen Log zu finden.

 

Was ich einfach nicht verstehe, warum erkennt der DVBViewer nicht, dass der Stream wohl erst gar nicht beginnt? Bei der Cinergy 1200-C hatte das eigentlich immer geklappt. Dort hat zwar das neu tunen öfters keinen Erfolg gehabt, aber bei der FloppyDTV versucht es der DVBViewer erst gar nicht.

 

Soweit ich sehen kann, liegt kein Bug vor. Warum der Stream bei dir stehen geblieben ist, kann ich auch nicht sagen. Bleibt nur, zu warten, ob es ein weiteres Mal auftritt, und falls ja, die Bedingungen und Begleiterscheinungen genauer zu analysieren.

 

Was kann ich noch zur Analyse beitragen? Die Support.zip enthält auch die debug.log-Datei. Parallel zur fehlerhaften Aufnahme, lief auf der 2. Karte eine fehlerfreie. Wurde vielleicht dadurch der fehlende Stream nicht erkannt?

 

Gruß

Prinz

Edited March 18, 2007 by Prinz

[Griga]

Du nimmst offenbar als MPG auf. Da gibt es zumindest theoretisch noch andere Gründe, die den Rekorder daran hindern könnten, mit dem Schreiben zu beginnen (nicht gefundener Sequence Header, keine PCR...), selbst wenn der Stream kommt. Mit TS entfallen diese Hürden - direkter und weniger fehleranfällig. Vielleicht ist es einen Versuch wert.

 

Bei meiner FireDTV-S führt der DVBViewer Pro 3.6.1.2 bei ausbleibendem Stream ein Retune durch, wie ein Test eindeutig ergab.

[Prinz]

Hallo,

 

danke für den Tip, werd ich versuchen und weiter beobachten.

 

Gruß

Prinz

[Moses]

..hinterm demodulator gibt es keine unterschiede zwischen S,C oder T. Wenn die nullpakete eliminiert werden, ist das eine rein kosmetische operation. Bei vollem mux müssten ohne pid_filter wieder probleme auftreten.

 

Es gibt doch hier ein paar kompetente kabeluser, die sowas leicht mit TransEdit testen könnten

 

Ich weiß zwar nicht, ob ich wirklich kompetent bin, aber ich hab mit meiner FireDTV und Transedit rumgespielt und die Transponder mit 256QAM kann die alle ganz öffnen ohne dass irgendwelche Pakete verloren gehen.

 

Bei meine messungen mit realen dvb-s transpondern hatte sich eine grenze von ca. 48mbps für die firedtv ergeben. Darüber gab es massive discontinuitäten. Genau liesse sich das nur mit einem ts_generator ermitteln. Aber qualitativ reicht es..

 

256QAM bei der gebräuchlichen symbolrate von 6,9MS/s im kabel ergibt eine netto streamrate von 50,9mbps. Daraus folgt, dass störungsfreier betrieb bei unterdrückung der nullpakete nur gewährleistet ist, wenn wenn die nullpaketrate nicht unter ca. 3mbps absinkt. Wieviel im kabel leer ist, vermag ich nicht zu sagen, aber das könnte knapp werden und dann rätselt jeder, woran das denn liegen könnte

 

Richtig, hab einen Transponder mit 6,9MS/s und 256QAM geöffnet, Transedit pendelt sich bei 50,87 mbps ein. Ich bin die mal alle durchgegangen, und hab mir die Null Paket Rate angeguckt... der mit den wenigsten Null Paketen hat pendelt sich nach ein paar Minuten bei 2.95mbps ein, was also ca den 3mbps entsprechen würde... Die "Peaks" nach unten scheinen wohl auch noch im Rahmen zu liegen, keine verlorenen Pakete in ca 15min Messung.

 

Ich bin mal gespannt auf HDTV... bin bei Ish. Die speisen nur einen einsamen HD Kanal ein und der hat auch noch seinen eigenen Transponder spendiert bekommen... damit liegt da die Null Paket Rate bei über 30mbps.. *g*

[Derrick]

Richtig, hab einen Transponder mit 6,9MS/s und 256QAM geöffnet, Transedit pendelt sich bei 50,87 mbps ein. Ich bin die mal alle durchgegangen, und hab mir die Null Paket Rate angeguckt... der mit den wenigsten Null Paketen hat pendelt sich nach ein paar Minuten bei 2.95mbps ein, was also ca den 3mbps entsprechen würde... Die "Peaks" nach unten scheinen wohl auch noch im Rahmen zu liegen, keine verlorenen Pakete in ca 15min Messung.

Wenn ich deine messungen richtig interpretiere, können meine überlegungen nicht mehr stimmen Da du anscheinend den gesamten transport stream von einem 265qam-multiplex in transedit siehst - ohne fehlende pakete !! - muss das firewire-interface aufgebohrt worden sein. Beizeiten werde ich es mit neuer firmware auch bei sat probieren..

[Derrick]

Das wird leider etwas unübersichtlich..

 

Ein firmwareupdate auf 1.2.4 von (1.2.1) hat nichts gebracht. Auf meinen testtranspondern wird die rate noch genauso gedrosselt wie vorher (viele missing packets). Es kann aber sein, dass es für DVB-C anders gelöst ist. Die hardwareversion heisst dort zwar auch 1.2.4 aber die zip grössen sind unterschiedlich. Bravo dig. everywhere, da kann ich nur

[Moses]

Hm.. warum stört dich denn, dass ein 50 Mbit/s Stream über ein 100 - 400 Mbit/s Interface geschickt werden kann? *grübel*

Eigentlich ist Firewire da doch nicht der Flaschenhals... oder überseh ich da was?

 

Das die DVB-S Variante da Probleme hat ist natürlich merkwürdig...

[Griga]

Das die DVB-S Variante da Probleme hat ist natürlich merkwürdig...

Kaum. Bei DVB-C sind etliche Kunden betroffen. Bei DVB-S nur vereinzelte Spezialisten, die sich auf exotischen Sat-Positionen herumtreiben. Beim normalen Astra/Hotbird-Betrieb merkt man davon nichts - ich bin mit meiner FireDTV-S jedenfalls noch nie auf das Problem gestoßen.

 

Gemacht wird, was sich auszahlt. Die Bedürfnisse von Minoritäten sind ohne Belang. So funktioniert der Kapitalismus.

[Derrick]

Bei DVB-S nur vereinzelte Spezialisten, die sich auf exotischen Sat-Positionen herumtreiben. Beim normalen Astra/Hotbird-Betrieb merkt man davon nichts - ich bin mit meiner FireDTV-S jedenfalls noch nie auf das Problem gestoßen..

Bei einem solchen tellerrandweltbild fragt man sich, warum die sich einen englischen namen geben und auch ihr support-forum englisch ist. Ausser astra_norm_transpondern gibt es mehr. Hier ein beispiel von einem transponder von dem benachbarten satelliten Eutelsat W2 auf 16E. Einmal mit der mistfiredtv und einmal mit der (trotz dvb-s2 billigeren) pinnacle-konkurrenz

[Griga]

Tut mir ja leid, dass es bei dir psychosomatisch bedingten Brechreiz auslöst, aber für die allermeisten ist das wirklich nur ein - wenn überhaupt - marginales Problem.

[Derrick]

..man lernt natürlich, sich mit den unzulänglichkeiten zu arrangieren Trotzdem sollen die hersteller/entwickler wissen, was ich davon halte.

 

Hier geht es z.b. um retuning. Inzwischen ein anerkanntes feature, das aber erst durch mein quengeln in den DVBViewer integriert wurde (immer noch verbesserungswürdig, da der DVBViewer bei nicht (mehr) vorhandenem transponder ziemlich unbedienbar wird ). So gibt es noch einige beispiele.. ..als fazit komme ich immer mehr zur überzeugung, dass treiberschreiber entweder dumm, faul oder schlecht bezahlt sind (auch in beliebiger kombination zutreffend ). Jedenfalls haben sie anscheinend häufig keinen schimmer, was in der praxis gefragt ist. Bei der SS2 ist der lnb-ausgang z.b. auch in der xten-treiberversion noch aktiv, sobald der rechner hochfährt. Beim auto wäre das etwa so, als wäre immer ein gang drin, wenn der zündschlüssel gedreht wird.

[Prinz]

Hallo,

 

werd ich versuchen und weiter beobachten.

 

Leider ist das Problem heute wieder aufgetreten, mit einem Unterschied, heute ist die Datei nicht 1kByte groß sondern 4,6MByte statt etwas 1550MByte. Am mpeg-Format hat es wohl nicht gelegen. Irgendeine Meldung ist im Log wieder nicht zu finden.

 

Nicht funktioniert hat die Aufnahme, welche um 25.03.2007 11:14:04 gestartet und um 25.03.2007 12:31:01 geendet hat.

 

Auffällig ist, dass das Problem bisher immer dann aufgetreten ist, wenn beide Karten gleichzeitig eine Sendung aufnehmen. Die Sendung von der anderen Karte war fehlerfrei. Wie das Log zeigt, funktioniert die Parallelaufnahme prinzipiell schon.

 

Was kann ich noch machen, um dem Problem näher zu kommen?

 

Gruß

Prinz

Edited March 25, 2007 by Prinz

[gwr]

Das Verhalten erinnert stark an die Probleme mit 2* Skystar 2 bzw. 2* Airstar 2 mit den Technisattreibern.

Dabei wurde ja auch schon öfter geschildert, daß eine Karte nach dem Standby oder Ruhezustand kein

Bild und Ton bringt. Ist vielleicht hier auch ein Treiberproblem. Wenn dann könnte der Viewer da nicht viel machen.

 

Anderes Beispiel: Meine Nova-S-Plus funktioniert nach dem Standby nicht mehr, wenn vor dem Standby Girder

über Hauppaugeplugin und "irremote.DLL" auf die Karte zugreift. Wenn ich dann nach dem Standby den DVBViewer

starte habe ich weder Bild noch Ton, bekomme aber eine Signalstärke angezeigt. Es wird also etwas empfangen.

Deshalb wird auch nicht automatisch neu getunt! Es hilft nur ein Neustart des PC`s.

 

mfG Gerd

Edited March 25, 2007 by gwr

[Griga]

habe ich weder Bild noch Ton, bekomme aber eine Signalstärke angezeigt. Es wird also etwas empfangen.

Deshalb wird auch nicht automatisch neu getunt!

Das Retune im DVBViewer richtet sich danach, ob der Treiber Daten liefert (egal welche), nicht nach der Signalstärke.

[gwr]

hmm... hast natürlich Recht es wurde auch neu getunt (Pro 3.6.1.20) in der Debug.log steht es auch.

aber es nützt halt nix weil der Treiber kaputt ist.

Sorry hätte ich vorher noch mal testen sollen.

 

Gerd

[Prinz]

Hallo,

 

Das Retune im DVBViewer richtet sich danach, ob der Treiber Daten liefert (egal welche), nicht nach der Signalstärke.

 

Und warum werden die bei mir nicht aufgezeichnet? Doch ein DVBViewer-Problem?

 

EDIT:

Ganz vergessen hatte ich, dass prinzipiell eine Datei doch geschrieben wird.

 

Wenn man die mit ProjectX anschaut gibt es folgenden Bildschirminhalt:

 

TS(generic PES Container)(no PMT found)

1. PID 0x140-($)

2. PID 0x12C($)

3. PID 0x140

4. PID 0x136-($)

5. PID 0x136

6. PID 0x12C

7. PID 0x0-($)

Kann damit jemand etwas anfangen?

 

Gruß

Prinz

Edited March 25, 2007 by Prinz

[gwr]

Das passiert nach dem Ruhezustand oder Standby oder wann? das hab ich noch nicht ganz durchschaut?

Wenn es nach dem Ruhezustand oder Standby passiert(?) könntest Du die beiden karten mal

mit dem Analyser von Transedit überprüfen, immer eine auf nicht verwenden und dann mit der anderen einen

Transponder auswählen und schauen ob der Treiber vernünftige Daten liefert.

Oder mit dem DVBViewer ne aufnahme starten und dann die 2. mit Transedit überprüfen.

Vielleicht lässt sich da was erkennen.

 

Viele Grüsse, Gerd