Jump to content

Sporadische Fehler bei der Aufnahme


Recommended Posts

@shaupti: Bitte versuche mal eindeutig einzugrenzen ob es immer erst ab dem 5. TS (=> der 5. Tuner wird benutzt) liegt oder nicht! Ich habe hier testweise schon mal bis zu 15 Sender ohne jegliche Fehler aufnehmen können...

Link to comment
  • Replies 117
  • Created
  • Last Reply

Top Posters In This Topic

  • shaupti

    59

  • MaxB

    21

  • Tjod

    15

  • Derrick

    11

Top Posters In This Topic

Posted Images

Die Tests die ich gemacht hatte Waren immer so Tuner 1 - 5 nacheinander zugeschaltet und beim Tuner 5 hat Tuner 1 Fehler bekommen, wenn Tuner 5 aus ging kamen keine neuen Fehler wenn Tuner 5 wieder zugeschaltet wurde kamen wieder Fehler bei Tuner 1. Hatte auch die Konstellation Tuner 8 - 3 wobei dann Tuner 8 Fehler hatte.

Bei diesen Tests kommt der Fehler zu 100%

 

Ja das ist war im normalen Betrieb treten weniger Fehler auf. Konnte bis jetzt auch keinen Hinweis finden ob es nur gewisse Sender/transponder Kombinationen betrifft.

Deswegen ja sporadisch.

 

Weis ja auch nicht wie die Initialisierung von den Tunern abläuft, wenn eine Aufnahme beendet wird und auf dem gleichen Tuner 2min später eine weitere startet. Ob der Tuner dann deaktiviert wird oder sozusagen im standby bleibt.

 

Muss mir nachher die logs von gestern abend und heute anschauen vielleicht ergibt sich was.

Link to comment

OK, also sind wir uns insofern einig, dass es ab dem fünften internen DD-Tuner (egal welcher als fünfter benutzt wird) Probleme gibt?

Hier mal ein gerade gemachtes Beispiel mit 18 Aufnahmen an meinem DVB-C RS mit 6 Tunern, allerdings nur 4 interne an der Octopus Bridge (RTSP Octopus-1 & RTSP Octopus-2) sind DD-Netzwerktuner...

post-18611-0-97494400-1404647009_thumb.png

 

So, ich muss arbeiten (Spätschicht...)

Link to comment

Ja genau! Und so lange mehr als 5 Tuner laufen kommen auch keine Fehler.

 

Du meintest hoffentlich "Und so lange weniger als 5 Tuner laufen kommen auch keine Fehler." :rolleyes:

Link to comment

Der gemeinsame nenner ist doch die achtarmige DD-hardware, oder nicht? Warum funktioniert es anscheinend bei DVB-C, nicht aber bei S(2)? Die hardware ist doch bis auf frontend und LNB-versorgung identisch, oder nicht? Unterschiede gibt es natürlich bei den treibern. Dem DVBViewer/RS sollte es ziemlich egal sein, von welchem typ die quelle ist.

 

Gibt es andere anwendungen ausser DVBViewer, mit denen sich testen liesse? Passiert es auch, wenn z.b. 4 tuner einer GE-instanz fest zugeordnet werden und die anderen über den RS laufen? Gibt es übrigens eine reaktion von DD?

 

 

Link to comment

Zum testen würde mir nur MP Einfallen.

Ja das stimmt der Nenner ist DD. Habe das Ticket erweitert das es ja nicht eindeutig besser geworden ist, mal sehen was da noch kommt.

 

 

@MaxB

Könntest du vielleicht die Aufnahmen mal direkt im DVBViewer machen ohne RS?

Bei mir laufen Grad ein paar Aufnahmen die ich ungern unterbrechen will.

 

 

Link to comment

Ich meinte nicht ohne RS, sondern der Pro/RS einige tuner entziehen (nicht benutzen) und dafür diese tuner einer anderen instanz (GE) zuordnen. Wenn die störungen nach wie vor von der summe der aktiven tuner abhängen, ist der RS aus dem schneider ;)

Link to comment

Ich hatte schon mit der letzten (internen) TransEdit Version ohne den RS getestet auch wenn es in diesem Post nicht so deutlich zum Ausdruck kam

 

Ich habe den RS und TransEdit auf die letzte interne Beta aktualisiert und die DD-Tuner sowohl mit dem RS als auch mit TransEdit (mit RTSP über den RS & auch direkt ohne den RS zu nutzen) vorwärts und rückwärts durchgetestet:

Auch da war es eindeutig immer ab dem 5. TS! DVB-S oder DVB-S2 war egal...

 

Die DVB-C-Tests sind mit 4 internen Tunern und der externen Octopus-NET gemacht, deshalb kann ich dort problemlos 6 Tuner nutzen. Das ist genauso wenig Aussagekräftig wie der gut gemeinte Test von Griga mit zig verschiedenen Tunern.

 

Für mich bleibt aber immer noch die offene Frage an @shaupti, ob das Problem auch dann noch existiert wenn man die internen DD-Tuner anders aufteilt, aber ich denke er versteht meinen Denkansatz nicht und möchte nicht mehr umbauen :rolleyes:

Ich kann es nicht, da ich erstens gerade ca. 400 KM von den Sat RS entfernt bin und zweitens in dem RS nur eine "Octopus PCIe 4 Port Bridge" in dem Server verbaut habe...

Link to comment

Ich verstehe dich und werde es auch machen.... Müssen ja wissen ob es etwas bringt. Das mit dem transedit hab ich schon gelesen nur durch die frage/Aufforderung von Derrick kam noch eine andere Idee.

Da wird morgen nochmal gebastelt.

Link to comment

Sodelle, habe jetzt umgesteckt und die Cius neu zugewiesen,

 

Die Frage ist nur, welcher Ci ist jetztz der erste und gehört zum welchem tuner?

 

Edit:

Da durch die Ferrit-Kerne sich der Fehler nicht mehr 100% Provuzieren lässt, müssen wir ein wenig warten um das Ergebniss zu sehen.

Edited by shaupti
Link to comment

@shaupti: Das Umstecken meine ich nicht (nur) wegen dem CI sondern wegen dem 3. Tuner an der Bridge. Ich hatte Dein aktuelles Setup so verstanden: Bridge mit 3 Flex-Tunern + 1 CI, V6.5 + 1 CI, oder sind die Tuner schon aufgeteilt?

 

Wegen dem Vorschlag.

 

Den Latency Checker hatte ich auch laufen, keine Ausschläge, alles im grünen Bereich.

 

Jetzt ist die Cine 6.5 und eine Duo-Flex und ein Ci

und an der Octo Bridge sind 2 Duo-Flex und ein Ci

Edited by shaupti
Link to comment

@shaupti: bevor mit CI gespielt wird bitte unbedingt erst das Verhalten von FTA (wie auch schon von Derrick angemerkt) durchtesten. Ich werde -sobald ich mal wieder bei meiner Familie bin- wegen Ferritkernen nachschauen, ich meine die Kabel haben noch keine Ferritkerne. Gab es die von DD kostenlos oder musstest Du die selbst besorgen?

Link to comment

Ich Spiel da nicht rum, nur müssen die auch zugewiesen sein um einen normalen Betrieb zu ermöglichen.

Selber besorgen, bzw glaube die haben die mittlerweile im Shop.

Die Ferritkerne will ich nicht weg machen, weil dadurch ist eine Fehlerquelle ausgeschlossen.

Link to comment

Du meinst bestimmt die Ferrit Kerne für die Stromkabel, hast Du davon an jedes Stromkabel der DD-Hardware jeweils einen dran gemacht einen oder nur einen davon an die Zuführungsleitung vom Netzteil?

Link to comment

Ja genau die. An jedes Stromkabel was an die Karten gehen und an die ci, d.h. In meinem Fall 6 Stück

Das deutet aber eindeutig daraufhin, dass die Störungen von der DD-Hardware erzeugt werden und ist damit eigentlich ein reines "Gewährleistungsthema" ich möchte jetzt nicht auch noch mit der EMV kommen...

Edit/Nachtrag: Weiterer Link zum Thema EMV hinzugefügt, ich könnte dazu Romane schreiben, hatte da auch mal Ärger mit einem Kunden (der ist vor Gericht gegangen, weil ein von mir verkauftes Gerät nicht der EMV entsprach und hat das Problem weit nach Ablauf der Garantie bemängelt!)...

Edited by MaxB
Link to comment

Ja weiß was du meinst. Ist doch mit den Datenkabel zu den flex auch so eine Sache, ich hatte da noch keine Probleme, gibt aber hier genug im forum.

 

Ist ja alles bei mir so verlegt das es keine Probleme geben kann, alla DECT usw.

Link to comment

Exakt das gleiche Verhalten wie bisher (der 5. TS wird angefordert und es kommt ab dem 5. TS zu Diskontinuitäten?), oder sind es evtl. auch andere Fehler, die während der Aufnahme passieren? In den letzten Tage sind diverse Gewitter unterwegs, die können einem auch die Aufnahmen versauen, z.B. wenn der Uplink der Anbieter beeinträchtigt wird...

Link to comment

War mir klar, das das mit dem Gewitter jetzt kommt ;)

Die Fehler die durch das Gewitter entstanden sind, sind natürlich außen vor und es sind nicht nur 2-3 Discos sonder gleich 30- 50 oder mehr Discos.

 

Ja das gleiche verhalten, wenn eine Aufnahme gestartet wird kommt in der länger laufenden die Fehler.

Wie gesagt ich kann es durch die Ferritkerne nicht mehr selber erzeugen.

 

Aber durch die logs ersieht sich das der Fehler der gleiche ist und es ist immer noch jeder Tuner betroffen, ich kann also nicht sagen es ist nur z.B. Tuner 5.

Link to comment

Bis zur Benutzung 4 (vier) internen Tunern kann ich weder an meinem DVB-C noch an meinem DVB-S Servern Deine Probleme nachvollziehen, ab der der Benutzung des fünften schon, habe aber definitiv noch keine Ferritkerne in meinem System(!), daher zum letzten Mal die Frage an Dich:

 

Tritt exakt das gleiche Verhalten (wie von mir bestätigt) auf: Der 5. TS wird angefordert und es kommt ab dem 5. TS zu Diskontinuitäten???

Link to comment

OK, da Du ja bisher experimentierfreudig warst folgende Fragen an Dich:

Hast Du noch irgendwelche andere DVB-S(2)-Tuner bei Dir rumliegen und könntest den RS mal auf maximal 4 DD-Tuner reduzieren und als 5. Tuner den evtl. vorhandenen Tuner einbinden? Ich bin mir inzwischen ziemlich sicher, dass ein reines DD-Problem ist, auch wenn es von denen evtl. dementiert wird...

 

Tut mir wirklich Leid, dass ich Dir so viel Bastelkram aufdrücke, aber DD scheint Dir ja nicht helfen zu wollen...

Edited by MaxB
Link to comment
  • 2 weeks later...

So die Fehlersuche geht weiter....

die letzten Tage waren schön, also auch keine Fehler durch unwetter oder so.

Habe jetzt mal von ein paar Tagen die logs nach fehlern durchgeschaut.

Die Fehler treten überwiegend in Zeiträumen auf also

um 01:00 Uhr
um 10:00 Uhr
um 18:00 Uhr

 

So im schnitt alle 7 - 9 Stunden

Ich habe die Automatische Viren suche abgeschaltet und die Backups. Von mir Persönlich laufen keine Anwendungen in diesen Zeiträumen.

 

Läuft irgendwas vom RecService oder so in diesen Zeiträumen?

Oder irgendwelche Windows Dienste?

Der EPG-Scan kann es nicht sein der Startet um 15:00 Uhr.

Link to comment

Das Thema habe ich schon gelesen, glaube ich eher nicht um die Zeiten laufen entweder alle Rechner oder sind aus.

Und am Server hängt usb mäßig nur Tastatur und Maus.

 

Und sonst habe ich schon alle Kabel von den sat kabeln entfernt so dass die ringsum knapp 20cm platz haben.

 

Also dürfte von extern alles gut sein

 

Bleibt nur noch intern.

Link to comment
  • 2 weeks later...

Bin immer noch auf Fehlersuche. Hab schon weitere Sachen umgebaut und eingestellt.

 

Jetzt hab ich noch eine Frage.

Wie zuverlässig ist die Zeit Angabe bei der Angabe wann der nächste Epg -Scan startet?

Link to comment

Was bedeutet das?

 

TRecordDatabase SvcDatabase.db3UpdateEntry ESQLiteException at 004B95D4: Error executing SQL statement.
Error [11]: The database disk image is malformed

Link to comment

Kann mir das einer erleutern was da passiert?

 

 

15.08.14 11:45:00.909 TRecording Release Digital Devices DVB-S/S2 Tuner 2 (2)
15.08.14 11:45:00.909 TRecording Destroy Digital Devices DVB-S/S2 Tuner 2 (2)
15.08.14 11:45:00.918 TRecording Destroyed Digital Devices DVB-S/S2 Tuner 2 (2)
15.08.14 11:45:00.918 TRecording hamDeleted Digital Devices DVB-S/S2 Tuner 2 (2)
15.08.14 11:45:00.921 CreateProcessW 4288
15.08.14 11:45:00.931 TRecordingEngine Releasereference TRecording: 10
15.08.14 11:45:00.952 TRecording AllocateHardware Digital Devices DVB-S/S2 Tuner 2 (8)
15.08.14 11:45:00.952 TRecording StartRecording Digital Devices DVB-S/S2 Tuner 2 (8)
15.08.14 11:45:00.952 TRecording StartRecording: RTLNITRO
15.08.14 11:45:00.960 TRecordingEngine AddReference TRecording: 11
15.08.14 11:45:01.875 TRecording ($02B7B700) EPG Callback: RTLNITRO running - 15.08.2014 09:00:00 - Highlander - 56174 - PDC:0
15.08.14 11:45:01.875 TRecording ($02B369D0) EPG Callback: RTLNITRO running - 15.08.2014 09:00:00 - Highlander - 56174 - PDC:0
15.08.14 11:45:03.536 TRecording ($02B7B700) EPG Callback: RTLNITRO not running - 15.08.2014 09:55:00 - MacGyver - 56158 - PDC:0
15.08.14 11:45:03.536 TRecording ($02B369D0) EPG Callback: RTLNITRO not running - 15.08.2014 09:55:00 - MacGyver - 56158 - PDC:0

Link to comment

×
×
  • Create New...